These patterns are intended to form an Alexandrian pattern language, as found in Christopher Alexander's book A Pattern Language, and not a catalog such as is found in the book Design Patterns. This means in part that they are intended to be used together synergistically, in a way such that the whole is more than the sum of its parts. Like other such pattern languages, it does not break new theoretical ground or present innovative new techniques -- it's more than likely that you have seen examples of every pattern in here. Instead, it captures ordinary design wisdom in a practical and learnable way.
The intended goal of this pattern language is deliberately broad: to support high-quality interaction between a person and a software artifact. The artifact may support one or more of a broad spectrum of activities, ranging from the most passive -- absorbing information with little or no interactivity -- to the hands-on creation of other objects. Consider some of the varieties of software out there today:
Another similarity among all these kinds of software (and other media) is their basic purpose. The best ones all provide their users with a successful and satisfying experience, by doing one or both of these things well:
In both cases, there is an "unfolding" process going on between the artifact and the user. In something which presents facts or ideas (such as a map), that unfolding may be top-down, in which the "big picture" is shown first and the users work their way down into the details as they need. Or, it might be in the form of a fictional narrative, in which the author uses language and character to let the central themes slowly unfold. The basic shape of the content might take the form of one of these "primary patterns:"
The primary patterns for actions -- their basic shapes -- might include these familiar genres:
Note that the patterns aren't meant to be straitjackets -- for instance, they can be used in combination with each other, such as putting bits of Narrative into the cells of a Tabular Set, or using a Form as an adjunct to a WYSIWYG Editor -- but the boundaries are basically respected by mainstream artifacts, and for good reason. Usability is improved when users' expectations, subconscious or explicit, are followed. On the other hand, experiments, cutting-edge interfaces, and art often make it a point to violate those boundaries. How you deal with the existing boundaries all depends upon your purpose.
The next set of patterns captures ways of unfolding an artifact's content or available actions. Some apply to content, some apply to actions, some to both; there's no reason to be dogmatic about their use.
There's one thing you should keep in mind about this language, however, that is atypical of other Alexandrian pattern languages. Most of these patterns can be used at many different levels of scale. A Form, for example, may be the dominant pattern in one artifact, while being a minor helper task in another. Likewise for a High-density Information Display such as a chart or a table. Small Groups of Related Things is recursive by definition, much like Composite in Design Patterns, and the concept of a working surface is also recursive -- any single surface can be composed of a set of Tiled Working Surfaces, for instance.
Because of this scale issue, I haven't yet been able to draw a coherent
diagram of the whole language, nor define clear linear paths through it.
I am open to suggestions on how best to do this. For instance, the
sublanguages are not much more than suggestions, based on which patterns
seem to go well with each other; it shouldn't be interpreted as exclusive
At a much deeper level, you can use this language as a tool to help you design an artifact. Please understand that it is no substitute for creativity or a good process. It is not a silver bullet. To use any pattern language effectively, you must start with an understanding of the artifact's purpose and audience, as is the case in any design methodology. (How can you pick a design solution if you don't know what the relevant factors are?) And to get the most benefit out of it, I believe you must allow the design to progress iteratively. Allow it to grow organically, by weeding out the bad ideas as you go and letting the good ones flourish. Start with the broad strokes and work down into the fine details; with each iteration, check your designs against reality, so that you can discover the bad choices and get rid of them.
(This reality may take the form of the viewpoints of different stakeholders, such as users, technical writers, testers, customer educators, and marketers. If they "speak" the same pattern language you do, so much the better -- let them in on the fun. They might have some excellent design ideas. In my experience, they almost always do.)
It is common in software to start with a "conceptual model," or a model of objects, relationships, behaviors, and states that describes the artifact independently of the user interface. Upon first reading, these patterns may seem to describe just the surface of an artifact -- the way it looks and the way it behaves. But the patterns may also be used to help design the conceptual model behind the interface. For example, content presented as Navigable Spaces might be implemented with one "object" per space, with object relationships corresponding to the links between the spaces. A Hierarchical Set should be the visible manifestation of a tree structure. A Form may present a series of editors for each property of an object, maybe with subforms for subobjects.
Some designers start from the user's perspective. They first design the interface, based on the user's needs and goals, and then design the underlying model to match it. This works well if you have the luxury of being able to affect the design the whole artifact. Conversely, you could start with the conceptual model -- perhaps it is an unchangeable requirement -- and then choose interaction patterns that have high fidelity to that model, assuming the model is a good one to start with.
The point is, users are going to build their own mental models about the artifact from what they can see. If there is consistency between the underlying model and the interface, and the interface is designed well enough to convey that model effectively to the intended audience, then the users will build mental models which correspond pretty well to the artifact's underlying model. Then the artifact has integrity. The user can more easily predict the artifact's behavior. Errors, if they happen at all, become comprehensible. The interface is easier for the designer to maintain over time, as the model changes.
In any case, I am not going to present a failsafe method for using this pattern language. In the first place, it has not been used enough to generalize from successful examples. Secondly, and perhaps more importantly, I'm not convinced that it will fundamentally change the processes that designers already use to design artifacts. A pattern language should make the processes smoother, more effective, faster, and hopefully with better end results; but there is already a wealth of knowledge out there on how to do design. As pointed out above, user contact and iteration are the keystones of good design.
Just as a proof of concept, here is an example of how the pattern language
may be used to build a user interface design.
(Technically, it was a redesign session. A previous version of this software had been designed as basically a set of Tiled Working Surfaces, and it hadn't worked very well. The main dialog was too small to allow the contained subforms to grow, for one thing, and it was all getting too complex. The models we had used turned out not to match the way our customers generally thought about the order-entry process, either. Furthermore, the underlying software structures were changing drastically. These factors made it worthwhile to redesign the whole thing from scratch, rather than incrementally modify the existing design.)
Primary Pattern: The users will be typing in preformatted information, and occasionally browsing for information that's already been typed in. The primary pattern we picked was Form; no other option seemed to make sense.
Posture: As mentioned above, the application was intended for use as a demo -- it would be seen by potential customers who have short attention spans, and our salespeople would not have long to demo it, and could spend little or no time on setup or long explanations. Therefore, we chose Helper Posture. (A real order entry system would require Sovereign Posture, to support the people who use the software eight hours a day, five days a week.)
Working-surface Organization: Here we thought carefully about what kinds of information would need to be provided, and how they broke down into obvious groupings -- customer information, order information, services and their various features. We considered how those information groups related to each other, in terms of part-whole relationships. (It turned out to be more or less a hierarchy.) We also thought carefully about use cases -- what happens when a customer calls? What information do they give, and when? What does the order entry person need to tell them? How does the order entry person need to navigate through the application, to keep up with a customer? Our discussions at this point were heavily informed by the feedback we had gotten from the previous design of the interface.
We decided on a Central Working Surface where most of the order entry actually gets done (a Java JFrame), with an auxiliary dialog for looking up specific customers and orders. The order entry frame itself was composed of a Stack of Working Surfaces, representing the various forms needed to take customer information, order information, etc.
Since these forms related to each other in a hierarchical fashion, we eschewed tabs (a linear presentation) in favor of a Hierarchical Set along the left side of the Stack of Working Surfaces.
Information Organization: We wanted to allow a summary of a given customer's entire order to be visible, both for practical reasons and for a more effective demo. But sometimes more than a summary is necessary; for instance, a customer may call and ask about the status of one particular feature of one service of one order, which is getting into very fine detail. Thus, we chose to use Optional Detail On Demand, in the form of a Hierarchical Set (which we'd already chosen) in which the nodes could be open or closed by the user.
Actions: We thought about which actions an order entry person would take, such as creating new orders, adding new services to an order, and switching to another customer. We divided these up into sets of Convenient Environment Actions and Localized Object Actions. Because we had chosen Helper Posture, we decided to create verbiose text buttons for each these actions, and then we decided where to put them (on the outer frame for the Environmental Actions, on the individual forms for Object Actions).
Again, because it was a Helper Posture application, we didn't bother using patterns such as User Preferences (no user would use it for very long) or Actions for Multiple Objects (potentially confusing and expensive to implement).
Kinds of Information to be Supplied: Each panel for the different kinds of information (customer, order, service, feature) is its own Form. For each of these Forms, we had to figure out what logical groups of information existed and in which order the Form would present the information. We sometimes used Small Groups of Related Things to visually organize it according to the natural groupings, such as a labeled box around the fields for an address.
At this point, we didn't have enough information about the details of the various model objects (customers, orders, services, features) to go into the next design iteration. But some of the patterns available to us here would be Forgiving Text Entry, Structured Text Entry, Choice from a Small Set, and Choice from a Large Set; modifying these still further would be Disabled Irrelevant Things and Good Defaults.
So, with the design discussion temporarily at an end, we put what we
had on paper (in pencil, for easy modification). Some informal usability
tests were performed with this paper prototype, to try out the initial
design; then an on-line prototype was built, for higher fidelity.
The feedback we got from these usability tests indicated that the interface
basically performs well. Once people actually tried to play with
it, we found that some of the navigation between forms needed to be changed
(it was then tested again), but we were happy enough with the final results
to begin implementing the interface.
Control Panel - The whole front of the phone.
Small Groups Of Related Things - The various groups of buttons: numbers, function buttons, etc.
Helper Posture - Only in your face while doing dialing, not too imposing on my desk.
Background Posture - The blinking 'Hold' indicator. (also Status Display)
Important Message - The ringer.
Remembered State - Redial button, stored numbers (bound to 'Quick Dial' buttons).
Go Back to a Safe Place - The 'Release' button, or the hook.
Composed Command - The dialing process (sometimes could be better supported by speech recognition)
Quick Access - 911, 411, *SP, etc.
User Preferences - The 'Quick Dial' buttons and the numbers they are bound to.
Social Space - Conversations and multi-way conversations are supported
by the medium the telephone connects to.
Narrative - Voice mail can be seen as a Narrative triggered by the user.
Optional Detail On Demand - Slide-out panel that shows more functionality, in more sophisicated phones.
Iconic Reference - Pictures indicating quick-dial buttons, like fire, police, pizza, etc.
Editable Collection - Voice mail 'unheard' and 'saved' messages.
Step-by-Step Instructions - Automated account information available from the phone company, credit card company, etc.
Clear Entry Points, Go Back One Step, Go Back to a Safe Place, Bookmarks, Optional Detail On Demand, User's Annotations, Convenient Environment Actions
Series of Small Multiples, Hierarchical Set, Tabular Set, Chart or Graph, Navigable Spaces, Small Groups of Related Things, Optional Detail On Demand, Disabled Irrelevant Things, Short Description, User's Annotations
Hierarchical Set, Tabular Set, Chart or Graph, Choice from a Small Set, Sliding Scale, Small Groups of Related Things, Optional Detail On Demand, Disabled Irrelevant Things, Important Message, Short Description, Personal Object Space, User Preferences
Choice from a Small Set, Choice from a Large Set, Sliding Scale, Convenient Environment Actions, Localized Object Actions, Pointer Shows Affordance, Small Groups of Related Things, Optional Detail On Demand, Disabled Irrelevant Things, Good Defaults, Remembered State, Reality Check, Important Message, Short Description, Interaction History, Personal Object Space, User's Annotations
Choice from a Small Set, Choice from a Large Set, Editable Collection, Sliding Scale, Forgiving Text Entry, Structured Text Entry, Good Defaults, Remembered State, Step-by-Step Instructions, Small Groups of Related Things, Disabled Irrelevant Things, Pointer Shows Affordance, Optional Detail On Demand
Toolbox, Set of Object Actions, Actions for Multiple Objects, Convenient Environment Actions, Optional Detail On Demand, Disabled Irrelevant Things, Pointer Shows Affordance, Short Description, Personal Object Space, User Preferences, Scripted Action Sequence, Remembered State, Reality Check, Demonstration, User's Annotations
Convenient Environment Actions, Localized Object Actions, Actions for Multiple Objects, Scripted Action Sequence, Forgiving Text Entry, Reality Check, Progress Indicator, Interaction History
Interaction History, Convenient Environment Actions, User Preferences
Map of Navigable Spaces, Clear Entry Points, Go Back One Step, Go Back to a Safe Place, Interaction History, Bookmarks, Pointer Shows Affordance, Short Description, Disabled Irrelevant Things, Progress Indicator, User's Annotations
Go Back One Step, Go Back to a Safe Place, Progress Indicator, Map of Navigable Spaces, Interaction History, Optional Detail On Demand, Disabled Irrelevant Things, Convenient Environment Actions, Good Defaults
Copyright (c) 1999 by Jenifer Tidwell. All rights reserved.