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.

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 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

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 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).

***

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.

***

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.

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

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

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

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