Patterns & guidelines http://www.it.bton.ac.uk/staff/lp22/guidelinesdraft.

html

Don’t Write Guidelines Write Patterns!

Richard N Griffiths

Lyn Pemberton

University of Brighton, Brighton, UK

Summary

This paper describes the use of pattern language, as developed by the

architect Christopher Alexander, to document and disseminate HCI
design knowledge, and argues that this will have advantages over
guidelines.

1 Introduction
Compared with the centuries old disciplines that shape the lived environment
(architecture, fine art, civil, mechanical and electrical engineering, printing and
theatre, to name the more obvious), computing is a brash newcomer. Even less
mature is our sub-discipline of human-computer interaction design. It behoves us
to show humility in recognising the immaturity of our discipline by looking to
those longer established for both general approaches to design, and perhaps also
for specific solutions. This is not to set these disciplines up as edifices of
immutable wisdom; they contain their own debates and movements, and have
been capable of radical reappraisal and change during contemporary history.
However, these debates, drawing on the accumulated wisdom of prolonged
practice, offer substantial insight into fundamental issues about designing
appropriate artefacts for sustainable human use. In this paper, we discuss the
potential advantages of adapting ideas developed in the domain of architecture for
use in human-computer interaction design.

We refer specifically of the imaginative and thoughtful work on architectural and

engineering design which took place from the sixties onwards in the US and
Europe and in particular, the concepts of design patterns and pattern language
originally introduced by architect Christopher Alexander and colleagues, in two
books, A Pattern Language [1] and The Timeless Way of Building [2]. Though
developed in the domains of architecture, town planning and interior design,
Alexander’s thinking on design patterns has been applied very intensively over the
last few years in one area of computer systems development, that of object-
oriented design. There it has proved very powerful and fruitful [3]. This proof that
the design pattern approach travels well has encouraged other initiatives in the
software design area and makes us optimistic that it will be a useful conceptual
tool for re-visioning the usability guidelines program.

1 of 11 11/6/2008 1:17 PM
Patterns & guidelines http://www.it.bton.ac.uk/staff/lp22/guidelinesdraft.html

2 Background
2.1 The Form of Patterns

The concept of patterns as developed by Alexander has enormous subtlety and far
reaching implications. We cannot hope to do it anything like justice in this short
paper. In what follows, we attempt merely a brief introduction to the topic as
encouragement to further investigation.

Patterns grew out of Alexander’s disaffection with the quality of architecture in the
1960’s, which he attributed in part to the misapplication of formal methods in
architectural design. This had resulted in buildings which failed to fulfil the real
needs of the people who lived and worked in them, which failed to adapt to local
social and physical environments and which people simply did not like [cf. 6].
Alexander contrasts these modern failed building with the many successful, ‘living’
buildings created in other societies, buildings which for Alexander embodied ‘the
quality without a name’, a recognisable but indefinable quality which floats in the
semantic space bordered by terms such as ‘alive’, ‘whole’, ‘comfortable’, ‘free’,
‘exact’, ‘egoless’ and ‘eternal’. Patterns are conceptual tools for helping people
design buildings, which might themselves have that quality.

A pattern is the solution to a problem in a context. In a context or a set of

situations, a problem or clash of constraints will occur, which is amenable to
resolution by a canonical design form or solution. The pattern encompasses all
three elements: the situation, the problem of clashing constraints or forces, and
the canonical solution. An example problem in a context, from Alexander, would
occur where parents and children live in a house together (context), in which the
parents would like their own space away from the children, but still want to be
able to go easily to the children if, for instance, they are ill or anxious at night
(problem). A standard solution would be to create a separate space for the
parents, still within easy reach of the children’s room. This is the pattern "Couple’s
Realm," number 136 among the 253 patterns presented in A Pattern Language.
Like all the patterns it is connected both to larger patterns, which it completes,
including, in this case, "House for a couple" and "Intimacy gradient", and to
smaller patterns which in turn complete it, in this case "Low doors", "Sitting
circle", "Light on two sides" and "Marriage bed" among others.

At the highest level we find patterns such as "Independent regions", "Country

towns" and "The distribution of towns", while at the other end of the scale are
detailed patterns covering the need for a bench by a front door and for different
sorts of chairs to be provided in a room. Together the linked patterns form a
Pattern Language, a kind of informal grammar for buildings and spaces.

The solutions are not simply pre-formed parts of a building kit. A pattern is an
abstraction from any specific examples: this is what gives patterns their

2 of 11 11/6/2008 1:17 PM
Patterns & guidelines http://www.it.bton.ac.uk/staff/lp22/guidelinesdraft.html

