Patterns & Guidelines

8/14/2019 Patterns & Guidelines

http://slidepdf.com/reader/full/patterns-guidelines 1/11

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.

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

1 11/6/2008



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


1 11/6/2008



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


1 11/6/2008



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, inAlexander’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


1 11/6/2008



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 foldersbut 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 theSynthesis of Form [8].

3.1 Design P atterns 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 todescribe 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 areleft 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).


1 11/6/2008



***

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

but w ill 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 ispart 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 w ith it,

arrange to present the warning information so that it is noticed by the

user, but does not cause a breakdow n in the task w ith which they are

engaged.


1 11/6/2008



***

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 isJenifer 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 functionalitydesign 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" P attern

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.


1 11/6/2008



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


1 11/6/2008



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

• 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


1 11/6/2008



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 includedAlexander’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 thepatterns 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.

References1. Alexander, Christopher,, S. Ishikawa and M. Silverstein. A Pattern Language. Oxford, Oxford UniversityPress, 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 withDesign 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, HarvardUniversity Press, 1964


11 11/6/2008



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 ForDesign. 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 SpaceFlight 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 Modelof Interactive Multimedia, in Proceedings of the IEEE ICMCS’97 International Conference on MultimediaComputing and Systems, 1997
