Abstract
The relations among graphical representations, computer
functionality, and everyday objects are more complex than
terms like "the desktop metaphor" may suggest. While
metaphors in the everyday world highlight similarities
between preexisting entities, interface metaphors create
new ones. New computer entities can also be created
without metaphor, when existing elements are combined
by conceptual structuring. Naming such constructs,
however, may involve yet another metaphor, between the
functionality suggested graphically and that implied by the
name. In sum, interface representations - which can only
be called "metaphors" metaphorically - are complex and
confusing, but this leads to a flexibility and power that may
be lost if simpler mappings are used.
Keywords:
mapping, metaphor, semiotics
Introduction
Graphical interfaces are typically thought to be effective
because they use metaphors to everyday objects in order to
suggest their functionality. The relations among computer
functionality, graphical representations, and everyday ob-
jects are more varied and complex than this may suggest,
however. In this note I discuss some of the issues involved
in creating representations of computer functions to show
that the "desktop metaphor" is really a complex web of
mappings.
METAPHORS IN THE EVERYDAY WORLD
Metaphors are linguistic devices in which the similarities
between two things are highlighted by referring to them as
equivalent - for example, "I am an island," or "painting the
town," or "family tree" (top of Figure 1).
Metaphors typically compare things that have preexisting
identities, both conceptually and in appearance. Thus they
are easier to create linguistically than graphically.
However, graphical metaphors can be created, for example
by combining the appearances of the two concepts to be
compared (e.g., the graphical "family tree" at the bottom of
Figure 1). The ability to do this without changing the
sense of the metaphor suggests that two different mappings
are relevant. The metaphor itself is a conceptual
mapping between the two ideas, while
independent perceptual mappings
relate each of the ideas to its
representation as a word or picture [2]. Though in most
cases metaphors create new concepts only temporarily, for
the duration of a sentence, occasionally new entities such
as family trees are created that take on an existence of their
own.
FIGURE 1. Metaphors are conceptual
mappings independent from the
perceptual mappings used to express
them.
METAPHORS IN COMPUTATIONAL WORLDS
Metaphors work differently in computer interfaces than in
the everyday world. Whereas linguistic metaphors usually
highlight similarities between existing entities, interface
metaphors like "buttons" or "windows" serve to define
new ones.
Two classes of attributes can be distinguished for everyday
and computational entities [1]: appearance
(e.g., "round, appears to afford pressing") and
functional (e.g., "performs some task when
activated"). In the everyday world, the relation between
appearance and functional attributes is often very close
because objects' physical structures are lawfully related to
their perceptual appearance. For computer entities, in
contrast, the relation between their appearance and
underlying functionality is almost entirely arbitrary and
must be designed.
FIGURE 2: Metaphors can fuse form and
function.
After all, graphical displays (such as icons) have perceptual
attributes but no functional ones. Computer entities have
functional attributes but no perceptual ones. Interface
metaphors allow the relations between functional and
appearance attributes to be created for interface objects by
a conceptual mapping between the functional attributes of
the computer and an everyday analog (Figure 2). By
designing a display's perceptual attributes to be similar to
those of an everyday analog, the display can
simultaneously suggest a conceptual mapping between the
functional attributes of the software and the everyday
analog, and at the same time create the relation between the
display's perceptual attributes and the software's
functional ones.
The result is that the metaphor acts to fuse the represen-
tation and software so that the graphics gains the functional
attributes of the software, and the software the appearance
attributes of the graphics. The two become one, producing
a new sort of graphical entity that, unlike pictures, has
functional attributes as well as perceptual ones, affordances
as well as appearance.
Moreover, if this process of fusing graphics and software is
successful, the role of the metaphor is complete. The com-
puter entity no longer needs to be understood via an every-
day analog, but instead can be understood directly as an
item with functions and appearance. Thus interface objects
such as buttons, windows, files and folders exist indepen-
dently from their real world counterparts. After fusion,
they are no longer metaphors, but objects in their own
right.
NOT METAPHOR
Once new interface entities with both appearances and
functions have been created using metaphor, they may
themselves be joined via conceptual structuring
to form more complex constructs. This is not a
metaphorical process, but one of building from simple
elements. Just as data structures can be defined from
lower-level variables, so can interface objects having no
analogs in the everyday world be constructed from simpler
elements. For instance, tool palettes are created by
combining sliding surfaces, icons, and buttons to create
new entities with no obvious analogs.
The perceptual mappings between the appearances of com-
puter entities and those of their everyday analogs are not
metaphorical either. For instance, a conceptual button in
the model world may be given perceptible form on the
computer display by a picture of a button or by the word
"button," neither of which involves a metaphor. Instead, a
picture of a file involves an iconic mapping to the concep-
tual file, while the word "file" relies on a symbolic
one [2]. True graphical metaphors (such as the
family tree in Figure 1) are used only rarely for perceptual
mappings, and when they are they usually take the form of
metonymy, in which parts are used to stand
for wholes (e.g., when the letter "A" is used to stand for a
text-writing tool in graphics programs).
Finally, when iconic mappings indicate components of an
interface structure, it is more appropriate to think about the
expression of that structure than a metaphor. From this
perspective, graphical indications that a button may be
pressed or that menu items may be selected need not
depend on metaphors to buttons or menus. Instead they
use the same sort of perceptual information about the
layout of objects and surfaces that allows affordances to be
perceived in the everyday world. At this level, the concept
of metaphor applies only loosely and not very usefully.
MIXED METAPHORS: NAMES AND GRAPHICS
The situation becomes more complex still when graphical
entities are named. In some cases (e.g.,
buttons) names and graphics suggest the same
functionality. But in others (e.g., windows) the graphical
devices used to create them - such as scrollbars, buttons,
and the title bar - express different functions than those
suggested by the name. Comparing these two sets of
implied functions, however, allows the true functionality of
software windows to emerge. For instance, scrollbars'
graphical suggestion of changing something, and window's
suggestion of views as something to be changed, are
mutually responsible for expressing an aspect of graphical
windows' functions.
From this perspective, names can introduce a second layer
of interface metaphor, one between the functionality ex-
pressed graphically and that suggested by the name (Figure
3). Metaphors from the everyday world may convey un-
wanted implications about functionality (e.g., buttons may
not appear movable). Graphical expressions of novel
structures (e.g., windows) may not be able to convey all
the functionality being offered or to provide it with a
unified identity. Using both names and graphics allows two
models to both add to and constrain one another.
FIGURE 3. When names suggest different
functionality than graphics express,
software functions depend on the mix.
CONCLUSION
Calling the sorts of representations created by interface de-
signers "metaphors" is itself something of a metaphor. As
I hope to have illustrated, the mappings involved are more
complex and varied than can be captured so simply. Their
complexity should be embraced, however, since it allows a
flexibility and power that simpler, easier to conceptualize
mappings may lose. For understanding interfaces, it is im-
portant that we untangle our metaphorical web. For
designing, it is important we do not.
ACKNOWLEDGEMENTS
I thank Martin Locker, conversations with whom inspired
me to write this paper. I also thank Colin Burns, Gillian
Crampton-Smith, and Anne Schlottmann for comments.
References
[1] Familiant & Detweiler (1994). Iconic reference:
Evolving perspectives and an organizing framework
International Journal of Human-Machine
Studies.
[2] Gaver, W. (1989). The SonicFinder: An interface
that uses auditory icons. Human-Computer
Inter-action 4(1): 67-94.
