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
user.
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.
Harris, J. and Henderson, A. A new mythology for systems design.
CHI 99
Proceedings. New York: ACM, 1999.