The Promise of Pattern Languages for Interaction Design


Lyn Pemberton

School of Information Management

University of Brighton



One of the challenges for design as a discipline lies in developing effective techniques for communicating the engineering or craft knowledge that experienced designers have accumulated about solutions that work in particular circumstances. This is as true for interaction design as for more traditional areas such as product design, engineering design or architecture. While scientific knowledge is normally passed on fairly adequately in text books, there are few areas of interaction design that can genuinely be said to be built on comparable scientific principles. In engineering and craft fields, from bridge building to farriery, the traditional way of learning the requisite accumulation of skills and knowledge was for the beginner to be apprenticed to a skilled craftsman. However, today, apprenticeship in software design is uncommon, and other structures are needed for passing on expertise. This paper reviews the various tools and representations available for the communication of interaction design knowledge, before introducing a relatively recent addition, Design Pattern Languages. We give some examples of individual patterns and pattern languages and discuss the potential use of pattern languages as a means of representing interface design solutions in a range of contexts.
 

Requirements for an HCI knowledge transfer tool

The communication of expertise needs to be practised in a variety of contexts apart from formal teaching situations: The search is therefore for a usable way of representing and communicating interaction design knowledge, in a wide variety of contexts. The specific implications of this list seem to be that whatever vehicle is chosen: Current vehicles for Interaction Design Knowledge

Current tools for packaging interaction design knowledge, in addition to the examples furnished by the software programs themselves, include textbooks, monographs, edited collections, journals, conference proceedings, advice delivered via Web sites, sets of principles, collections of guidelines, standards documents and style guides

Textbooks

There are several respected and comprehensive HCI text books on the market, aimed at an undergraduate readership. Shneiderman's highly respected Designing the User Interface [Shneiderman, 1998] is a well known and internationally acclaimed example, though the predominantly UK-based teams headed by Dix and Preece have both produced successful competitors, both under the title Human Computer Interaction [Dix et al., 1998; Preece et al. 1994]. Other text books renounce the quest for comprehensiveness and concentrate on a particular aspect such as screen layout, usability engineering, designing for certain user groups or genres and so on. While these texts, both general and more specialised, are extremely successful in a formal academic setting in promoting awareness and conveying methods and principles, they can be difficult to navigate and physically unwieldy, making them unsuitable for day-to-day use in helping find solutions to specific concrete problems.

Other books

Many practitioners would agree that cultivating a "user-centred" attitude is as important as the mixture of high and low level factual knowledge usually conveyed by text books. Inspirational texts, often in the form of stories from the field, can be very powerful formers of attitudes, with writers such as Don Norman [Norman, 1988], Alan Cooper [Cooper, 1996], Terry Winograd [Winograd, 1996] and Brenda Laurel [Laurel, 1991] presenting themselves as obvious candidates. Clearly, though, while these volumes easily pass the "attractive to read" test, they are by no means the practical handbooks a designer might call on in time on need, nor is authoring a book of the calibre of those mentioned above a goal that a typical software designer in a commercial organisation could sensibly aspire to as a way of capturing his/her team's knowledge.

Other print media information and advice is found in edited collections of themed articles, academic journals and conference proceedings. The practical designer's lament here is the reasonable one that the volume of HCI research output contained in the totality of these publications is so overwhelming that the individual designer cannot possibly be expected to find his/her way through it to unearth the relevant nugget that might just be buried within it. These sources probably best seen as primary sources, to be re-represented by textbook authors before reaching individual designers.

On-line information

An interesting development in the area of interaction design advice is the turn to the Internet. This takes two main forms. The more established of these is the existence of special interest mail groups via which interaction designers (as other professionals) offer mutual support and advice. The Usability Professionals' Association discussion group is a good example of such a facility. However, the goodwill of individual designers is finite, and members are careful to put their problem to the group only once other avenues have been explored, so as not to be accused of various offences against Internet etiquette.

In a more recent development, well known practitioners such as Jakob Nielsen, David Siegel and others have set up Web sites where designers can read both general attitudinal advice together with more targeted prescriptions. These sites are nowhere near to filling their potential yet, existing at the moment mainly as repositories for the authors' articles and advice columns. As they expand, as they surely will, they will need to rationalise their structures and add better information retrieval facilities, but they are a promising development, holding out the promise of context-specific on-line design support.

Principles

Rather than expecting a designer to remember a whole textbook full of advice, why not try to boil some of the most widely applicable heuristics down for delivery in a more manageable set of general principles? Several of the major textbook authors have used this approach. For instance, Shneiderman (1998) sets out his eight golden rules:

