Patterns as Mechanism in HCI
Austin Henderson
Rivendel Consulting & Design, Inc.
PO Box 334
La Honda, CA 94020, USA
+1 650 747 9201
henderson@rivcons.com
ABSTRACT
The growing role of patterns a basis for capturing
computational regularities in HCI is being offered as a
means for describing interfaces, their components and their
behaviors. The description has effect through the
elaboration of design and the implementation of coding.
This paper suggests that with appropriate framing, patterns
can become the mechanism for realizing interfaces. Further,
by making patterns accessible to users, design of interaction
to meet local needs and tastes can be put back into the
hands of users.
Keywords
Patterns, interaction implementation
this work, other people interact with them to get help.
A BIG GOAL: PLIANT COMPUTING
Computer applications are ontologically disengaged. The
ontology of an application is fixed: it is crisp, unmoving
and single-minded. The implementation of applications
embodies this fixed ontology; but because it will never
change, it need not be made explicit, and need not be
expressed in the code. The ontology is compiled into the
code; the code is unaware of it. Therefore applications are
neither able to present their ontologies to the user (help
systems can, but those descriptions are inherently
disconnected from the application) nor able to interact with
users to change them.
In contrast, people's use of computer applications is
ontologically engaged. Usage is dynamic: the world
changes, the needs change, the meanings of things change,
the use to which applications is put changes. The world is
multi-perspective: collaborating users with different views
must bring those views together. Living in the world
requires ontological engagement: what things mean is at the
center of existence.
This mismatch between computation and the use of
computation over the engagement with ontology puts heavy
burdens on users. Since computers are not engaged with
their own ontologies, and users must be, all the ontological
work of dealing with a dynamic and multi-perspective
world must be done by the users, without computational
help.
We have suggested ( and 1999) that there is no need for
this to be the case. We have argued that this choice can be
made differently and that computation could be re-invented
to be ontologically engaged. We have offered patterns as a
possible basis for this new computation.
Therefore, my deepest interest is in how the intuitions
arising from Pattern Languages for describing HCI can be
used as a basis for making the applications created with
them ontologically engaged. That is, if patterns are used to
describe, and ultimately create aspects of applications (e.g.,
the UI, the user's conceptual model, even the structure of its
intended use), then possibly those patterns can be made
accessible to the user in support of use. And if the coupling
between description and implementation can be made
causal, so that changing the patterns can change the
implementation on the spot, then possibly the user can be
given the power to modify the application to suit their
needs.
FROM PATTERNS TO IMPLEMENTATIONS
Patterns as partial descriptions
The idea of patterns is that they are partial. The intuitions
are that:

they apply to some domain (e.g., a house, an interactive
computer application);

each captures a regularity of some sort about the
domain; the regularities can be at many different sizes,
about many different aspects of the domain;

they combine to describe things in the domain; the way
they combine is by situations left unspecified in one being
matched and specified by others.
When patterns are used for describing an existing situation,
the description of composed patterns is inevitably
incomplete; there is more detail present in a domain
situation than is specified in the patterns. Patterns are
importantly partial.
Pattern enactment frameworks
When patterns are used for creation, all the detail not
supplied by the patterns must be supplied by the creation
process. This, to date, is the job of the designers who are
using patterns. What we must do is find the computational
framework that will supply this information, or permit
users, in the midst of their situations, to supply it.
Much too hard for now
However, for this workshop, I think this is much too large a
goal to tackle. We need a much more modest place to start.
has happened from the context, or must the number pad
itself show this?

Is the right idea to use a single "undo" button, that
takes back the last action, whatever it is? What about
undo of undo?

For "pre-defined" jobs, the number of copies may be
different from 1. Therefore, the context may require the
idea of "starting" the number pad at a number different
from 1. Is it in reset mode (so pushing 3) means 3, or in
entering mode, so 3 and delete work on the last digit
only?
A SMALLER START: UI TOOLKITS
I have experience in creating open-ended architectures for
human-computer interaction (HCI) and in creating toolkits
for designing and building user interfaces based on those
architectures (1986).
My intuition is that the regularities expressed in HCI
architecture and captured in the interface toolkits are the
stuff of interaction patterns. I would like to see if this is so.
I have no experience in creating such patterns. I would like
to use this workshop as a chance to explore the relation
between the regularities built into toolkits and those
expressible as patterns.

NUMBER PAD

construction of a number from digits

presentation of numbers in place-value notation

correction of error, or supporting change of mind, by
In the work on Trillium, I was amazed at the complexity of
something as seeming simple as the number pad that
appears on a photocopier.
Issues
There are a number of things going on here, even in this
relatively simple interactional element.
Simple story
There are 11 buttons and a display. 10 buttons are the
digits, and one ("C" for clear) is used to reset the number
pad. The activity is:


pushing a digit button causes the corresponding digit to
be slid in from the right and the number moved over.
Computationally, the number in the display is multiplied
by ten and then the corresponding digit added.

starting over

backing up one digit

backing up one button push

default values

timeouts

pushing the clear button resets the number pad to 1.
Complexities
How do we convey all this to the user?
as a design issue, we must decide at what point is it not
worth the effort? After all, resetting, and entering the
number again in its entirety is not very much work.
However, the complexity now begins to rise:
The behavior we see in the resulting design is responsive to
all of these influences.

Patterns
following a reset, pushing the 3 button does not slide in
a 3 from the right to give 13. It replaces the 1 left by the
reset with the 3. The argument is that the reset should be
to 1 because that is the default value. If the user walks up,
and ignores the number pad, they will get one copy.
However, if they explicitly ask for 3, they should get 3.
It seems there could be a number of different ways to
approach this with patterns:

a single pattern for entering a number and supporting
resets, defaults, and changes. The number pad would be
an answer, and all the internal details left unspecified. The
pattern would be of value in capturing the regularities
around the notion of entering a number.

what happens if the first digit hit is 0? Should the
number be set to 0, or left at 1?

some number pads have a 12th button ("D" for delete)
which is used for correcting mistakes. That is, after hitting
2,4,7 and seeing 247 in the display, if the user hits delete,
they are back to 24; and then, to 2; and then to what: 0? or
1? And if 1, should the pad be regarded as reset, so that
the first digit subsequently entered replaces the 1?

a single pattern giving all the details of the number pad.
This feels too specific and narrow.

a pattern for each of the issues listed above. These
would each address a much broader point, and could use
the number pad as an example.
As there are two different behaviors when 1 is showing
(when reset, and when 1 has been hit), how does the user
know which they are about to get? Should an additional
indicator of some sort be given showing that this is the
default or this was explicitly entered?
The last of these is most attractive from an architectural
point of view. However it raises the issue of how patterns
are combined very strongly.


The context may also force a reset: most copiers time
out, and all the values are reset. Can the user tell that this
CONCLUSION
I would like to understand how the patterns for individual
dimensions can capture the regularities of interfaces of
which the number pad is an example. I would like to
understand how these patterns are combined to produce the
number pad in all its complexity as a special case. And
long-run, I would like to understand how we can build
computational mechanisms that would support designers,
ultimately including users, in creating number pads and all
sorts of variants on them.
REFERENCES
Henderson, A. (1986). Trillium: A Knowledge-based
Design Environment for Control/Display Interfaces.
CHI'86, Human Factors in Computing Systems, Boston,
MA.
Harris, J. and Henderson, A. (1999). A Better Mythology
for System Design. CHI 99: Human Factors in Computing
Systems, Pittsburgh, PA, ACM.