by Katalin Szabó
The word "metaphor" is well known. A widely quoted example for it can be found in Shakespeare's As You Like It: "All the world's a stage...".
It is originally a Greek word which means "carrying across". The essence of metaphor is to give an idea of some unknown thing or concept, by illustrating it with something else which is known and which originally has nothing to do with it. The metaphor identifies the two things with each other, for the purpose of illustration. In fact the metaphor is an error committed on purpose, because the two things which are said to be identical are in fact not identical.
It technically differs from the simile: it is an implicit simile in which the fact of comparing is not explicitly mentioned. The metaphor in the broader sense includes the simile (and the allegory, the hyperbole, the symbol etc.) as well. In this paper the word 'metaphor' will always be used in this broader sense. The important point is the figurative speech.
The metaphor puts aside the conventional expressions, it takes us back into the pre-verbal world from where the words and concepts emerged.
As Fig. 1. shows, the metaphor is usually directed (the arrow cannot be reversed). Metaphors can be found not only in poetic and dramatic works of great literary value. They are also a part of our everyday life and of journalism. Its role in literature and in rhetorics is to illustrate the imaginary, the unknown with something concrete and known, to evoke associations in the reader/listener to enrich the impression. The role of the metaphor in science is to illustrate the unknown, not easily imaginable things. An example for the scientific metaphor is Rutherford's model of the atom which compares the structure of the hydrogen atom to the solar system. Metaphoric thinking dominates in those early phases of scientific thinking (like during formulation of a new theory) when the scientist does not yet see clearly and thinks in metaphors. The formulation of metaphors usually precedes the formulation of clear concepts .
There are several sciences dealing with metaphor: poetics, linguistics, aesthetics, psychology, semiotics, philosophy, cognitive science etc. It is worthwhile to mention that the field of artificial intelligence could not yet integrate metaphoric thinking, so far it seems to be an essentially human feature. Perhaps the reason is the constant changing of the systems of reference: the metaphor is constantly putting "something" into the reference system (i.e. "world") of "some other thing" - and there are lots of possible systems of reference.
When people encounter something new which they want to learn, then they try to fit it into their knowledge structure, using their already acquired knowledge about other things. E.g. in the case of learning the use of a word processor program, if the person involved already knows other word processors, then he/she initially would compare it to them. If she does not know such similar programs, then he/she would probably relate the word processor to the typewriter, and also it would probably be easier to teach him/her the use of the word processor if we compare it to the typewriter. Thus the "world" of the word processor will not be so unfamiliar (there are letters, space and shift keys on the computer's keyboard as well as on that of the typewriter etc.) Thus, if you are at home in one "world", and you are told that a new "world" is to some extent similar to an already known one, then you will probably learn to find your way in the new "world" faster.
So the use of metaphors may facilitate learning. This is not a new discovery. The use of metaphor was regarded as an easy and enjoyable form of learning by none other than Aristotle .
The metaphors' role in the user interface is to facilitate learning, orientation, and the forming and maintaining of the concept about the program i.e. the mental model.
In our former typewriter example, if somebody has learned the use of the word processor program through the typewriter metaphor, then later he/she will be able to switch from the typewriter to the word processor and back - provided that the layout of the keyboard is the same in both cases.
The case when there is a discrepancy, i.e. the correspondence is not complete, is called mismatch. Such mismatches inevitably occur with every metaphor, because the two "worlds" cannot be the same in every way (otherwise they would be the same "world"). However, it is important that the mismatches should not come as surprises to the user. He/she should be well prepared for them (e.g. by a training course, a learning aid, a user's guide, a visual cue etc.). Also, the extent of the mismatches should not be so great or of such a nature that would "kill" the metaphor. In our typewriter example: if the keyboard layout is not the same, e.g. the letters Z and Y are interchanged, this already makes the use a bit harder. A drastically different keyboard layout may totally confuse the user. But users can easily accept such mismatches as the word processor providing additional services in comparison with the typewriter (e.g. insertion or relocation of text, or the different possible appearances of the printed form of text).
If the program - or a part of it - can be related to - or identified with - an object of everyday life, then the user will easily be "at home" with it. The most widely used such metaphor is the desktop. A significant part of office systems is based on it. The program, as it appears on the screen, is identified with the top of an office desk, on which documents and tools can be placed. Documents can usually be seen in individual, partially overlapping "windows", as if they were partially on top of each other. Documents can be arranged into "folders", they can be modified, appended to each other, destroyed etc.
It is an accepted practice to use composite metaphors. A program may have an overall, global metaphor (like the desktop mentioned above), and besides or within that, it can have other sub-metaphors assigned to subtasks or operations (e.g. the concept of carbon copy in an e-mail system).
A lot of metaphors have already been quite well integrated into the minds of people working with computers. They don't even think of them as metaphors any more. E.g. the pointer appearing on the screen is such a metaphor: we don't physically point at the screen with our finger or a stick, instead we move a little box - the mouse - on the table, and this results in the moving of an arrow (or some other graphical symbol) on the screen.
This section is based on the ideas outlined in .
If we develop a new user interface, it is not a bad idea to base it on one or more metaphors. If we don't consciously use metaphors, the users would almost surely try to compare the system to something they already know, and possibly their metaphors will not be so appropriate (comprehensive, consistent etc.) as ours. There is no need to find a new metaphor for every new system (e.g. the desktop metaphor, which was originally used by Apple, has been used in a lot of systems since).
Work out the details of the use of each metaphor, with the aid of typical user scenarios. Imagine how people would use the system while achieving specific goals, and how they could rely on your metaphor during the course of their activity.
Identify the points at which the mismatches occur. Think over the implications of these mismatches. The discrepancies should always be explicable and manageable. E.g. in most systems using the desktop metaphor, we do not write into a document by picking up a pen but we use the keyboard instead (which is analogous to putting the paper into a typewriter). If once we demonstrate it to the user, then he/she will able to accept it, and will use the system accordingly. However, if the mismatch is too strong, disturbing, not easily manageable, then the metaphor should be abandoned.
This concerns the issue of how to help the user in handling the mismatches.
It is very advantageous if we enable the user to explore the system without risk. There are means to achieve this: help function, error and informative messages, tool for training, documentation, escape & undo function etc.
The abovementioned four steps may occur multiple times in the course of design and implementation, as development is usually an iterative process.
Most of the metaphor problems - as most interface problems - cannot be discovered in a purely speculative way. That is why so many experiments, tests are made during interface development.
It is not sufficient to find good metaphors which are consistent in themselves. They should be consistent as a metaphor system, too (e.g. the user should be able to "pick up" things on the whole desktop in the same way).
A potential pitfall is to overburden the user with unnecessary, functionally irrelevant details of a metaphor .
It is worthwhile to note that, unlike metaphors in literature (poetry etc.), interface metaphors are not necessarily verbalised. When I sit in front of a computer and use the services of a "desktop" system, e.g. I open a folder and take out a document, I do not have to verbalise what I do ("now I open the folder") while giving the necessary instructions to the machine. It is sufficient to perform the act itself (or rather, execute the equivalent of the physical act in the world of the desktop, i.e. drag the mouse, click etc.). Thus, in the use of interface metaphors, no verbal communication is necessary. This makes the use of interfaces faster. In a sense, when we use the interface, we are in the same state in which small children are, before their verbal abilities are developed (this does not mean that we are infantilised: in our everyday life we are quite often in situations when we do not use our verbal abilities).
According to the author's knowledge, the desktop metaphor was first used by Apple, in its Macintosh. This has been a very successful metaphor (with icons representing documents and folders, direct manipulation etc.) and it has been used in a lot of systems since, e.g. in Microsoft's Windows, a lot of graphical workstations etc.
One element of the Macintosh desktop is the trash can.
When we are using the Macintosh desktop and we want to get rid of a document because we no longer need it, we "grab" it with the mouse, take it above the trash can and release it i.e. drop it into the can. The document will stay in the trash can until we explicitly empty the trash can or until we recover the document from it (if we change our mind about it and decide that we need it).
The trash can is a very appropriate metaphor, which nicely fits into the desktop metaphor. It is not bothering that usually people do not keep their trash cans on the top of their desks (and there actually exist some trash cans which can be attached to the side of the desk, not to speak of ashtrays which are actually on the desk).
However, there is an aspect to this trash can which has been widely criticised. (The author has encountered some other desktop systems which also have the trash can, but this aspect was present in none of them.)
The problem is the following: if, in the Macintosh, there is a diskette in the drive, and we want to take it out (i.e. we want to have it ejected by the system), then the icon symbolising the diskette has to be grabbed, and dropped into the trash can! There is no EJECT button on the machine or on the desktop.
A lot of people feel badly about this. Even some experienced Macintosh users talk about an uncertain feeling experienced before ejecting the disk: maybe the contents of the diskette would be erased? Some resolve the problem by switching off the whole machine (then the diskette is ejected automatically).
It can be said in defence of the system that throwing the disk into the trash can means simply that we take it out of the "world" of the desktop (of virtual reality, if you like), and put it into our "real" world. This argument does not really dissolve the uneasiness of users, but it weakens the trust in the desktop metaphor.
What is the explanation of the feeling of uneasiness that users experience when they throw the disk into the trash can - even though they know very well that no disaster would happen?
Nearly every user has already been in the unpleasant situation when he/she accidentally erased files which he/she wanted to keep. Thus, if a situation occurs when files which are intended to be kept are somehow associated with an operation (the throwing into the trash can) which has something to do with destroying, this evokes unpleasant feelings. Caution is deeply embedded in humans. Let's take an example which is valid for prehistoric man as well as for us: collecting mushrooms. If a harmless mushroom is mistaken for a poisonous one, no tragedy occurs, while mistaking a poisonous mushroom for an edible one may have serious consequences. Thus, most people would rather "stay on the safe side". In the case of the Macintosh desktop: some users would rather switch the whole machine off than throw the diskette into the trash can. This human trait should be taken into account by interface designers.
For illustrative purposes, let's take two examples (to the author's knowledge, these ideas have not actually been implemented yet):
The Internet is quite a novel phenomenon, rapidly appearing in the everyday lives of millions. It is only natural that computer professionals and ordinary people alike have tried to compare it to other things, in order to grasp what it is all about. Here are some metaphors for it:
The information superhighway metaphor will be discussed later.
There are people who say that this metaphor is in fact too good. They caution that the asphalt highways were made not on popular demand but under the pressure of lobbies of auto manufacturers and road builders. At that time (in the fifties) only every second American household had a car, others used the public transport. The negative consequences of the Internet are potentially the same as those of the asphalt highway system: people are forced to buy a lot of expensive technical gadgets; isolation; the widening of the gap between rich and poor; the shifting of decision-making from local democracy to larger global centers.
Some criticise the highway metaphor because they think that travelling is not the point here : we (hopefully) don't spend too much time travelling, we rather "jump" from one place to the other, and the important point is what we see on these places.
To illustrate these "magic jumps", we can borrow metaphors from tales. The author thinks that the Internet, as it manifests itself to the user, can be regarded as a magic carpet: We just express our wish where we want to be - and we can "fly" there in practically no time.
 Világirodalmi Lexikon (Encyclopedia of World Literature, the entry on "metaphor") Akadémiai Kiadó, Budapest, 1982 (in Hungarian)
 Carroll, J. M. - Thomas, J. C.: Metaphor and the Cognitive Representation of Computing Systems
IEEE Transactions on Systems, Man and Cybernetics, SMC-12 No.2., 1982
 Carroll, John M. - Mack, Robert L. - Kellogg, Wendy A.: Interface Metaphors and User Interface Design, in: M. Helander (ed.): Handbook of Human-Computer Interaction, 2nd. ed., North-Holland, 1991
 MacLean, Allan - Bellotti, Victoria - Young, Richard - Moran, Thomas: Reaching through Analogy: A Design Rationale Perspective on Roles of Analogy, in: Proceedings of CHI'91 (New Orleans, Louisiana, April 28 - May 2, 1991), ACM, New York, pp 167-172.
 Rohrer, Tim: Feelings stuck in a GUI web: metaphors, image-schemas, and designing the human-computer interface - or - Metaphors we compute by. bringing magic into interface design
 Dieberger, Andreas - Trump, Jolanda K.: The Information City - A Metaphor for Navigating Hypertexts (recent research paper at BCS-HCI'93, Loughborough, September 1993) also available as
 Dieberger, Andreas: Spatial metaphors in interface systems
 Sjoerd, Michels: Metaphors in the interface
 ISWorld Net Metaphors
 Sclove, Richard - Scheuer, Jeffrey: The Ghost in the Modem - For Architects of the Info-Highway, Some Lessons From the Concrete Interstate, Washington Post, May 29, 1994. also available as
 Souder, Mick: For Users, "Information Highway" is a Bad Metaphor
 Jaramillo, Narciso: Internet metaphor du jour