A very similar set of 10 usability principles are suggested by Nielsen's [1992] list of areas of concern: Principles are clearly worth their place in the interaction designer's toolbox. They are often pithy and easy to remember. They function well as general decision support tools; when two candidate solutions are proposed for a problem, a solution that flouts one of the principles might be discarded in favour of the blameless alternative. They are general enough to cover a wide range of systems and contexts. However, their lack of specificity is also their major disadvantage: each general principle needs to be interpreted in the light of the context in which it is applied, and the experience to do this interpretation is precisely what the novice designer or the designer finding himself confronted by a novel situation both tend to lack.

Guidelines

Principles shade into a further type of design guidance vehicle, the interaction design guideline collection. These collections of tried and tested wisdom, distilled from research and experience, are to be found published both in textbooks and in guideline collections, the best known being Smith and Mosier's [1986] collection of 944 guidelines, available in print or digital format, ranging from the very high level, e.g. use short, simple sentences, to the highly specific, e.g. when using blink coding, make the blink rate 2 to 5 Hz, with a minimum duty cycle of 50 per cent. Collections like this are clearly the result of an enormous re-representation exercise, as advice from a range of sources is filtered and standardized into digestible prescriptions, and they are a rich source of practical advice. Moreover, unlike the daunting task of writing a text book or best-selling monograph, the task of reformulating a design teams' knowledge into prescriptive guidelines similar to these is a feasible prospect. With guidelines we are leaving the "read-only" world and moving towards a genre which invites participation from working designers. However, guidelines as currently conceived do not fulfil all our requirements, and have well-known drawbacks, resulting mainly from their form as short prescriptions, delivered out of context. For instance, guidelines can give conflicting advice, with no accompanying means of resolving the conflict. A detailed and comprehensive collection tends to be overwhelming in numbers for the average practitioner and advice on specific points is often difficult to retrieve. The relative degree of importance of individual guidelines is rarely indicated, nor the degree of confidence of the writer, and there is no deep learning for the designer who consults guidelines, as the underlying knowledge which generated them is, reasonably enough, not available.

Style guides

The popular user interface systems are the subject of especially produced sets of guidelines known as style guides, which aim to help those designing applications for a specific context to achieve a consistent appearance and behaviour. Style guides usually give descriptions of specific interface elements, detailing both look (appearance) and feel (behaviour), with guidance on how and when to use them. Interface design guidelines will normally include a window hierarchy diagram and standards for menus and buttons, use of keyboard keys, mapping of data types to window controls and so on. While commercial style guides are widely used, individual organisations and even projects regularly develop their own style guide probably developed on the basis of general guidelines, commercial guidelines and possible house style/previous projects.

Style guides are excellent tools for encouraging consistency amongst commercial designers developing software for a particular platform. On an organisational/project scale, they can be invaluable tools for encouraging a team to work in harmony throughout a project, working to agreed principles, terminology and the like. Style guides, like guidelines, pass the "write it yourself" test. However, they are not particularly engaging to read or easy to retrieve information from, and they share with guidelines a lack of explanatory context. Most importantly, they tend to help only with appearance and behaviour of screen objects, while having nothing to say to the designer about the "bigger" decisions she must make before questions such as mapping data to controls or icon design occur.

A promising addition: interaction design pattern languages

We have seen that a wide range of genres have been developed for design knowledge to be represented and communicated. While each of the approaches we have very briefly discussed has a good claim to its place, none fulfills all the criteria suggested as desirable, namely that it should be a repository of rich knowledge, tailorable to local circumstances, usable in the process of solving a specific problem, deployable in a range of situations, attractive to consume and engaging to produce.

A promising addition to this range of approaches comes in the form of Design Patterns and Pattern Languages. Pattern Language was originally introduced by architect Christopher Alexander and colleagues, in two books, A Timeless Way of Building (Alexander, 1979) and A Pattern Language (Alexander et al, 1977). 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 (Lea, 1997). 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 particular 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-scale patterns, which it completes, including, in this case, "house for a couple" and "intimacy gradient", and to smaller-scale 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 253 linked patterns form a Pattern Language, a kind of informal grammar for buildings and spaces. 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

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 creative power. They do not supply ready-made answers, as people need to exercise their own creativity to implement a pattern. In addition, because they involve abstracting away from individual cases, patterns are difficult to discover and may take a long time to describe adequately. Alexander and colleagues spent over ten years refining A Pattern Language and Alexander commented that finding patterns was a hard as theoretical Nuclear Physics.

