Download Richard N Griffiths - School of Computing, Engineering and

CHI2K Workshop: Pattern Languages for Interaction Design: Building Momentum
1
Design Patterns are a Process and not a Product
Richard N Griffiths
University of Brighton, UK
School of Computing and Mathematical Sciences
[email protected]
This submission addresses the process of developing design patterns in HCI. I will argue
that whilst the concepts of design pattern and pattern language have apparently obvious
beneficial application in structuring and representing guidelines in a tractable and generative
form, this takes account only of a shallow aspect of the pattern language programme. There
is a deeper and more thoroughgoing aspect that should be explored in this domain.
--With a romantic metaphor in mind, I would say that my relationship with HCI pattern
language has just come out of the infatuation stage, and I’m starting to look critically to see if
there really is a future for us. I get the sense that I am not alone in this. (That’s one of the
advantages to being a workshop facilitator — you get to read everyone else’s position paper
before finally editing your own.)
Here are the superficial appearances that hooked me into my relationship with patterns: The
idea of casting good practice in interaction design as design patterns appears to have
significant advantages over the writing of guidelines:

Design patterns record information about the contextual application of the prescription
and thus do not (should not) give conflicting advice, as sets of guidelines may.

Design patterns interlinked in a pattern language are generative of design where as
guidelines are largely evaluative.

Design patterns, having a narrative form and structure both internally, and externally as
part of a pattern language, are more inviting to read and easier to remember.
These are the ‘neat ideas’ of the sort that Alexander has castigated the object-oriented
community for not having got beyond. However, there is a down side:

Individual guidelines are comparatively easy to identify and record, whereas design
patterns being more highly generalised are much more difficult. (Like doing nuclear
physics according to Alexander!)

The ‘literary form’ of a design pattern is more demanding to write than the terse prose of
a guideline.