generative power. They do not supply ready-made answers: people need to

exercise their own creativity to implement a pattern. In addition, because they
involve abstracting away from individual cases, patterns are hard to discover and
may take a long time to describe adequately. Alexander and colleagues spent over
ten years refining A Pattern Language and Alexander has commented that finding
patterns is a hard as theoretical nuclear physics [2, p. 261].

Alexander’s own patterns are structured and formatted as follows [1]:

Title: To capture succinctly (and evocatively) the solution that the pattern
offers.

Asterisks: To mark the significance of the pattern, two asterisks marking a

"true invariant", one marking a pattern which has made progress towards
identifying such an invariant, but which needs further work, and no
asterisks indicating confidence that an invariant has not been established,
and that variations are to be expected.

Picture: "... which shows an archetypal example of that pattern." This may
be literal or impressionistic. A subsidiary function may be to help the reader
remember and find the pattern subsequently.

Introduction: Setting the context and linking to higher level patterns.

*** To mark the beginning of the problem.

Headline: (In bold type) summarising the essence of the problem.

Problem body: Describing the empirical background of the pattern, the

evidence for its validity, range of variation of manifestation.

Solution: (In bold type) Describing the "... field of physical and social
relationships which are required to solve the stated problem in the stated
context." as a statement, in imperative form.

Diagram: Of the solution (For Alexander the solution should always be

capable of a diagrammatic representation.)

*** To mark the end of the main body of the pattern.

Connections: To lower level patterns that are required to complete this

pattern.

Pattern makers in other disciplines have adapted this layout as needed.

2.2 Pattern Languages

3 of 11 11/6/2008 1:17 PM
Patterns & guidelines http://www.it.bton.ac.uk/staff/lp22/guidelinesdraft.html

The fact that individual patterns are integrated into pattern languages is not
merely for convenience of retrieval. It enables the collection of patterns to operate
generatively, each pattern showing the sub-patterns required to resolve more
detailed design issues, in the context of the larger design. Exactly what might best
be considered a ‘natural’ organisational principle for HCI patterns is an open
question.

2.3 Identifying Patterns

The steps to identifying patterns that Alexander gives in ‘The Timeless Way of
Building’ [2] are:

1. Identify the subject of the pattern

For Alexander, within the domain of architecture, this involves finding places
which ‘feel good’. For us, this could translate to finding examples of human-
computer interaction that ‘work well’ for the users. The subjective
experience of the users is crucial in identifying patterns that are, in
Alexander’s phrase, ‘alive’, and make the user positively engaged with the
system.

2. Identify the problem that this pattern resolves

Patterns resolve conflicting forces, which may be technical, social or

aesthetic. Their interaction, through either conflicting or supporting is the
field of forces that the design solution must resolve.

3. Identify invariance

Empirical examples of attempted design solutions to these fields of forces

are then examined to identify features or properties of successful designs
that are missing in unsuccessful ones; i.e. the invariant that a pattern must
encapsulate. It is possible that an invariant will be identified, not from
existing examples, but from abstract analysis.

Identified patterns will be integrated into a pattern language, higher level patterns
setting the context for application of this pattern and lower level patterns
indicating how it should be completed.

3 The relevance of patterns to interface design

Given the background to the original development of patterns the design of
human-computer interaction appears obvious as a domain to which the pattern
approach may be applied. Interface design has always been about metaphors,
however loosely conceived: even a primitive command line interface is based on a
metaphor of conversation. With the advent of the graphical interface, these

4 of 11 11/6/2008 1:17 PM
Patterns & guidelines http://www.it.bton.ac.uk/staff/lp22/guidelinesdraft.html

metaphors have become increasing spatial. The desktop metaphor is ubiquitous on

PCs. In the Web (itself a spatial metaphor) terms such as home and site are
commonplace, and it is now common to speak of information spaces and to design
visualisations of data in 2-D and even 3-D spaces. The mapping between source
and target terms in any metaphor is never complete and one-to-one: metaphors,
in interface design as in language, will always break down sooner or later [cf. 7].
However, in interface design as in language, users seem to be able to handle this:
if not they would feel less easy about desktops which contained not only folders
but also objects rarely encountered on top of desks such as windows, menus and
wastebaskets. People have little difficulty in associating modern interfaces with
the sorts of objects and relationships that are the stuff of Alexander’s patterns.

At a deeper level, the analysis of the process of design that underlies patterns is
applicable to the HCI domain—as it is to any other where the design is to be
executed against a set of many specific and interacting requirements. Here the
task of the designer is to decompose the requirements into sub-sets defining
tractable design problems that will eventually be composed to satisfy the overall
goal. This approach to design is described in detail in Alexander’s Notes on the
Synthesis of Form [8].

