Metaphors (literally: carrying across) are an important kind of learning, used quite often in teaching. In teaching, the instructor chooses some concrete situation with which the student is familiar and presents new information in terms of how it relates to the old familiar information. In general, human-computer interfaces incorporate many metaphors in order to make the computer more usable.
The notion of employing metaphors for interface design has partially replaced the notion of the computer as tool with the idea of the computer as a representer of a virtual world or system, in which a person may interact more or less directly with the representation. As Weiser [1994] explains, a good tool is an invisible tool. Of course, tools are not invisible in themselves, but as part of a context of use. As an example of a good tool, he mentions eyeglasses: you look at the world, not at the eyeglasses. Laurel [1993] stresses this point: action occurs in the mimetic context and only secondarily in the context of computer operation.
Carroll et. al. [1988] have formulated a theory of metaphor use. They define three stages of metaphorical reasoning, each associated with different kinds of cognitive activity:
Instantiation is the recognition or retrieval of something known which can be translated to the new computerised domain. For example, in the desktop metaphor, icons of folders would assist a human's instantiation of a desk top. A metaphor may be instantiated on the basis of surface similarity whereas in other cases, the similarity of tasks and goals is the basis for instantiating a metaphor.
The second stage, elaboration, involves the generation of inferences about how an instantiated source can be applied to the target domain. It is a more detailed analysis of an instantiated comparison. An important aspect of this stage is exploration of possible ways, based upon prior knowledge, in which the metaphor could be applied. This stage is also used to identify mismatches between the source domain and the target domain (Eberts [1994]) which, as will be made clear later, are inevitable. When an action based on an elaboration of a metaphor fails, other inferential processes, not based on the metaphor, may be called in to repair it. If the mismatch is succesfully resolved (i.e., a succesful plan is created to repeat the action in a later stadium), the problem solver develops a new understanding of the target domain in its own terms.
The third stage, consolidation, provides a control structure for the other two stages. It consolidates the elaborated metaphor into a mental model of the computerised target domain itself. At this stage, the new mental model is not the same as the original metaphor; it is a new entity which accounts for the matches and mismatches between the source and the target domains. The distinction Carroll et. al. envision between models and metaphors resides chiefly in the open-endedness, incompleteness, and inconsistent validity of metaphoric comparisons versus the explicitness, comprehensiveness, and validity of the models which the succesful learner will ultimately obtain. Models are designed to represent some target domain, whereas metaphors are clearly chosen or designed to invite comparisons and implications.
Analogous to Barfield [1993], I make a distinction between real-world metaphors and artificial metaphors. You can take two different approaches when designing a suitable user model for a system: either use some metaphor from the existing world or design an artificial user model encompassing the system's behaviour and goals. An artificial metaphor is some sort of system of ideas and concepts which behaves according to artificial rules, unfamiliar in the real world (thus, perhaps 'artificial model' would be a more accurate term). Although such a metaphor is unfamiliar to the user because it is not based upon the real world, Barfield thinks it may nevertheless be advantageous to use since it could be more suitable for a particular application. In the remainder of this part, we concentrate on real-world metaphors. Elsewhere within this section, the hypermedia model is discussed which is an excellent example of an artificial metaphor.
Among others, Laurel [1993] identifies both strenghts and weaknesses regarding interface metaphors. She states that the most commonly acknowledged strength of interface metaphors derives from the naturalness and pervasiveness of metaphor in human thought and language. According to the theory of metaphorical reasoning which was presented before, if only the interface presents representations of real-world objects, people will naturally know what to do with them.
A problem with such a real-world metaphor is that it is like reality only different: (slight) mismatches between the real-world and the representation on the computer are inevitable. According to Carroll et. al., metaphors, by definition, must provide imperfect mappings to their target domains. As an example, they mention a text editor. If it truly appeared and functioned as a typewriter in every detail, it would be a typewriter! However, these inevitable mismatches of the metaphor and its target are a source of new complexities for humans which must be solved during the elaboration and consolidation stages of metaphorical reasoning. The whole new world of virtual reality that is currently opening up, may eventually provide us with novel possibilities for supplying high- quality feedback and thus the ability to support real-world metaphors to a very large degree.
Another strength of interface metaphors Laurel identifies, is coherence: all elements of the metaphor naturally belong together. None of the components contradicts with any of the other elements. However, what if a user starts looking for an associated element of the real world, which is not a part of the interface metaphor? What happens when he finds something in the interface metaphor which does not fit his idea of the real world and contradicts with the other components? In both cases the interface metaphor is a misrepresentation of the real world.
An interesting example is the well-known desktop metaphor of the Apple Macintosh computer, featuring direct manipulation of windows and other objects on the screen. It is for sure one of the most succesful interface metaphors. Nowadays its use has spread to other graphical environments, including Microsoft Windows®. Naturally, elements on the desktop go together; folders go with documents that go with type writers that go with desktops. Laurel demonstrates that there are two ways to fall of the desktop. One is, when you look for things that are on your real-world desk, but not on the metaphorical desktop, like a telephone. The other way to fall of the desktop is to find something on it that does not belong there, like the famous Macintosh trash can, which is awkwardly positioned on the desk's top though not many users actually keep a galvanized steel garbage can sitting on the near-right corner of their desks, as Marcus [1993] points out. It is doubtful whether the desktop metaphor is the right metaphor underlying groupware applications.
In the beginning of this paragraph, I already glanced at a third strength of real- world metaphors: their value in helping novices to quickly learn how to use a computer system through the application of a source domain to the target domain, the virtual environment that is depicted on the computer. However, this advantage may turn against you when the novice user has grown into an experienced user as Laurel points out: the difficulty comes in helping a person make a graceful transition from the entry-level, metaphorical stage of understanding into the realm of expert use, where power seems to be concentrated specifically in those aspects of a system's operation where the metaphor breaks down. In this context, the usefulness of a metaphorical approach can be understood as a trade-off between the reduced learning load and the potential cognitive train-wrecks that await down the track.
As Madsen [1989] argues, it might be necessary to step out from behind our desks and come up with alternative real-world metaphors. In the case of cooperative work, the desktop metaphor is no longer sufficient as the task environment has extended from the private desk toward entire organisations and even beyond their borders. The Xerox ROOMS interface metaphor and Madsen's Office Building metaphor apply this knowledge. They enable humans to shift between a number of work areas that match specific tasks.
Moreover, the user population is changing rapidly. In my definition of interfaces I mentioned this as a reason for dropping the term 'user'. This will inevitably lead to real-world metaphors which move away from the traditional office, like the kitchen interface which is described by Langford and Jones [1994]. It may also be necessary to take cultural diversity into account as Marcus explains, though Teasley, et. al. [1994] are agitated by a number of alleged compelling points and some sweeping generalizations he quite obviously makes to prove his point.
For example, Marcus concludes that women prefer 'curvilinear' shapes in dialogue boxes whereas Teasley, et. al. state that there is no published research to support this notion. Moreover, they find that lumping all 'white American women' into one cultural class (without regard to age, socioeconomic distinctions, educational differences, and so one) seems naive at best.
These notions may not directly affect The COOPerator. First of all, The COOPerator supports distributed, asynchronous interaction. The group members work at their own desks at home and would not benefit from a Rooms-like interface. However, the Magic Cap graphical communication environment, as described by Pluym [1994], offers some interesting points of view. It is equiped with three supplementary real-world metaphors among which is a virtual city; in each street of the city one sees a number of housefronts representing the relations of a co-worker. Catching this train of thought (do not get carried away), try to imagine a student actually delivering a mail message by inserting an envelope in a group members' letter-box . Second, for the time being we do not take other users than students at Tilburg University into account, thus we shall not pay attention to any cultural diversities outside its domain. Of course, numerous foreign students tread the campus site each year ...
Based on the theory of metaphor use, Carroll et. al. suggest four steps in the design of interfaces in which metaphors are used:
The first step is the identification of candidate metaphors. Eberts suggests some general features which should be present in candidate metaphors. The emotional tone of the metaphor must match the human's desired attitude. For example, instead of a parade metaphor you do not want to use the metaphor of a funeral. Also, if more than one metaphor is required to explain a system, then the metaphors should not be too dissimilar; a similar theme should form the basis for all applied metaphors. An example of such a common theme is the office. Moreover, the metaphor should be exciting! This is especially true in the case of routine work. To make the interface dynamic, so that it actively involves its audience in the scenario, some of the characteristics of games could be incorporated. Another important feature of metaphors is their spatial nature. To represent a familiar object which may be manipulated directly on screen requires highly graphical and spatial interfaces. Finally, candidate metaphors depend on the main purpose of the application program. Candidates for a single-user program should be different from candidate metaphors for a multi-user application. The prototype of COOPerator's client application proves this point.
The second step is the detailing of the metaphor/software matches for representative user scenarios. For the desk top, the metaphor specifies that program applications occur if the application is placed in the work area of the desk. Thus, on the computerised desktop, this translates into accessing the appropriate application file on the desk top and then placing it in the work area by double clicking the mouse on the application. For example, text editing and drawing occur by locating the file on the desk top and activating the application through mouse clicks. Finding the appropriate file occurs by visually searching the files on the desk top. This may involve opening and closing folders to search them.
In The COOPerator, group members can save their work but they cannot name the files in which the data is stored. The data in the graph is saved automatically. There is no need to look for particular files that represent appointments or group documents as these can all be retrieved from the graph easily.
The third step is to identify inevitable mismatches as well as their implications. Carroll et. al. suggest that a mismatch be treated as follows: the mismatch should be isolated and a salient alternative course of action should be available in the computerised target domain. Moreover, there must be something to learn and it must be possible for the intended audience to actually learn it, either on their own or with help from the designer. For example, whenever an action on some object fails, an alternative for directly manipulating the object this way should be available through a pull-down menu.
For example, one might argue whether the calendar metaphor that was used to model COOPerator's Agenda, is a good metaphor.
The designer may assist by offering on-line help and this brings me to the final step.
The fourth and final step is to design strategies to help humans manage the mismatches. Essentially, users of the system should be able to explore without penalty. While this is desirable in all software products, it is especially important where metaphor-driven mismatches in the human-computer interface are expected. Thus, not only should humans be able to solve problems arising from mismatches, they should also be able to recover from possible surprising system states (Carroll et. al.).
Strategies to help the user manage mismatches are typically included in the documentation that accompanies an application. In the (near) future, these will increasingly be designed as on-line help so that mismatches and problems may be averted before they are encountered. Among interface techniques that can contribute to exploration are escape and undo functions. At all time, a user must be able to escape from any action that he either performs unintentionally or from which he regrets the results later on. The first requires a possibility to escape, the latter demands an undo routine.
Unintentionally performed actions must be distinguished from erroneous actions: the user can make a mistake. Therefore, handling errors is an essential responsibility of the human-computer interface. Error messages should be informative and give the user insight into what caused the error so that he can learn from his mistakes and repitition can be avoided (Stuart and Aldershof-Eikelenboom [1992]).
When mistakes are made while filling in the dialogue to make an appointment in COOPerator's Agenda, a meaningful error message is presented to a group member. It should hopefully prevent him from making the same error again.
Direct manipulation makes it easier to see and reverse the outcomes of actions. Besides, it reduces the chance for errors to occur.
Metaphors applied in The COOPerator include a calendar, a real-world metaphor for the agenda, and the hypertext model, an artificial metaphor that enables and supports cooperative work. For an in-depth discussion, you are encouraged to explore the section on COOPerator's client prototype.
Sjoerd Michels, Tilburg, The Netherlands.