As guidelines do not contain interlinking references to other guidelines, they are easier to
maintain.
Each of the claims above are subject to considerable qualification and may be disputed. In
principle, they could be subjected to empirical evaluation (and this is something that the
patterns community could do). However, I’m now beginning to see that they miss much of
substance that is contained in the pattern language concept, and which would not be easy to
quantify or evaluate. This involves acknowledging the deeper aspects of designs that are
appropriate and amenable to sustainable human purposes.
CHI2K Workshop: Pattern Languages for Interaction Design: Building Momentum
2
It may well be the case that the form of design pattern and pattern language can be useful in
interaction design without consideration of these other aspects. They would encourage
consistency and standardisation of design and thereby assist in managing the design process.
For example, the ‘pattern’: “Make everything look like it was designed by Microsoft”
considerably simplifies the design process, and appears to produce acceptable results.
(That’s certainly the implicit guideline that most of my students adopt naively.) So simply
casting existing design guideline sets into pattern form could usefully be done. Maybe the
Microsoft style guide could be rewritten as a pattern language to generate Microsoft clones.
It could even be automated as a Wizard! But much would be missed. For design patterns to
make a significant contribution to human well-being, they need to point to timeless solutions
— and there’s the problem: where are timeless solutions to be found in this domain?
It seems to me that there are a number of sins of omission and commission that we should
seek to avoid as we take the idea of HCI pattern language further. I don’t expect that my list
is exhaustive.
The sin of hasty codification
It is a key aspect of Alexander’s development of patterns that they be based upon existing
examples. In the case of architecture the accumulation of examples has been proceeding for
millennia, and unsuccessful design details have been winnowed out over successive
generations. In the case of computerised information system design, and the design of their
human interfaces, this process has hardly begun, and any ‘patterns’ drawn from this
experience may be insubstantial and ephemeral. Further, rapid codification as a design
pattern may be positively harmful, as it could perpetuate a less that optimal design solution
— the interface design equivalent of Qwerty keyboards, a status that Windows™ has already
obtained.
The sin of mistaking the map for the territory
As well as the issue of the pattern concept being trivialised, there has been another problem
with my (our) understanding of patterns. There is a danger of mistaking the map for the
territory. It is important to remember that the pattern exists independently of anyone writing
it down as a design pattern. Where it exists is an interesting metaphysical speculation! It
may be in craft knowledge — which may be the procedural knowledge of creators (designers
and constructors) in the domain, or it may have a Platonic existence awaiting discovery
through mathematical or other scientific analysis. However it may only be identified at the
intersection of constructed artefact and social use. The point being that, to use a metaphor
from chaos theory, the pattern is an attractor that the written design pattern points to but that,
I would suggest, in all but the simplest cases can never completely define, i.e., it is a strange
attractor. This has a practical implication: it is inappropriate to attempt to create the
canonical set of design patterns. Every attempt to capture a pattern will emphasise certain
aspects and attenuate others. However, recognising that one design pattern points to the
same underlying pattern as another is valuable, if problematical, and requires identifying the
pattern by a common designator. Design patterns may be used by design practitioners to
negotiate a shared appreciation of the pattern.
The sin of fetishising the form of a design pattern
There is also a potential problem of our fetishising the superficial form of a documented
design pattern. Not everything that looks like a design pattern captures a pattern, and
understanding how to capture a pattern from our domain is a problem. An issue relevant to
CHI2K Workshop: Pattern Languages for Interaction Design: Building Momentum
3
this came up at the end of the Interact’99 workshop when a group of us were finalising the
poster we were required to produce. (See:
http://www.it.bton.ac.uk/staff/rng/UPLworkshop99/Poster.html ) We had decided that the
best way that we could get across the idea was to give an example HCI pattern. We used a
variation of Alexander’s form, with a schematic illustration at the end. In Alexander’s
design patterns, these are schematic architectural drawings. (Alexander specifically refers to
them as diagrams.) Is this the appropriate form for the schematic illustration of interaction
patterns? In the event, our example pattern contains two schematics; a sketch, and some
lines of pseudo-code. Which is really in the spirit of Alexander’s patterns?
I got some insight into resolving this when I read Alexander’s ‘Notes on the Synthesis of
Form’. (You often get key insights by following the genesis of an idea back through a
writer’s work.) There the significance of the diagram is explicated at some length. He
categorises diagrams into form diagrams, which “... summarise aspects of a physical
structure, by presenting one of the constituent patterns of its organisation ...”, and
requirements diagrams, which “... summarise a set of functional properties or constraints, ...
This kind of diagram is principally a notation for the problem, rather than for the form.” He
stresses that diagrams should be ‘constructive’, by which he means that they should be both a
requirements diagram and a form diagram in one, and that it should “... help in effecting the
translation of requirements into form ...” The example he gives is a vehicular traffic flow
diagram, in which the density of traffic in a particular direction is signified by the width of an
arrow. Ceteris paribus, the road layout to accommodate maximum traffic should look like
the diagram.
It appears that in our example pattern we managed to produce a form diagram (the sketch)
and a requirements diagram (the pseudo-code). But how should they be put together to
create a constructive diagram? What does a constructive diagram in our domain look like?
As we are freed from many of the constraints of material construction, and may wish to
document patterns that have no immediate material realisation (e.g., processes of group
co-ordination of work) using the same notion of form that is appropriate to architecture may
be too narrowly prescriptive in our domain. I.e., it will emphasise one amongst many
potential material forms (widgets on screens) of realisation of the pattern.
The sin of only recognising the theoretically appropriate
If Alexander’s idea of pattern language grew out of the ideas explored in “Notes on the
Synthesis of Form” (NotSoF), then it might be worth examining that book for ideas on the
deep issues we may have to confront when creating design patterns in our domain.
NotSoF contains a methodology for developing a design out of an analysis of requirements.
Essentially all requirements (and there may be over a hundred for a realistic design problem)
are analysed to identify those that support each other, and those that conflict. This is used as
input to a partitioning algorithm that breaks the collection into strongly internal but weakly
externally interacting groups and subgroups. The resulting tree of grouped requirements is
used to modularise the design space. Constructive diagrams are produced to provide
solutions for the leaf subgroupings, and then composed (in the mathematical sense) to solve
the requirements in their super group, until the whole design arrives as a composition at the
topmost level.
An emergent property of Alexander’s analysis is that the groupings of requirements do not
correspond to the typical analytical categories that designers may use to discuss the domain,
e.g., function, economics, production, safety, use, capital, maintenance, etc. His argument
CHI2K Workshop: Pattern Languages for Interaction Design: Building Momentum
4
(based on the Whorfian hypothesis) is that designers who attempt to use these categories are
inevitably lead away from appropriate solutions.
“In this fashion the selfconscious individual’s grasp of problems is constantly
mislead. His concepts and categories, besides being arbitrary and unsuitable, are
self-perpetuating. Under the influence of concepts, he not only does things from a
biased point of view, but sees them biasedly as well. The concepts control his
perception of fit and misfit — until in the end he sees nothing but deviations from his
conceptual dogmas, and looses not only the urge but even the mental opportunity to
frame his problems more appropriately.”
It appears that patterns are to be identified in the solution of these design module complexes
of interacting requirements. Hence, it may not be obvious where a pattern ‘came from’, i.e.,
what interaction of principles are required to explain it. Some of the patterns in “A Pattern
Language” are like this. For example, “116 Cascade of Roofs” which contains the comment:
“Why do these apparently different problems lead to the same pattern? We don’t
know. But we suspect that there is some deeper essence behind the apparent
coincidence. We leave the pattern intact in the hope that someone else will
understand its meaning.’
Can we identify patterns in the myriad if interaction design solutions that are thrown up, by
NOT looking in ways that cause us to be blinded by our conceptual dogmas?
So how forward?
So how should the development of interaction design patterns proceed? I would suggest that
this should be done at several levels, acknowledging the relative ephemeral /timeless status of
the design patterns that we propose. When we are structuring current good practice as
design patterns and pattern language we must be aware that this is a shallow and intentionally
ephemeral use of the idea. At the same time, we should have one eye on the bigger picture,
and look for timeless patterns to incorporate in our design, where the design pattern pointers
to these patterns may not have been generated within the software domain.1 For example; in
architecture, in the structure of books, libraries, paper filing systems, the practice of
typography and graphic design, painting, furniture design, agriculture, civil and mechanical
engineering, ... I.e., where a class of designed artefact has existed for many generations, and
the practitioners of the design of that type of artefact undergo a craft apprenticeship, in which
the mysteries of the craft are transmitted to successive generations of practitioners. Or more
abstractly, there must be an environment in which the pattern may evolve (perhaps, after
Dawkins, as a meme, evolving in the Darwinian sense).
It may be argued that as the pace of industrial development has hotted up — and the software
domain must be the quintessential example of this, the rapid turnover of designs means that
the evolution of substantial patterns may occur within the working lifetime of one generation
of designers. Against this, the frontiers of use of the new technology are rolling back at a
phenomenal rate, with new developments appearing on the horizon before current designs
can be fully assimilated. A contemporary example of this is the arrival on the scene of
e-commerce via interactive television, while the existing mode via the web, has not been fully
established, and other possibilities via mobile devices are waiting in the wings. In this
1
This may already have been acknowledged within interaction design practice by the adoption of metaphor as a
guiding principle. However the literal application of metaphor has been substantially discredited. The idea
may be worth revisiting, with the metaphor applied in a more abstract way, as similes, through the application of
patterns obtained from other domains.
CHI2K Workshop: Pattern Languages for Interaction Design: Building Momentum
5
tumultuous environment, it may be unrealistic to expect to identify substantial and persisting
patterns, but on the other hand, the attempt to do so may represent the only way to get a
principled grip on the requirements of good design. Thus engagement in the process of
searching for patterns may be much more valuable than any design pattern that we may
produce.
Brighton, February 2000