Almost before we even started figuring out which patterns we wanted, we starting talking about how they should be internally arranged. There's a surprising amount of variation here, but most of all we decided a single, totally-consistent method was most important. That way you have a fighting chance to take two competing patterns, and compare them.

The most important section ended up being the variations. Something like 15-20 patterns disappeared over the course of writing, and ended up being better described as variations of existing patterns. And a few split instead. After writing started, the differences were a bit too severe, so it was rewritten to be two or more patterns, instead of just one with variations.

Name

Names are as short as practical while still being clear, and whenever possible do not conflict with an existing concept. Some end up being a bit of a mouthful as a result, but we do 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.

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 get worried about any history that may have to your organization.

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

Solution

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 being 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 aren't restrictive. All of these have variations that can not only be chosen from, but which are defined so that the correct one can be chosen based on the content to be delivered and the context in which the pattern will be used.

The size of this section varies widely depending on the number and difference of the variations. Some have multi-faced 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

How the user interacts with the item being described, both the physical pressing of buttons (or swiping the screen) and what the screen displays that the user can click on or type inside.

Presentation Details

Things on the screen, which 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 visibility, so matters, but does 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 separate out 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 "anti-variations" (methods that should never be used at all) 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 by violating heuristics, and often are verified by research.

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

If you cannot avoid an anti-pattern for technical reasons, the pattern should not be used, and a technically feasible replacement found. This is a common occurrence, and is a key reason the anti-patterns are explicitly listed.

Examples & Illustrations

Skimming this book, you will rapidly note there are no examples in the traditional manner found in technical design books. There are no screenshots of actual real-live products. After attempting to do this in the first few patterns, it was deliberately abandoned. Mostly because the screenshots weren't doing as good a job as the few illustrative, wireframe-like examples.

Production examples were are in very specific contexts, so had to have extensive captions to explain what the point was. And very often, some part was also bad, which had to be disclaimed.

The line drawings that are used show only what needs to be shown, with as much clarity as possible. These diagrams were produced in Adobe InDesign, and will be made available on the wiki when production is completed. So they can be used as components by interaction designers when implementing these patterns.