Alexander’s patterns are structured and formatted as follows (Alexander et al, 1977):

Title:Which succinctly captures 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 yet.

Picture: "... which shows an archetypal example of that pattern." This may be literal or impressionistic.

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.

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 which are required to complete this pattern.

This rich and graphically interesting structure is an important part of the impact of Alexandrian patterns, as is the fact that they are typically expressed in very accessible, literate prose, rather than in any technical language. In particular, it allows the patterns to be shared with an important class of reader, the person who will eventually be inhabiting the building being designed.

How is an interface like a building?

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 is object-oriented programming. There it has proved very powerful and fruitful (Gamma et al, 1995). However, there are considerable mismappings between O-O development and architecture (Borchers, 1999), whereas the parallels between architecture and interaction design are clear and compelling. As Winograd has pointed out, interactive software can be seen as "the metaphorical spaces that people inhabit" (Winograd, 1996, p.15). Interface design has always been about metaphors, however loosely conceived: even a primitive command line interface was based on an implicit metaphor of conversation. With the advent of the graphical interface these metaphors have become increasing spatial. The desktop metaphor is ubiquitous, 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 (Lakoff and Johnson, 1980). However, again in interface design as in language, users seem to be able to handle this: if not they would feel less easy about desktops littered with windows, menus and wastebaskets. Software users have little difficulty associating modern interfaces with the sorts of objects and relationships which are the stuff of Alexander’s patterns.

In addition, the idea of "liveness" in buildings, the quest for the quality without a name, has much in common with the intuition that the systems which genuinely enable users to work as they want are want are those which we can call "engaging" or "convivial" systems. These are terms, like Kay's (1990) and Tognazzini's (1993) remarks on the place of magic in the interface, which seem to bound a similar semantic space to the quality without a name in the sphere of software. Systems with this quality, like Goldilocks' porridge, are "just right".

HCI Pattern Language

Since 1997, when a CHI workshop discussed the application of Alexander's ideas to interactive software, interest has been growing in developing design patterns and languages for interaction design. A number of workshops have been held at international HCI conferences (see Resources section, below), which have explored the relationship between architecture and interaction design and seen some steps taking towards the goal of creating HCI pattern languages. The 1999 Interact Workshop expressed the goals as follows:

The goals of an HCI pattern language are to share successful HCI design solutions among our colleagues, and to provide a common language for HCI design to anyone involved in the design, development, evaluation or use of interactive systems. (Usability Pattern Languages, 1999) A number of mini-languages have been developed and have been published on the Web, possibly the best developed being [Tidwell, 2000]. A particularly interesting twist on pattern publishing is the pattern critiquing facility provided by one site (van Welie, 1999) which allows a pattern to be developed remotely via the Web as critiques are received and integrated.

Some indicative examples of the kinds of HCI patterns created so far are given in Figures 1 to 3, which show abbreviated versions of patterns from the Brighton Usability Group's Interaction Design Pattern Language.
 
Title & number & rating 20 Interaction Feedback **
Problem & heading . . . . users working at data processing tasks on conventional workstations ? DESKTOP METAPHOR (23), GRAPHICAL USER INTERFACE (67) ? will need to be aware of the current mode of the system ?ALWAYS INDICATE CURRENT MODE (42) ? and must have an indication that their input has been accepted by the system.

People need to know that the system has registered an interaction event, such as mouse click, mouse movement, arrow movement, keyboard press, etc.

Body/forces Where an interaction event is only part of a sequence of commands to a system, or where no explicit user perceptible effect is achieved, people can become anxious that they have not been "heard" by the system, and may repeat the click or movement.

This anxiety can be relieved by giving some feedback ? proportionate to the scale of the interaction event and its significance ? to confirm to the user that the system has registered the event. Possibilities include, indenting a button, back-lighting a word, changing the shape of the cursor, making an audible click or beep.

For instance, the satisfying "zip’ when a window is rolled up or down in the Mac System 7.1a interface, the simple clicking of the mouse button, the movement of the key when hit by the finger, the "ghost" of the folder as it is closed and "replaced" in its parent folder.

In some work environments, an audible feedback may cause annoyance, so it must be possible for the user to silence it.

Solution Give feedback for every interaction event.
Diagram/examples

The highlighting of the waste bin reassures me that the document I dragged there hit its target

