Almost before we even started to figure out which patterns we wanted, we started talking about how they should be internally arranged. There’s a surprising amount of variation here, but primarily we decided that a single, totally consistent method was most important. That way, you have a fighting chance of taking two competing patterns and comparing them.

The most important section ended up being the one on variations. Something like 15 to 20 patterns disappeared over the course of writing this book, and ended up being better described as variations of existing patterns. And a few patterns we split into two or more patterns instead: after we started writing, the variations for some of the patterns were a bit too severe, so we split those patterns into two or more patterns, instead of just one with variations.

Name

Names are as short as practical while still being clear, and whenever possible they do not conflict with an existing concept. Some ended up being a bit of a mouthful as a result, but we did our best. In far more cases than expected, there was no name at all for a well-used design element, and we had to make something up.

We always used title case for the actual pattern names. If you run across a name that is capitalized for no apparent reason while reading a sentence (e.g., “Input Method Indicator”) that means it is in reference to another pattern in the book, which you can refer to in order to make a comparison. Whenever possible this is also made clear in the text, such as “see the Input Method Indicator pattern for an alternative method.”

Problem

Some people get nervous when the word problem is used in a project or design sense. But problems foster solutions, so try not to worry about any history or bad implications that term may have to your organization.

The “Problem” section of each pattern is just a summary of why you’d want to use the pattern. Ideally, patterns are grouped with similar problems, and you can get to the right section and then compare the problem statements as a way to help identify which one you really have.

Solution

The “Solution” section provides a definition of what the pattern involves, which other patterns are key overlaps or provide key components, and (when relevant) the important technologies required to make it operate.

This is one of the sections that can vary widely, from a very brief introduction to comprising half of the pattern. If it is difficult to explain, difficult to implement, or often poorly implemented, this will get longer. Simple patterns are shorter.

Variations

Our patterns aren’t stencils, so they aren’t restrictive. All of these have variations that you can choose and that are defined so that you can choose the correct one based on the con- tent to be delivered and the context in which you will use the pattern.

The length of this section varies widely depending on the number of and differences among the variations. Some have multifaceted variations, so more than one list may be encountered. In some cases, the variations are so pronounced that much of the interaction and presentation is covered in this section as well.

Interaction Details

This section explains how the user interacts with the item being described — including pressing buttons (or swiping the screen) and what the screen displays that the user can click on or type inside.

Presentation Details

This section explains things on the screen that you cannot click on, or details about the manner in which displayable items are presented which do not directly influence the interaction. A shadow on an interactive item might help with visibility, so this would matter but would not directly influence interaction, for example.

The difference between interaction and presentation can be a bit difficult to fathom sometimes, but breaking them up helps a lot when trying to seek the core truths of a function and separating what must be present and what is optional or additional.

Antipatterns

Specifics of the implementation you should watch out for are always listed. These cover both antivariations (methods that should never be used) and more minor pitfalls or edge case uses of proper variations to watch out for. These are not speculative, but are known to be bad because they violate heuristics, and often are verified by research.

These do not encompass all the possible antipatterns, but the key and most likely problems. Rest assured that there are many other ways to break a good pattern. Use design principles and heuristics, and carefully read the rest of the pattern to prevent poor implementations.

If you cannot avoid an antipattern for technical reasons, you should not use the pattern and instead you should find a technically feasible replacement. This is a common occurrence, and is a key reason the antipatterns are explicitly listed.

Examples and illustrations

We deliberately chose not to include a lot of screenshots. In fact, we include hardly any. We did not arrive at this decision lightly; we gathered and extensively annotated screenshots for the first several patterns. But we decided to take this route for the purpose of practicality. It’s very hard to find enough adequate examples, and often the best one is on a device that is difficult or impossible to capture. Some of the clearest examples are on feature phones, old PDAs, GPSes, and the like.

This leads to the key problem we encountered with screenshots: clarity. Patterns are the pure essence of an implementation. And almost every implementation layers its own style on top — or buries a pattern alongside others. Screenshots required explanation, and very often caveats about what not to do.

To solve the problems with screenshots, we used illustrations almost exclusively throughout the book. These are all of the same basic style, but vary widely in the detail level used, sometimes in adjacent drawings in the same pattern.

In each case, only the required amount of detail is used. Sometimes that detail is just boxes and lines, and the words and images are implied. Sometimes words and so on have to be in there to communicate the point. Sometimes actual raster icons or websites, drop shadows, and other effects are used.

As a general rule, large blank areas on a page do not mean there’s nothing there. It just means we’re not discussing that component, so we removed placeholder information for clarity. The Annunciator Row is almost always assumed, so space is provided, but is not displayed — again, for clarity and to reduce clutter.

Color, especially when clearly not naturalistic, generally has a meaning:

• Yellow usually refers to the displayed, interactive elements.
• Blue is for images, and graphical displays such as information visualizations. A different color is used so that it is clear that it’s not just a box.
• Grays represent nonselectable items, like the parent when a child has popped up over it.
• Orange is used when the item is in focus, as when scrolling in a list, or to indicate the primary button that is going to be selected for a process.

This is not always adhered to, especially in the higher-fidelity drawings, but it is a good guideline.

That being said, there are a few photos and screenshots in the book. We used these when creating an illustration of sufficiently high fidelity would have been pointless, for clarity when describing certain hardware details, and as example implementations when introducing new categories of patterns.

Next: Successfully Designing with Patterns and Heuristics

Discuss & Add

Links within the wiki

Please note that within the wiki, pattern names are generally cross linked. Click the blue text and just go straight there. In the book, they are also blue, but I assume if you click them the pages don't flip. I am not sure if they work in eBook formats, so someone who bought one tell me.

Some are not because we forgot, or linked them wrong, or changed the name later and forgot to update it. Do please tell us if one is missing.

To avoid too many links, the first use in a paragraph or section tends to be linked, but others often are not. We're a bit loose on this really, and the book isn't perfect on taking a position either way as well. If it bugs you, tell me and I'll fix it, else just figure it out.

A few other items will be linked, because the wiki software is trying too hard to auto-recognize, or something. If it doesn't seem like a pattern, and doesn't resolve, it's one of these. Sorry, I can't figure it out so gave up.

More about how to read patterns

There's an O'Reilly webcast Steven did on 8 November 2011 that outlines some principles of patterns (as we see them) and which includes a portion explaining each of these sections from a different point of view. Basically, why the sections exist as they do. http://oreillynet.com/pub/e/2087

Examples

If you want to add examples (and we occasionally do also) add them here.

Make a new section

Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.