A short note on the interpretation of Christopher Alexander's fifteen fundamental properties as applied to HCI design.

J. C. Thomas


1. Levels of scale.  This seems fairly straightforward.  HCI design, in
principle, spans levels of scale from aiding in the design of social structures
and large-scale architectural designs that are technologically instrumented and
enabled, through the design of applications and task support, down to the level
of making sure that fonts are visible and trackpoints have the proper damping
functions.  (See, "The Million-Person Interface).

2. Strong centers.  This is probably one of the most overlooked principles of
design in HCI.  Often, what exists for the user is a "sprawl" of functions, tool
bars, and icons with no overall or subsidiary organization.  A better design
would allow the user to quickly find a "home base" from which, it would be
obvious where other subsidiary home bases would be.  There is some sense in
which hyperbolic trees,  fisheye lenses, and home pages begin to address this.

It should be possible for users to "know where the action is" in entering an
application or a web page.

In another interpretation, this refers more to underlying architecture and
points to the need for a core of functionality that transcends a specific
release or even a specific application.  A good underlying architecture will
communicate this essential center (related to central purpose or style) to the

3. Boundaries.  Often it is not clear in existing designs what is possible and
what is not possible.  There are no strong boundaries on function or on data.
What words are "in" the dictionary of a word processor spell-checker, e.g.?
There is no intuitive way to know; only on a case by case basis can the user
explore this.  Similarly, it is not typically obvious how large a file can be
handled by a typical application program.  The only boundaries that are fairly
clear are at the very base hardware level; e.g., how much memory the total
machine has, how big the screen is.

A related concept is that of "scope."  What is the "scope" of action of an
invoked command?  It should be clear to the user before taking an action over
which actions the object should apply.  Recently, I meant to apply an action to
a single item and my finger slipped  (or the cursor drifted) to the next menu
item which applied the action to all (over 1000) such items but there was no
preview of this action!

4.  Alternating repetition.  I interpret this in the context of HCI to be nearly
identical to its meaning in the context of organizational design; that is,  to
refer to activity patterns.

Input, process, output.  Pick up the phone, answer a person?s question, put down
the phone.  Contact a client, discover their needs, make the sale.  Research,
develop, deploy.  Set the nail, tap, pound, pound, pound.  There are many
patterns and if one were to see these patterns laid out a symptom of a
well-working organization would be that these activity patterns had a rough
periodicity to them.  If they show so much variability that no pattern can be
perceived, the organization is too disorganized.

By the same token, HCI designers must understand the flow and rhythm of activity
at a variety of levels and support this.  At the intermediate application level,
for instance, we can imagine that there is a cycle to creating a document by
inputting words into a document and then editing it; then, repeating the cycle.
At a higher level, these documents may be part of a larger cycle of activity in
which input for a "fall plan" is solicited by numerous people in the
organization and then consolidated.  Perhaps, another round of input and
consolidation is included in the process.  At a lower level, the user probably
goes through a process of planning a paragraph and then typing it.  At a still
lower level, there is an alternating repetition of keystrokes.

In the physical world, animals use widespread "rebound" effects to lessen work.
For instance, the achilles tendon and the arch in humans store energy when we
run that is released in the next step.  Most of our input devices do not
currently support this kind of rhythmic action.

5. Positive space.  I interpret this to mean two things.  First, it is better to
have functionality over determined than underdetermined.  That is, it is better
to have several "alternative" ways of accomplishing the same task than to leave
"holes" of functionality that cannot be accomplished in any way.  Secondly, at a
higher level, the overall design of a system should "push" at the edges; allow
for users and teams of users to extend functionality into new areas.

6. Good shape.  At the more micro levels, this applies making shapes, sounds,
textures, etc. that are aesthetically pleasing and clear.  Equally, we can apply
the idea of "good shape" to input devices.  There are gestures of movement that
are more natural and complete and those that are less natural and less complete.
At a "higher" and more abstract level, this principle can be applied to overall
screen design, tool design, and perhaps even to the design of applications.
"Good shape" applied at the application level would mean that the parts of the
application tools help pull together to define an overall application shape.
This overall "shape" helps a user understand "where" particular functionalities
would be found and how the various functions fit together.  Typically, "editing"
a document, "filing it" and "creating" it are all portrayed as single menu items
in some fairly arbitrary menu hierarchy.  But, how does this contribute to an
overall "shape" of the application?  It doesn't.  We could imagine instead that
if there were one or more models of the overall document creation process, that
the various functions could fit within and help define this overall model in
some abstract, and quite possibly, in some concrete way.

7. Local symmetries.  Generally, if there is a method to move "up" there should
be a symmetrical method to move "down."  If there is a method to paint the
foreground, there should be a method to paint the background.  If there is a way
to make an object larger, there should be a symmetrical way to make it smaller.
As I interpret it, the HCI design principle should be applied both to
functionality (symmetry of function) and to implementation (the *way* in which
the functions are invoked should be symmetrical).

8. Deep interlock and ambiguity.  Ambiguity?  Surely, this is something that HCI
design should avoid. But is it?  At the highest level, if tools are
well-designed, the user should not be sure (or even consciously thinking about)
whether they are using a tool or interacting directly with the medium.  Is a
sculptor creating a vision out of the rock, or is the rock revealing to her or
him the vision that hides within it?  Is the writer creating a fictional world
or revealing a deeper truth?  Is the writer indeed, writing words or creating
images and events?  Is the musician playing notes that have been laid down or by
the composer or co-creating with the composer by discovering what is there?  Is
the scientist finding out about nature as it is or building mental constructs
that portray a world as built?

The way I interpret "Deep Interlock and Ambiguity" as applied to HCI design is
not that (at least typically) it should be unclear what a command does,
(although there may be an occasional place for this) but that really good HCI
design should support the kinds of ambiguities and interlocks that are
characteristic of "creative flow."

9. Contrast. At a fairly micro level, this can refer to such mundane but
essential elements as ensuring sufficient contrast between characters to be read
on a screen and the background.  In general, any two importantly different
events from the user's perspective should be sufficiently contrastive to ensure
that the user can perceive the difference.  This would seem like a fairly
obvious principle of user interface design, yet there are many cases where,
e.g., it is not clear to the user whether a "message" from the system is a
message that essentially means, "Everything is fine and we're just letting you
know that" from a message that essentially means, "You are in deep trouble and
you'd better do something soon." !!  In terms of pragmatic contrast, the words
form categories of similarity and difference that are appropriately contrastive
for the system designer, but not at all for the end user.

10. Gradients.  I see at least two good applications of this principle.  First,
in terms of finding things and organizing things, it is typically better to have
things organized and searchable by gradient than by category.  For example,
being able to list files alphabetically, by recency, by size, by importance are
four ways of graded category and search.  This is more amenable to the way human
memory and the application of decision criteria typically work than by forcing
exact queries.  "Give me all the files that were created after April 1, 1999 and
have 'Alexander' in the title" may miss exactly the file I'm looking for that
was actually created March 31, 1999 and was titled, 'fifteen properties.'  The
creation of semantic gradients would greatly help in the search and organization
of vast quantities of information.  In (my personalized) semantic gradient,
'fifteen properties' would be very close to 'Alexander,' whereas in the rather
arbitrary alphabetic gradient, they are very far apart.

Again, we can interpret some pieces of the current generations of HCI designs to
incorporate some aspects of this in such innovations as fisheye views and
hyperbolic trees or dynamic queries.

Secondly, the actions that users take should form natural gradients.  When we
walk through the physical world, we move continuously through space (except when
we fall off a cliff or trip over a branch -- situations we like to avoid in the
natural world, though the computer world seems full of them!).  As we swing a
club harder, the club moves faster, at least up to a point.  As we put more
effort into throwing a rock, the faster and farther it goes (and the more likely
to kill a prey or drive off a predator).

There are aspects of this in current interface design; e.g., the longer we move
a cursor, the further it goes; the more times we hit the "bigger" function, the
bigger something gets.  But there are many areas of action where this breaks
down at every level of design.

At the micro-level, most input devices are oblivious to the dynamics of motion.
Hitting the "T" key harder doesn't produce a darker "T" on the screen, e.g.
Shouting at a speech recognition device simply makes it less likely that our
words will be correctly transcribed.  At the outset, most input devices
immediately translate our inherently and naturally (not to mention sophisticated
and sensitive !) analog motions immediately into digital form (presumably
because that is what is easier for the computer to deal with).

11. Roughness.  Austin Henderson and Jed Harris (CHI 99) argued eloquently that
systems should be designed with this quality (though they did not label it as
such).  An example they gave was of a paper invoice system a company used.  In
order to "increase efficiency" the paper invoice system was computerized.  What
really happened was that the people now have to use both systems.  They are
required by the company to use the new, expensive, computerized system, but in
order to actually get work done, they still have to use the paper system.

Both systems use forms and ask for specific information types to be put into
those forms.  But in the paper version, people may use "roughness"; e.g., in one
situation, where the "address to be delivered" was to be input, the user wrote a
notation that before delivery, the dispatcher should call a specific telephone
number to determine where the delivery was to be made (because it was a ship
visiting different ports).  But, in the "intelligent" computerized version, such
a notation was impossible because "Call 914-784-7561 and speak with Mr. Thomas
to determine the current whereabouts of this ship" is clearly not an address; in
fact, it doesn't even fit in the allocated space.

Roughness is an especially good property when one considers architectures that
are to support cross-cultural adaptations.  To take just one obvious example,
the number of "bits" required to specify an English character set is not
appropriate for most Asian languages.

12. Echoes.  This property offers an excellent potential method for teaching a
complex system.  If there are echoes of complex advanced function or overall
design within the setting of a small, confined first application or small
function set, the transition of the user from novice to expert can be
facilitated.  For instance, if a small introductory word processor includes
functions for making characters larger or smaller, might it work for this to
foreshadow that graphics functions and more abstract functionalities also allow
changes in scale, similarly evoked?

13. The Void.  Christopher Alexander writes (The Nature of Order, Part I, p. 80)
?In the most profound centers which have perfect wholeness there is at the heart
a void, which is like water, in infinite depth -- surrounded by, and contrasted
with the clutter of the stuff and fabric all around it....Is there a way that
the presence of the void arises mathematically, as part of a stable unified
structure, or is it merely a psychological requirement?  It is the latter.  A
living structure can?t be all detail.  The buzz finally diffuses itself, and
destroys its own structure.  The calm is needed to alleviate the buzz.?

One obvious interpretation of how this might apply to HCI design is to point to
the danger of over-optimizing and re-engineering.  This is another way to
conceptualize the point that Harris and Henderson made.

Another interpretation is that there should be a place for the individual team,
the individual user, and the individual role of the user to "fill in" with
specific function.  A fairly trivial example of this is simply that most
"spell-check" dictionaries and Automatic Speech Recognition facilities allow the
user to add their own vocabulary elements.  Many systems also allow the user to
store their own objects, functions, macros, etc.

14. Simplicity and Inner Calm. Christopher Alexander (Ibid., p. 85) writes
"Everything essential has been left; nothing extraneous is left.  But the result
is simple in a profound sense, but not in the superficial geometric sense.  So
it is not true that outward simplicity creates inner calm; it is only inner
simplicity, true simplicity of heart, which creates it."

Amen.  This seems to be crying out against "feature-creep" --- the adding of the
union of whatever features any competitor actually has or has pre-announced and
whatever features any programmer on the team has time to program regardless of
whether such features add to the actual utility of a system, application, or
widget.  The lack of simplicity and inner calm is even more apparent when needed
aspects of a system are not allowed for in the basic architecture and must be
"hacked in" later.  So, it would seem that the architecting for breadth and then
being austere in implementation might be one heuristic for achieving this.

15.  Not-separateness.  In HCI design, this seems to reflect the following
interconnected set of notions.

Users do not come alive at the instant they begin using your system and die when
they exit.  They come with preconceptions and the system affects their lives
outside and after interacting with your system.  This is most dramatic, perhaps,
in the case of Repetitive Stress Injury, but applies more subtly in various
other cognitive and perceptual domains as well.  What is the impact of
continually placing the sensitive analog body movement capabilities against the
crude, digital, discrete world?

Information, artifacts, and results do not live only in the space of the
computer system we are designing.  I visited a lab with Lewis Branscomb (former
Chief Scientist of IBM) once where we were being shown a new printer.
The printer was cheap and produced a curly, silver piece of paper about 5 inches by
4 inches.  Lew asked the inventor, "what will the person do with this piece of
paper after he gets it off the printer?"  It was clear that the inventor had
never considered this question.  There was no existing infrastructure (folders,
binders, etc.) to support the collection and use of curly, silvery, 5" by 4"
pieces of paper.

Further examples of considering the "ecological validity" of design can be found
in Thomas and Kellogg.

I think that the fifteen properties may serve as guiding principles to be used
in conjunction with the development of a more specific "Pattern Language" for
HCI.  The current draft is merely a first attempt and could benefit greatly from
Dialogue and critique.


Thomas, J.C. and Kellogg, W.A. (1989). Minimizing ecological gaps in interface
design, IEEE Software, January 1989.

Harris, J. and Henderson, A. A new mythology for systems design.  CHI 99
Proceedings. New York: ACM, 1999.

A position paper prepared for the Usability Pattern Language Workshop at Interact '99