3.1 Design Patterns for Interaction Design

When attempting to identify design patterns in human-computer interfaces and

interaction design, we must remember that the buildings that Alexander
considered were the result of many hundreds of years of development, whereas
interfaces have only had decades. There are few universally acclaimed design
solutions and this may mean that it will be easier to identify problems than to
describe the solutions that address them. In Alexander's terms, it may be that any
patterns we do find will not deserve asterisks. ‘Patterns’ (i.e., repeated
arrangements of widgets, or approaches to a particular design problem) can
certainly be seen in contemporary interface design. However, not all of these are
good! For instance, the use of frames on the Web has been roundly criticised by
Nielsen, [9]. However, others certainly look like candidate patterns to us. We give
some examples below.

The first of these, which describes the need for the user to be warned of potential
problems when interacting with a system, is described in full, while the rest are
left in outline ‘context, problem and solution’ form. Figures in parentheses are
references to other, fictional, patterns which would have to exist in a complete
pattern language.

85 Give a Warning *

. . . . users may be able to execute actions that can have serious unintended
consequences, so encourage or make them to THINK TWICE (86).

5 of 11 11/6/2008 1:17 PM
Patterns & guidelines http://www.it.bton.ac.uk/staff/lp22/guidelinesdraft.html

***

A user may need to be alerted to the consequences of a proposed action,

but will resent interruption in the flow of execution of their task if the
action is in fact correct.

When an expert user is engaged in a flowing task, the (software) tool that they
are using disappears from their conscious perception. This is an essential idea of
Heidegger's that Winograd and Flores use in their influential book, "Understanding
Computers and Cognition" [10].

"Another aspect of Heidegger's thought ... is his insistence that objects

and properties are not inherent in the world, but arise only in an
event of breaking down in which they become present-at-hand. One
simple example he gives is using a hammer to drive a nail. To the
person doing the hammering, the hammer as such does not exist. It is
a part of the background of readiness-to-hand that is taken for
granted without explicit recognition or identification as an object. It is
part of the hammerer's world, but it is not present any more than are
the tendons of the hammerer's arm." [10, p.36, Italics in original]

In general, the design of a software tool interface should allow this mode of work,
and not call attention to itself until a breakdown—an error occurs, or an
adjustment has to be made.

However, some actions may have consequences that the user should be alerted
to—where there is a more than usual possibility of the action being executed
mistakenly and inconvenience ensuing. The interface should be designed
syntactically so that inappropriate actions are not available—the mistake here is
more semantic in that the action may be intended by the user, but may have a
side effect that is not desired. The problem is to issue a warning without causing a
breakdown.

Thus, if all other actions are initiated by selecting from pull down menus and
releasing the mouse button, this particular action should also. However, the
significance of the action should be drawn attention to, e.g., while the mouse
pointer is over the menu item, a warning message appears along side, the item
has a different colour or typeface, an exclamation mark is appended to the item,
etc.

Therefore:

Where an action should have a cautionary warning associated with it,

arrange to present the warning information so that it is noticed by the
user, but does not cause a breakdown in the task with which they are
engaged.

6 of 11 11/6/2008 1:17 PM
Patterns & guidelines http://www.it.bton.ac.uk/staff/lp22/guidelinesdraft.html

***

This may be done by TOOL TIPS (101) or TEXT FORMATTING INDICATES

SIGNIFICANCE (102). Other levels of protection may be more appropriate; GET
CONFIRMATION (87), GET AUTHORISATION (88), AUTOMATIC OVERRIDE(89) . . .
.

The most extensive current example of an interaction design pattern language is

Jenifer Tidwell’s Common Ground [11]. Readers are encouraged to view this site
for a fuller view of the possibilities for Interaction Patterns.

3.2 Related Applications of Patterns in HCI

Aspects of functionality, ergonomics and integration with the environment of use

may also be recorded in patterns, and fed into the design process.The functionality
of a piece of software lends itself to description in terms of patterns. This should
not be a surprise. Alexander's patterns are intended to create buildings which
allow users to live as they want: pattern-like thinking for software functionality
design should similarly aim to build systems which incorporate just those functions
which help a user to do what s/he wants. At its simplest, a functional pattern
would be an element of a requirements specification document together with a
rationale from systems analysis or a workplace study, as in this example.

"Provide Multiple Filing Systems" Pattern

Situation: in paper systems, people often have documents that need to be

referenced in two places or under two or more headings. In real life offices people
work round this either by creating a copy of the document and filing one under
each heading, or putting a referring note in one of the locations.