Connections If the computer action that has been initiated by the interaction event is going to take a significant amount of time to complete, then an indication if this should be given ? SHOW COMPUTER IS THINKING (34). 

Figure 1: Interaction Feedback

This is a pattern with a high level of generality, setting out the need for feedback on interaction events. It is, of course, equivalent at some level to the advice given much more succinctly in the principles quoted above, but to a bald prescription it adds a rationale, an example and a pointer to a more specific case (the reference to Pattern 34).
 
Title & number & rating "Show me first" 36 *
Picture
Problem & heading In a Graphical User Interface (5), when selecting an item from a list (Show What’s Available 24) or via a file title (Desktop Metaphor 8), the user may be uncertain what lies beneath the surface and therefore what they are committing themselves to.
Body/forces There’s usually a straightforward way of letting the user see what they’re getting, without forcing them to open up a new application or file, or commit themselves prematurely. This saves the user time.
Solution Give the user as much distinguishing information as possible before they commit themselves
Diagram/examples This font menu shows the user the effect of their choices before they make them.

Connections Specific situations have their own solutions, e.g. "Show preview" (48) for graphics/audio/video and "First few words" (79) for text files.

Figure 2: Show Me First

This pattern is more inventive and less closely allied with current guidelines. It suggests a general solution to a premature commitment problem, again with pointers to more specific solutions for particular versions of the problem (text, music, graphics files and so on). The pattern illustrates to some extent the creative power of patterns. If the object the designer is dealing with is not one which has previously had a "take a peek" capability, this pattern might push him to create one. What would a "take a peek" facility for a floppy disk, an application program or a remote server look like, for instance?
 
Title & number & rating "Don’t fence me in" 70 
Picture
Problem & heading There are some situations where the use may want to view or select from many items in a list, where it will not be possible for the designer to predict the top limit of items.
Body/forces Users don’t want to scroll though a list, especially if they have to do it many times over, e.g. when transferring files one by one to a different machine. However, designers often use non-sizeable windows to display the user’s list — sometimes this is big enough but often it’s not. 
Solution Give the user as big a window as possible — don’t make assumptions
Diagram/examples Main windows in Mac and Windows O.S. are sizeable. 
Connections Don't assume (55)

Figure 3: Don't fence me in

This is a relatively specific pattern, related to a higher level, more general pattern concerned with making assumptions about data to be displayed in an interface control.

How do patterns compare with other design knowledge tools?

Patterns of this sort, organised into languages, whether these be general or genre-specific, have the potential to fulfill most the criteria we identified above as necessary in a design knowledge transfer tool.

Some of the reasons for this are implicit in the form and structure of design patterns and languages. Their conventional format means that they contain both prescription, rationale and a variety of other information elements, such as illustrations, examples, provisos, warnings and so on. Patterns explicitly set 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 guidelines, more akin to the resources to be found in "craft wisdom" books of Cooper, Laurel and other writers, but expressed in a canonical form.

Patterns, particularly if delivered via a digital hypertext medium such as the Web or some other flexible format, are usable in context, by the designer confronted with a pressing practical problem. The "memorable" title is designed to ease recall and pattern languages, via their interrelated organisation, give a way of navigating a large collection of individual patterns with confidence.

Some advantages arise from the social context of pattern making. HCI patterns, at least as the pattern writing and dissemination process is currently conceived, are not "read-only". Designers can identify and describe their own patterns, disseminate them and publish them via the Web, where they can be critiqued and taken up by other designers. The rise in interest in using HCI patterns has coincided with the rise of their ideal publishing and development medium.

Patterns themselves are very satisfying to create and refine, particularly in the context of an informal pattern writers' workshop (see Lea, 1999). They are inherently much more motivating as a goal for a design team than an end of project review which they suspect nobody will ever read. Moreover patterns themselves are engaging and lively in a way that guidelines are not, both in form and in the process of development. This can make for continued evolution and collaborative development of patterns.

The style of patterns also 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. This is a particularly interesting area for development, though it must be admitted that some pattern writers have their doubts about its practicality or even advisability. Certainly some very early work on using patterns in interaction design explicitly involved users, and more recent work has involved patterns as a communication medium between HCI designer, software engineers and musicians [Borchers et al, 1998].

Patterns therefore hold out the promise of becoming effective tools for the communication of interaction design knowledge in a wide range of contexts by:

Issues for Exploration

There are a number of important issues about the development of interaction patterns which we have not yet touched on but which are crucial to its future.

