Differences between revisions 13 and 14
Revision 13 as of 2011-11-10 14:09:52
Size: 8640
Editor: shoobe01
Comment:
Revision 14 as of 2011-11-10 14:10:15
Size: 8642
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 73: Line 73:
Next: [[Successfully Designing With Patterns & Heuristics]] Next: [[Successfully Designing With Patterns and Heuristics]]

Click here to buy from Amazon.

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.

We always use 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 go see to compare. 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 get worried about any history or bad implications that term 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

We have made a deliberate choice to not include a lot of screenshots. In fact, hardly any. This was not arrived at lightly, and they were gathered and extensively annotated for the first several patterns. A little of it was simple practicality. It's very hard to find enough adequate examples, and very often the best one is on a difficult or impossible to capture device. Some of the clearest examples are on featurephones, old PDAs, GPS devices and the like.

Which leads to the key problem we encountered with screenshots: clarity. Patterns are the pure essence of an implementation. And almost every implementation layers it's 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, illustrations are used 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 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 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 means the displayed, interactive elements generally.
  • Blue is images, and graphical displays such as infoviz. A different color so it is clear that it's not just a box.
  • Grays are non-selectable items, like the parent when a child has popped up over it.
  • Orange is in-focus. Like 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 is a good guideline.

That said, there are a few photos and screenshots. These are used when making an illustration of sufficiently high fidelity would have been pointless, and for clarity when describing certain hardware details.


Next: Successfully Designing With Patterns and Heuristics


Discuss & Add

Please note that within the wiki, pattern names are generally cross linked. 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.

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.

Reading the Patterns (last edited 2013-04-08 20:01:56 by shoobe01)