Comments and reviews requested; send to: email@example.com
The patterns that he and his colleagues defined -- published in a second volume, A Pattern Language -- are an attempt to codify generations of architectural wisdom. They are not abstract principles that require you to rediscover how to apply them successfully, nor are they overly specific to one particular situation or culture. Instead, they are somewhere in between: a pattern describes possible good solutions to a common design problem within a certain context, by describing the invariant qualities of all those solutions.
For example, he recommends using the "Entrance Transition" pattern with homes or any other building that "thrives on a sense of exclusion from the world." The pattern describes what one must do to a doorway so that someone entering it feels as though they are coming into a private, safe space:
"Make a transition space between the street and the front door. Bring the path which connects street and entrance through this transition space, and mark it with a change of light, a change of sound, a change of direction, a change of surface, a change of level, perhaps by gateways which make a change of enclosure, and above all with a change of view." (From A Pattern Language, pg. 552.)Note that the pattern is not just proscriptive. It describes something positive, something you can try to build, even though you would naturally vary it according to the particular situation. It doesn't simply say, "Never build a doorway without a change of level." Note also that it carries values -- the value of a private space, the value of emotional comfort. Alexander's goal is not to make a building which is merely trendy, or efficient, or even good-looking; he is looking for ways to create a genuinely good experience for people, via their built environment.
In recent years, parts of the software engineering community have enthusiastically embraced the patterns concept, due in no small part to the 1995 book Design Patterns, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Like the Alexandrian patterns, these patterns of object-oriented software provide design solutions that are concrete enough to immediately put into practice, with good results, and yet are sufficiently abstract to apply to countless situations, limited only by the imagination and skill of the pattern user.
We badly need the benefits of such a pattern language in the field of
But how do you come up with those initial designs? Once you understand where the user is coming from and what the artifact needs to do, what comes next? What further questions do you ask? What assumptions should you make? How do you put it all together into a design that might work? This creative leap is always harder than it sounds. And it costs us far less, in terms of time and usability testing, to make good guesses and design choices right at the beginning.
Furthermore, by constraining yourself to the relatively small number of tools that most toolkits give you, and to the ways of using them that convention dictates, you limit the expressiveness of your interface to that which is currently acceptable. ("I used a combo box there because that's what everyone does.") And no style guide can infallibly tell you how to strike a balance between two opposing high-level principles.
But this can be a scattershot approach. The designer's experience may be limited to software of certain types, or made by certain companies, and they may not be closely related to the kind of software being designed. Furthermore, the other interfaces that the designer draws from may not be good ones in the first place. So the designer ends up with an impoverished decision-making ability, despite all good intentions.
(A familiar scenario occurs if the designer is really a software developer by vocation. His or her sphere of experience probably includes mostly developers' tools and the Web, neither of which may have anything to do with the user interface they are designing. We've all seen the results!)
Of course, experienced designers don't entirely escape this mode of thinking, either. Reinventing techniques isn't really practical most of the time -- consciously or subconsciously, they apply what they know, and reuse good solutions they've seen before. The difference lies partly in the depth of experience from which they draw: a seasoned designer has seen, analyzed, or built interfaces of many diverse kinds. And it also lies in the skill with which they apply that experience. They don't clumsily or timidly copy a technique, afraid they'll somehow ruin it by changing it; rather, they understand the design principles and process enough to confidently adapt a good idea to a new use in a new context. They understand what works and what doesn't -- the common ground -- across different media and contexts.
How can the HCI community help inexperienced designers move away from clumsy designs and labor-intensive processes towards this state of confidence and skill, without spending years learning it all the hard way?
To begin with, we could start building a human-computer interface pattern language. A language of this sort is a set of interrelated patterns, which share similar assumptions, terminologies, and contexts. At its best, such a language would both aid individual interface designers in their day-to-day work (as the Design Patterns book clearly does for many software engineers), and also help the whole industry develop better tools and paradigms.
More specifically, it would help individuals build better interfaces by:
Each pattern description defines a context of use, a problem the designer needs to solve, a set of "forces" pushing the designer in different directions, and a primary rule -- and sometimes additional secondary rules -- on how those forces might be resolved to best solve the problem. Examples are also provided, both good and bad; sometimes the bad examples show inappropriate uses of the pattern, and other times they show a situation in which the pattern should have been used but wasn't.
Note that the pattern names and problem descriptions avoid the use of GUI-centric terms whenever possible (e.g. mice, menus, dialogs), so that you may more easily think about them being used outside the GUI world. Most of them do work that way. That was a condition of acceptance into this language: if a pattern is invariant across such different forms as paper, hardware, video games, and desktop GUIs, there must be truth in it. In fact, some patterns, such as User's Annotations, are not even in common usage yet in desktop GUIs.
Please read these patterns actively! Think about other examples that you might have seen, both from the world of desktop GUIs and from other fields. Consider how you would use them to design a new interface, or redesign an existing one (VCRs almost always provide entertaining cases of poor design). Look at an interface you like, and see if what you like about it can be captured by some of these patterns -- keep in mind that a pattern language can serve not only as rules for building a design, but also as a system for deconstructing an artifact and classifying its pieces. Finally, imagine how you might apply the pattern in a fully three-dimensional interface, or in a "Star Trek" interface, or some other new or fantastic technology. Would it work there? Why or why not?
Christopher Alexander posits that good patterns improve with time and widespread use. The object-oriented software development community has discovered that this is true, since there are now lots of people in that field developing their own pattern languages and reviewing them with others. The patterns in the original Design Patterns book have been augmented and refined, as is done in John Vlissides' Pattern Hatching. There is vigorous discussion going on at conferences, in magazine columns, over mailing lists, and in local special-interest groups worldwide.
The HCI design world could start engaging in similar discussions. If you have thought about patterns as they relate to user interface design or development, write about it. If you have additions to or criticisms of the patterns defined here, speak up, so that these can be improved. Read the literature on patterns and develop your own language, in contrast to this one.
If the success of patterns in architecture and software engineering
is any indication, both our industry and our customers will benefit greatly
from this effort.
Copyright (c) 1999 by Jenifer Tidwell. All rights reserved.