One of these issues is validity. When searching to identify design patterns in interfaces, it is probably as well to remind ourselves that whereas the buildings which Alexander considered were the result of many hundreds of years of development, interfaces are at a relatively early stage. There are few universally acclaimed solutions and this may mean that it will be easier to identify problems than to describe the solutions which address them. The clear implication is that patterns need to provide empirical evidence of

their validity. One suggestion to head in this direction, promulgated at the CHI2000 Patterns Workshop, was for pattern writers who display their patterns on the Web to update them with evidence of their successful use, this information to be contributed by designers who have put the patterns into practice in a real-life context.

Another issue is structure. The structuring principle behind the Alexandrian patterns is scale, a principle that to some extent suggests itself. High level patterns deal with states, towns and cities, while lower level patterns describe chairs, picture rails and window panes. However, the "natural" structuring principle for interaction design patterns is not obvious. Borchers (1999) for instance, argues that time rather than scale would make a more natural structuring principle, while other would argue for a system using a scale from general to specific. One of the advantages of the digital format, of course, is that we are not tied to a single structure, and patterns could feasibly be marked up as multi-use hypertext fragments to produce whichever of a number of structures best suited the reader.

A third issue could be called coverage. At the moment in the HCI domain, several "sub-languages" for specific domains are being developed, for instance for Web applications, visualisation software, robot control systems, music applications and control room software. However, they are like pieces of a large, ambitious but rather anarchic patchwork quilt that at the moment has no overall structure to it: small patches are filled in but large areas remain blank. Individual sub-languages do not draw on others, which leads inevitably to redundancy as each pattern writer creates a different pattern for more or less the same phenomenon. Perhaps more importantly, there is no sense of the scope of the general pattern language writing project and therefore no public agenda for future efforts in pattern writing, as the impetus to produce pattern languages arises from either personal or organisational interest in a specific corner of a larger domain.

Much energy has been spent over the last four years exploring the theory of design patterns in HCI and in creating example mini-languages to illustrate the possibilities. One could argue that now the challenge is to move out - into applying patterns on real-life projects -and to scale up - from dozens of patterns to perhaps several hundred, integrated into a language. The answers to the issues discussed above will only emerge as designers put pattern languages to serious and sustained use in practice.



References

Alexander, C., S. Ishikawa and M. Silverstein. 1977. A Pattern Language. Oxford, Oxford University Press.

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

Apple Computer, Inc. 1992. Macintosh Human Interface Guidelines, Addison-Wesley Publishing Co.

Borchers, J. 1999. Position paper for HCI Design Patterns Workshop, Interact, Edinburgh. Available at www.it.bton.ac.uk/cil/usability/patterns/

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

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.

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

Cooper, A. 1996. About Face. Addison-Wesley.

Cross, N. 1984 . Developments in Design Methodology. Chichester, John Wiley.

Cross, N., Christiaans, H and K. Dorst, Ed. 1996 . Analysing Design Activity. Chichester, John Wiley.

Dix, A., J. Finlay, G. Abowd & R. Beale. 1998. Human Computer Interaction. 2nd edition. Prentice Hall.

Faulkner, X. 2000. Usability Engineering. Macmillan.

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

Hix, D. & H.R.Hartson. 1995. Developing User Interfaces: Ensuring Usability Through Product and Process. Wiley.

Jones, J.C. 1992. Design Methods. Van Nostrand Reinhold

Laurel, B. 1991. Computers as Theatre. Addison-Wesley.

Laurel, B. (ed), The Art of Human Computer Interface Design, pp. 191 - 207. Addison Wesley.

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

Lawson, B. 1980 . How Designers Think. London, Architectural Press.

Lea, Doug. Christopher Alexander: An Introduction for Object-Oriented Designers. http://g.oswego.edu/dl/ca/ca/ca.html, viewed Nov 6 1997

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

Newman, W.M. & M.G. Lamming. 1995. Interactive System Design. Addison Wesley.

Nielsen, J. 1992. Usability Engineering. Academic Press.

Norman, D.A. 1988 . The Psychology of Everyday Things. Basic Books.

Preece, J., Y. Rogers, H. Sharp, D. Benyon, S. Holland & T. Carey. 1994. Human Computer Interaction. Addison Wesley.

Shneiderman, B. 1998. Designing the User Interface: Strategies for Effective Human Computer Interaction. 3rd edition. Addison Wesley.