Problem: this is a problem in the paper world as it involves long hours by the
photocopier or messy bits of paper that have a tendency to get lost.

A solution: the same functionality can be provided in a lightweight way via

software by using a "duplicate" or better a "create a link" command in an
operating system.

When we move to the level of the physical artefact in which the software is
embedded, the pattern language structure can be used to point out general
contextualised problems and general solutions which can be implemented to fit
specific situations.

"Make a Computer that looks like a Filofax™" Pattern

Situation: business people want to carry their computers around with them.

7 of 11 11/6/2008 1:17 PM
Patterns & guidelines http://www.it.bton.ac.uk/staff/lp22/guidelinesdraft.html

Problem: business people tend to be relatively mobile, so heavy weights are

impractical. They also tend to carry briefcases and paper-based objects such as
reports, diaries and personal organisers.

A Solution: create a casing for the computer which lightweight, as handy as a

Filofax™ and which business people can carry in the briefcase which is part
of their "uniform".

At yet another level, we encounter problems or contexts in the physical world,

which need a physical world solution but one that has a software element to it.
Here we could imagine experimenting with Alexander’s patterns unchanged as
they should apply directly. In particular Alexander's patterns 146 - 252 on work
situations, covering flexible office space, communal eating arrangements, small
work groups, reception areas, waiting areas, small meeting rooms and half-private
offices will have direct applicability to building design in enabling people to meet
and also to withdraw into privacy as they wish.

"Sociable Terminals" Pattern

Situation: in control room environments where a number of workers are

collaborating (e.g., an industrial process, transport system, etc.), having a general
awareness of the current state of all parts of the system—not only those which
they control—is important. This may be crucial when an emergency occurs, when
the time needed for controllers to appraise themselves of the situation to begin
planning their actions in response eats into the time available to respond.

Problem: the display of information presented in the room must allow co-workers
to consult each other’s work. For instance, colleagues glance at each other’s
screens when walking to the coffee machine and often pick up problems as they do
so.

Solution: design the new layout perhaps as a horseshoe, with the screens of
workstations facing inwards, making sure screens are big and readable and of
common design.

This pattern might be linked to another pattern, which refers to the need for
co-workers to be in auditory rather than visual contact.

The current trend to carry out quasi-ethnographic studies of workplaces such as

control rooms as a prelude to the redesign of collaborative software has led to the
problem of finding a language in which the social scientists carrying out the study
can structure their results for clients and designers. As Erickson [4] has
suggested, patterns may provide just such a form, as these examples briefly
demonstrate.

3.3 The Advantages of Patterns

8 of 11 11/6/2008 1:17 PM
Patterns & guidelines http://www.it.bton.ac.uk/staff/lp22/guidelinesdraft.html

An immediate reaction to the ideas presented here may be that they simply
replicate (in a rather long winded way) what has already been done in HCI design
through the introduction of style guides such as the Macintosh Human Interface
Guidelines [12], The Windows Interface: An Application Design Guide [13], NASA
Human-Computer Interface Guidelines [14], and very many others. However, we
claim that what is missing from these style guides, and is added in the pattern
approach, is the explicit acknowledgement that whole patterns are being recorded.
This implies that:

• the meta-information surrounding the simple imperative instruction

normally found in guidelines is recorded. This means explicitly setting the
context in a hierarchical structure of patterns, drawing attention to the
problem that the pattern solves, conceiving of the solution to the problem as
resolving conflicts in a field of interacting social and physical relationships,
and considering and stating degrees of confidence in the invariance of the
pattern. This makes patterns an altogether richer resource for the designer
than lists of guideline, more akin to the resources to be found in what we
have called "craft wisdom" books such as [15] but expressed in a canonical
form.

• the use of patterns implies an emphasis on the process of developing and

using guidelines, rather than on the product—a list of imperative directions.
A good pattern will have been evolved out of the experience (both successes
and failures) and observations of a number of designers. It is susceptible to
further refinement in a way that seeks to approach the underlying invariant,
rather than simply recording more cases.

• pattern languages, via their interrelated organisation, give a way of

navigating the thousands of individual guidelines with confidence.

• patterns themselves are engaging and lively in a way that guidelines are
not, both in form and in the process of development, which often takes the
form of ‘pattern workshops’. This can make for continued evolution and
collaborative development of patterns.

• the use of a pattern language holds out the possibility of involving the
users of software interfaces in the design and modification of these
artefacts. By its non-jargon like nature, pattern language can serve as a
way of communicating between a number of parties to the design. We see
this as a particularly interesting area for development. Certainly some very
early work on using patterns in interaction design explicitly involved users
[16], and more recent work involved patterns as a communication medium
between HCI designer, software engineers and musicians [17].

