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.

Presentation Details

Presentation vs. interaction. Things on 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.

Antipatterns

Specifics of the implementation you should watch out for. Always should have examples of actual implementations that did this. Not speculative, but known-bad. These are not ALL the antipatterns, but some key ones we see. Rest assured you can screw up the pattern in more ways that we can list. If you cannot avoid an anti-pattern for technical reasons, the pattern should not be used, and a technically feasible replacement found.

Examples & Illustrations

...NOT REALLY INCLUDED! The list of examples is not inclusive, and not even always the most popular examples. They are instead intended to show variations, and even anti-patterns in practice, so you know what to look for.