Tognazzini, Bruce. 1993 . Principles, Techniques and Ethics of Stage Magic and their Application to Human Interface Design. Proceedings of CHI '93, pp. 335-362.

Usability Pattern Language: creating a community (at Interact 99, Edinburgh)

http://www.it.bton.ac.uk/staff/rng/UPLworkshop99/

Winograd, T. (ed.) 1996. Bringing Design to Software, Addison Wesley.
 


An Alexander Bibliography


Background

Alexander, C., Ishikawa, S. & Silverstein, M. (1977) A Pattern Language: Towns, Buildings, Construction. Oxford University Press.

Alexander, C. (1979) The Timeless Way of Building.  Oxford University Press.

The classic sources of the pattern language idea.

Gabriel, Richard P. 1996. Patterns of Software: Tales from the Software Community. Oxford University Press.

Includes an interesting and readable account of the application of Alexander’s ideas to software design.


An HCI Pattern Bibliography

Discussion

History of Patterns

http://c2.com/cgi-bin/wiki?HistoryOfPatterns

Richly hypertextualised account of the history of patterns for software, beginning, ironically, with a Smalltalk interaction pattern language.

The Interaction Design Pattern Page

http://www.pliant.org/personal/Tom_Erickson/InteractionPatterns.html

Tom Erickson has been active in promoting interaction design patterns for several years. Probably the best set of resources at the moment.

Lingua Francas for Design: Sacred Places and Pattern Languages

http://www.pliant.org/personal/Tom_Erickson/LinguaFranca_DIS2000.html

Tom Erickson

Accessible from his Patterns Page, this is an interesting insight into patterns for community use, with lessons transferred to UI applications.

Pemberton, L. & Griffiths, R. (1998) The Timeless Way: Making living co-operative buildings with design patterns In Co-operative Buildings: Integrating information, organization, and architecture, Darmstadt, Germany, February 1998, Lecture Notes in Computer Science, Springer.

An exploration of the idea of "patterns all the way down", from building to interface objects.

Rheinfrank, J. and S. Evenson. (1996) Design Languages. In Winograd (ed.) Bringing Design to Software, Addison Wesley, pp. 63-80.



Pattern Collections

Amsterdam Collection of Patterns in User Interface Design

http://www.cs.vu.nl/~martijn/patterns/index.html

Beautifully presented collection of UI patterns by Martijn van Welie, including a virtual pattern writers’ workshop where you can expose your patterns to critique by the community. Needs XML-enabled browser for best effect.

The Brighton Usability Pattern Collection

http://www.it.bton.ac.uk/cil/usability/patterns/Banner.html

The Usability Group at the University of Brighton

Small collection of HCI patterns and resources

Common Ground

http://www.cs.vu.nl/~martijn/patterns/links.html

Jenifer Tidwell

UI pattern language from MIT. Relatively extensive.

Experiences -- A Pattern Language for User Interface Design

http://www.maplefish.com/todd/papers/experiences/Experiences.html

Todd Coram and Jim Lee

Article based on PLOP’96 presentation, detailing several patterns for interface design, concentrating on Explorable Interface pattern.

An HTML 2.0 Pattern Language

http://www.anamorph.com/docs/patterns/default.html

Robert Orenstein

Perhaps better seen as a partial Pattern Language for usable Web site design.

Website patterns

http://c2.com/cgi-bin/wiki?WebsitePatterns

Dave Orme

A collection of patterns and antipatterns for Web site design

Pattern Writers’ Workshop Patterns

http://c2.com/cgi/wiki?WritersWorkshopPatterns

Jim Coplien

A set of patterns on running workshop for pattern writing.

Workshops and Conference notes

Usability Pattern Language: creating a community (at Interact 99, Edinburgh)

http://www.it.bton.ac.uk/staff/rng/UPLworkshop99/

Pattern Languages for Interaction Design: Building Momentum (at CHI2000,The Hague)

http://www.it.bton.ac.uk/staff/rng/CHI2K_PLworkshop/



Non-Interface Software Patterns

Patterns Home Page

http://www.hillside.net/patterns/patterns.html

A fairly extensive set of resources on software patterns, with downloadable papers & tutorials.

Bookmarks for Design Patterns

http://hem.passagen.se/gumby/cs/patterns.html

Very comprehensive site, frequently updated

Software Pattern Links

http://www.enteract.com/~bradapp/links/sw-pats.html

Brad Appleton

Comprehensive set of links to pattern resources of many kinds