4 Conclusion

9 of 11 11/6/2008 1:17 PM
Patterns & guidelines http://www.it.bton.ac.uk/staff/lp22/guidelinesdraft.html

With hindsight, it seems extraordinary to us that Alexander’s work has initially

had its most obvious influence on computing within the field of object oriented
systems design. On the face of it, human-computer interaction design has more
immediate correspondence with architecture; there is a visual aspect to
interaction with the artefact, and the architectural metaphor is widely used in
information system interfaces. In fact, Alexander did have a subtle, if not widely
acknowledged influence on the development of contemporary HCI, through the
writers of the Apple Macintosh Interface Guidelines. John Thomas has included
Alexander’s work in the bibliography section on Environmental Design with the
perceptive comment:

"In spite of its practical orientation, the design principles

—permeability, variety, legibility, robustness, visual appropriateness,
richness, and personalization—can be easily transposed to the human
interface domain." [12, p. 338]

In an invited speech to OOPSLA 1996, Christopher Alexander castigated the object

oriented software engineering community for only grasping shallow aspects of the
patterns programme; those having to do with organisation of the design space for
the convenience of designers. Generally, a piece of software’s end users of will be
unaware of the specific techniques used to produce it. While the original
constructors and maintainers of software are also users in a restricted sense and
there is admittedly some scope for liveness in their interaction with the code,
nothing like as much as in the individual and social interaction with the whole
artefact as employed for its eventual purpose.

References
1. Alexander, Christopher,, S. Ishikawa and M. Silverstein. A Pattern Language. Oxford, Oxford University
Press, 1977

2. Alexander, Christopher. The Timeless Way of Building. Oxford, Oxford University Press, 1979

3. Gamma, E. R. Helm, R. Johnson and J. Vlissides. Design Patterns. Addison-Wesley, 1995

4. Erickson, T. Report on Design Patterns Workshop CHI '97. http://www.pliant.org/personal

/Tom_Erickson/ viewed Nov 1,1997.

5. Pemberton, Lyn & Griffiths, Richard, N. The Timeless Way: Making Living Cooperative Building with
Design Patterns, in: Streitz, N., et al. (Eds.), "Cooperative Buildings—Integrating Information,
Organization, and Archetecture." Proceedings of CoBuild'98, Lecture Notes in Computer Science.
Heidelberg, Springer, 1998

6. Lea, Doug. Christopher Alexander: An Introduction for Object-Oriented Designers.

http://g.oswego.edu/dl/ca/ca/ca.html viewed Nov 6, 1997

7. Lakoff G. and M. Johnson. Metaphors We Live By. Chicago University Press. 1980

8. Alexander, Christopher. Notes on the Synthesis of Form. Cambridge Massachusetts, Harvard

University Press, 1964

10 of 11 11/6/2008 1:17 PM
Patterns & guidelines http://www.it.bton.ac.uk/staff/lp22/guidelinesdraft.html

9. Nielsen, Jakob. Jakob Nielsen’s Alertbox for December 1996 http://www.useit.com/alertbox

/9612.html viewed March 2000

10. Winograd, Terry & Flores, Fernando Understanding Computers and Cognition: A New Foundation For
Design. Addison-Wesley Publishing Co. Inc. 1986

11. Tidwell, Jenifer. Common Ground: A Pattern Language for Human-Computer Interface Design.
http://www.mit.edu/~jtidwell/common_ground.html viewed March 2000.

12. Apple Computer Inc. Macintosh Human Interface Guideline. Addison-Wesley Publishing Co. 1992

13. Microsoft Corporation. The Windows Interface: An Application Design Guide. Microsoft Corporation,
1987

14. Carlow International, Inc. (1992). Human-Computer Interface Guidelines. NASA, Goddard Space
Flight Centre, http:groucho.gsfc.nasa.gov:80/Code_520/Code_522/Documents/HCI_Guidelines/
viewed Dec 18 1997.

15. Cooper, Alan. About Face: The Essentials of User Interface Design. IDG Books, 1995

16. Beck, Kent & Cunningham, Ward. Using Pattern Languages for Object-Oriented Programs. Submitted
to the OOPSLA-87 workshop on the Specification and Design for Object-Oriented Programming, 1987

17. Borchers, Jan & Mühlhäuser, Max. Musical Design Patterns: An Example of a Human-Centred Model
of Interactive Multimedia, in Proceedings of the IEEE ICMCS’97 International Conference on Multimedia
Computing and Systems, 1997

11 of 11 11/6/2008 1:17 PM