TY - JOUR
AU1 - Alty,, J.L
AU2 - Knott,, R.P
AU3 - Anderson,, B
AU4 - Smyth,, M
AB - Abstract Interface metaphors facilitate the learning of new computer systems by supporting the transformation of existing knowledge in order to improve the comprehension of novel situations. However, there is very little guidance for software designers on how to select, implement and evaluate interface metaphors. This paper, which is based upon extensive work in developing metaphors for telecommunications systems, provides a framework for software designers who wish to exploit the use of interface metaphors. The paper proposes a set of six design steps, to provide designers with a practical approach to the application of metaphor in the design of interactive systems. An explanation of the activities required in each step is given and justified from experience gained in developing a number of interface metaphors. A pragmatic model of the use of metaphor in human centred system design is introduced, and a technique for eliciting metaphor characteristics is developed from ethnomethodology. The approach has been discussed with software designers at two workshops, and the final content has been influenced by their input. 1 Introduction As information technology applications grow in sophistication, software designers are faced with the problem of constructing intelligible and easy-to-use interfaces, which allow users to concentrate on the application itself and not be distracted by irrelevant interface complexity. One approach to this problem, which is commonly utilised by interface designers, is that of metaphor. Metaphor involves the presentation of a new idea in terms of a more familiar one. However, although metaphor has been extensively used in interface design, there is little substantive work to which designers can turn to assist them in systematically designing better interfaces. Current Direct Manipulation Interfaces rely heavily on metaphor when presenting a coherent system image to end-users. Despite the widespread use of the technique, the literature has provided little guidance for the selection of appropriate interface metaphors. Many authors have discussed classifications or taxonomies of metaphors (Hutchins, 1989; Wozny, 1989). Others have provided well-reasoned discourses as to the merits of each (Erickson, 1990; Kay, 1990). Very few, however, perhaps with the exception of (Carroll et al., 1988), have provided interface designers and practitioners with tools for thinking about the generation, selection and refinement of appropriate metaphors for use at the human–computer interface in any given situation. As a consequence there is little practical information on how to apply metaphors in three major areas in the software design process where a consideration of metaphor is relevant — in the early design phase of the system, during its actual implementation and during evaluation. A number of guidelines exist in the literature. Carroll and Thomas (1982) initially suggested the following approach: find and use appropriate metaphors when teaching naı̈ve users; when given a choice between two metaphors, choose the one which is most congruent with the way the system works; take care to ensure that the emotional tone of the metaphor is conducive to the desired emotional state of the user; if using more than one metaphor, use examples from the same task domain, but do not choose objects which are exclusive alternatives; consider possible consequences to users and designers of each metaphor used; when introducing a metaphor explicitly point out that it is not a perfect representation of the underlying system and make clear its limitations; remember that a time may come when a metaphor is no longer useful; provide the user with exciting metaphors for routine work. Later, Carroll and Mack (1985) suggested four steps: identify candidate metaphors or composite metaphors; detail metaphor matches with respect to user scenarios; identify likely mismatches and their implications; identify design strategies to help users manipulate mismatches. Both sets of guidelines point designers in the right direction, however, our goal is to support such guidelines with more objective techniques where possible. This paper, therefore, attempts to remedy the lack of suitable tools and techniques on metaphor design for interface designers, by developing an easy-to-use framework. Contents of the framework are derived, in part, from the use of a pragmatic model, which seeks to characterise the role of metaphor at the human computer interface. Additional techniques in the framework have been adapted from other disciplines or developed during the implementation of a number of metaphor-based interfaces for advanced telecommunications applications. Finally, the views of interface designers, at two software workshops on the framework, have been used to improve the efficacy and relevance of our framework. The framework is a collection of practical methods and techniques for exploiting the descriptive power of metaphor during interface design. Some of the content of this paper has previously been published in a number of conference proceedings (Anderson et al., 1994; Smyth and Knott, 1994; Smyth et al., 1995; Alty and Knott, 1998). The main function of this paper is to bring together the different strands of the work into a unified manner so that Software Engineers and Human Factors specialists can understand the framework, and use it to assist them in applying metaphor in interface design. 2 Defining metaphor Literary theory characterises the role of metaphor as the presentation of one idea in terms of another, such that understanding of the first idea is transformed in the process. From the fusion of the two ideas, a new one is created. Richards proposed a nomenclature in which he defined the original as the “tenor” and the second idea imported to modify or transform as the “vehicle” (Richards, 1936). Critical to the power of metaphor is that the convocation of ideas must involve some transformation, otherwise there is simply analogy or juxtaposition and not the idea of metaphor. Metaphors draw incomplete parallels between unlike things, emphasising some qualities and suppressing others. The terms characterising metaphor are presented in Fig. 1. Thus, in the design of the Apple Macintosh interface, the real-world desktop acts as a metaphor (or vehicle) in order to transform the functionality (or tenor), in this case the operating system of the computer Although many designers believe they are using metaphor in their designs, many current so-called “metaphor-based” interface systems actually adopt analogical or model-based approaches. These techniques employ direct mappings between the vehicle and tenor, thereby encouraging the direct transferral of existing knowledge to a novel situation. In contrast, metaphors do not make explicit the relationship between metaphor and functionality. Users actively construct the relationships that comprise the metaphor during interaction with the system. In short, the metaphor seeds the constructive process through which existing knowledge is transformed and applied to the novel situation. Fig. 1 Open in new tabDownload slide Representation of a metaphor. Fig. 1 Open in new tabDownload slide Representation of a metaphor. In the context of computer interaction, Carroll and Mack (1985) state that “metaphors can facilitate active learning… by providing clues for abductive and adductive inferences through which learners construct procedural knowledge of the computer”. Metaphor is viewed as an important technique facilitating the learning process, since it is easier to build up a completely new concept from other, more established, concepts (Carroll and Mack, 1985; Smyth and Knott, 1994). Metaphors appear to act as natural links that enable the selection and application of existing models of familiar objects and experiences in order to comprehend novel situations or artefacts. Indeed it has been claimed that all learning is metaphoric in nature. Lakoff and Johnson (Lakoff and Johnson, 1980) view metaphors as coming from a small set of constructs based on universal human experience (for example the journey, the path, the container etc.). In this view, metaphor is more than a literary device. It is a basic cognitive activity. Metaphor in human–computer interfaces plays a variety of roles. Firstly, it is a means of characterising interactions with computers (dialogue, conversational etc.), secondly it is an interface design technique, and thirdly it is a conceptual tool for facilitating consideration of implementation issues. Depending on its role, different requirement criteria exist for selecting appropriate metaphors. For example, systems designers and end users are two distinct groups, so metaphors that are appropriate for one group may not be suitable for the other. The design problem involves not only deciding “what metaphor” but also ascertaining “whose metaphor” as well. Such a distinction is easily lost when systems designers choose interface metaphors. Another key metaphor issue is the mapping between metaphor and the functionality it represents. It is important to realise that the power of metaphor comes partly from the incompleteness of the mapping, or mismatches. Sometimes there may be more mismatches than matches. “The ship ploughed the waves” is an evocative metaphor, but ships and ploughs in reality have little in common. 3 Experience in the MITS project Between 1993 and 1997, the authors collaborated on a project called MITS (Metaphors for Integrated Telecommunications Services) funded by the RACE Directorate of the European Union. In that project, a number of prototype systems using metaphors were developed and evaluated as part of a larger investigation into the role of metaphor in telecommunications (Alty, 1993). These systems have allowed us to “reflect on action” (Schon, 1983) over the processes involved, identify techniques which might be more generally useful, and examine the utility of any models used. The approach is outlined in Fig. 2. Fig. 2 Open in new tabDownload slide The MITS approach to developing a methodology. Fig. 2 Open in new tabDownload slide The MITS approach to developing a methodology. A series of initial demonstrators highlighted a number of key factors considered central in metaphor design. Factors identified included realism, appropriateness, degree of mismatch, and level of abstraction. These were then used to develop a series of pilot implementations to probe particular issues pertaining to the role of metaphor. The output of the pilots was then related to stages in system design, namely metaphor selection, implementation and evaluation. One pilot involved point-to-point communication over an audio–visual network and provided the context from which to compare the utility and appropriateness of three interface metaphors (deemed equivalent as they supported identical system functionality). The second pilot, called ROME (MITS, 1994a) was a real-time virtual conferencing system developed to support ad hoc meetings. The system utilised a number of metaphors to facilitate interaction, such as rooms to aid navigation, a pointer to enable multi-way pointing at objects contained within a room, and a briefcase to represent the separation between private and public document storage. Each metaphor was evaluated in terms of its utility to facilitate real-time conferencing. The third set of pilot interfaces was designed to explore the relevance of previously identified classes of metaphor (Condon and Keuneke, 1994). Spatial, those which adopt containment descriptions to suggest particular activities and interactions. Activity-based, those suggesting particular actions or behaviours. Interactional, those suggesting the adoption of particular norms of interaction. Three interfaces corresponding to this classification were designed to support a range of telecommunications services associated with co-operative working: MILAN, a room based metaphor, which was considered to be an example of the spatial class; Little People, an animistic metaphor, which was an example of the activity-based class; and Link Journal, a publishing metaphor, which was an example of the interactional class. Details of the results of this work together with the underpinning rationale can be found in Condon and Keuneke (1994). 4 Steps in the design process The experience gained in the course of building the MITS systems provided the authors with a valuable insight into the design and use of metaphor at the human–computer interface. During 1997, these ideas were honed into a set of guidelines and tools, which was presented at two workshops for software developers from a number of software companies in different countries. Their feedback was a key factor in the selection of the final collection of tools and techniques presented here. Our approach has identified six major steps in the design process: identify system functionality; generate and describe potential metaphors; analyse metaphor-system pairings; implementation issues: representation, realism, and consistency; evaluation; feedback on design. The first step must always be an analysis of the intended functionality of the system. This may sound obvious, but it is important to know what is required to be represented. The next step is to generate candidate metaphors to represent that functionality. Such a process should be as unconstrained as possible. At this point it is important to check the relevance of the proposed metaphors with the intended user population. Once a set of candidate metaphors has been selected, examining the match between the metaphor and the functionality narrows the choice further. What is being examined here is the degree of match and mismatch. This analysis will probably narrow the choice to a few candidate metaphors, which are then examined from an implementation point of view. Issues such as appropriateness, the realism of the implementation, and the user view of the metaphor will be important. Next the effectiveness of the metaphors in use needs to be evaluated. This leads naturally into the last stage, reflections on design. This is more than an Evaluation phase, and it is one stage where the design process may be metaphor-led. By considering the full range of the metaphor (e.g. mappings outside current functionality), the functionality of the system might be extended in novel ways. The steps will now be examined in detail, and related to our MITS experience. 5 Step 1. Identification of system functionality A necessary first step in the design of any system is the identification of the functionality which must be provided in order to support a given task domain. A description of the proposed functionality is a necessary precursor to the exploration of any mappings between the system and potential metaphors. Such a functional description defines what we call the Functionality Set S. A variety of techniques are available to practitioners, ranging from those providing formal descriptions, for example Task Action Grammar (Diaper, 1989) to those influenced by an ethnographic approach (Blomberg et al., 1993). However, the definition of the set S usually involves extensive internal discussions both between designers and with the intended users. At our workshop, software designers pointed out that metaphor could be used as an aid to supporting discussions about the proposed functionality of a system with the intended users. Although such metaphors may well be re-usable at system implementation, designers need to be aware of a number of potential difficulties with this approach. Firstly, experiences reported during the development of the prototype systems showed that it was extremely easy for systems designers to lose sight of the intended functionality to be communicated to the user. This resulted in an interface design that mimicked the attributes of the metaphor, rather than utilised these attributes to communicate the underlying system functionality to the user. Taken too literally, metaphor can switch from acting as a technique for thinking about a problem, to being seen as a solution to that problem. In order to avoid the pitfalls of such metaphor-led design, the intended system functionality must always be kept as the firm focus of design. The use of metaphor to stimulate the design process should be considered as “metaphor informed” rather than “metaphor led”. The distinction is important. It reminds designers that the application of metaphor is about making use of particular aspects of familiar real world entities to explain interface artefacts, rather than the mimicking of real world entities with no regard as to whether such wholesale transfer is either needed or appropriate. There is usually no need to strive to minimise mismatches, since human beings are very used to the metaphor concept and expect them. Users do not have waste bins on their desk top, but this mismatch in the implementation of the desk top metaphor does not trouble them at all. Neither does the fact that papers do not “fall off the desk”, when placed too near the edge. In these cases the users have an intuitive view of which matches matter and which do not. Secondly, interface designers must appreciate that their conception of a particular metaphor may be radically different from an end-user's conception of that same metaphor. A designer, for example, may think it appropriate to refer to the organisation of file systems in terms of directories. However, to a user of a computer based telephony system, a directory means a document in which names, addresses and telephone numbers are stored. Even the word file has a number of interpretations. To a user it refers to all records relating to a particular customer, to a system designer it refers to all records of a particular type unless they work for IBM in which case it could be interpreted as a physical entity on which binary data is stored. 6 Step 2. Generation and description of potential metaphors The next step in the design process is to identify a candidate set of metaphors that have the potential for use in the final interface to the functionality previously defined in step 1. In this section, we discuss a number of approaches to the problem of determining this set. 6.1 Design metaphors Metaphors used as aids to supporting discussions about the proposed functionality of a system with intended users can be useful sources of metaphor candidates. Users also often come up with metaphors in the language of the task to aid their understanding, and designers should take careful note of these. The technique therefore involves careful monitoring of the language used by prospective users when discussing their requirements. Any direct use of metaphor should be noted. 6.2 Extension Often, new systems are extensions of existing computer implementations or manual systems. Metaphors used by currently available software, procedures that provide similar functionality, or indeed standard interface metaphors such as windows, buttons and menus, can all be extended to new systems. These techniques, whilst potentially restricting the scope for truly innovative metaphor-based interfaces, can ensure consistency between software running on the same platform, and can also enable skills learnt using one system to be transferred to another if the metaphors are the same. The familiar metaphors of cut, copy, paste, style, frame and ruler used in most desk-top publishing systems are prime examples. 6.3 Brainstorming Usually involving system and interface designers, brainstorming can be of great use in the generation of metaphors for novel systems. To exploit this technique, the required functionality is written in a structured form on one side of a large whiteboard. Brainstorming consists of selecting subsets of this functionality and then mapping real-world processes onto these subsets. Then an attempt is made to try to cover the remaining areas of the functionality. The mismatches in the process will often generate interesting new metaphors. 6.4 Market feedback As was pointed out at our software workshops, much of the stimulation for the design of software systems originates from market feedback by customers. In many cases, the fact that customers attempt to describe the functionality of the systems which they require, forces them to employ metaphors with which they are familiar as part of their everyday lives and, as such, can form an invaluable resource for interface design. 6.5 Work-place studies Systems that are designed to support skilled work should blend in with the worker's current environment. This allows the worker to concentrate on “getting on with the job” in a manner that is empowered by the system rather than impeded by it. In order to do this, it is important that the everyday tools, skills and knowledge of those workers is supported by, or incorporated into, the system; and it is the role of fieldwork to identify and describe this workaday world (Moran and Anderson, 1990). Anthropological, and in particular, Ethnographic, field work techniques are beginning to be recognised as useful in this process (Nardi and Miller, 1990; Hughes et al., 1993). Ethnographic techniques describe the knowledge and understandings that informants have of their own world, in their own linguistic and conceptual terms. These methods can generate descriptions of objects or concepts that suggest interface metaphors grounded in the workaday world of the informants. We have therefore developed a technique based on those used in Ethnomethodology (Garfinkel, 1986). It involves the extensive use of frame elicitation techniques (Frake, 1962; Agar and Hobbs, 1985). The technique can be illustrated through the work of (Anderson, 1994; Anderson and Alty, 1995) who describes the setting up a system to allow users to interact with each other on a Video/Audio network, where a number of people on the net communicate with each other at any time. The problem to be addressed was how to control communication. Someone might be busy, and not wish to be interrupted. Others might be busy, but allow interruptions by certain people. At other times people might operate an open house. Discussions with users suggested that a DOOR metaphor, to indicate the users interface state, might be appropriate. But what door states would be expected and what actions would be appropriate and when? The technique involves asking users to fill in blanks in a set of questions in which the important information is blank. No guidance is given as to how to complete the form and any answer is acceptable. A set of Business Managers (both junior and more senior) were asked to complete the following: As I walked towards — (person's) door, I saw it was — (state) so I — (action) The answers form a set of {person–state–action} triples, whose content has been provided by users. A summary of the results is shown in Table 1 above: Table 1 Results of the ethnographic study for DOORS Closed . Busy-not disturbable not in office . Walk straight in (W) . Knock and wait for invitation (Kw) Leave a message (M) Check with Secretary (S) Go away and try alter (La)  Partially open Busy but can be interrupted Walk straight in (W) Knock and wait for invite (Kw) Take quick glance (G) Go away and try later (La)  Fully open Available for communication Walk straight in (W) Knock and wait for invitation (Kw) Knock and walk in (Ke) Take quick glance in (G) Closed . Busy-not disturbable not in office . Walk straight in (W) . Knock and wait for invitation (Kw) Leave a message (M) Check with Secretary (S) Go away and try alter (La)  Partially open Busy but can be interrupted Walk straight in (W) Knock and wait for invite (Kw) Take quick glance (G) Go away and try later (La)  Fully open Available for communication Walk straight in (W) Knock and wait for invitation (Kw) Knock and walk in (Ke) Take quick glance in (G) Open in new tab Table 1 Results of the ethnographic study for DOORS Closed . Busy-not disturbable not in office . Walk straight in (W) . Knock and wait for invitation (Kw) Leave a message (M) Check with Secretary (S) Go away and try alter (La)  Partially open Busy but can be interrupted Walk straight in (W) Knock and wait for invite (Kw) Take quick glance (G) Go away and try later (La)  Fully open Available for communication Walk straight in (W) Knock and wait for invitation (Kw) Knock and walk in (Ke) Take quick glance in (G) Closed . Busy-not disturbable not in office . Walk straight in (W) . Knock and wait for invitation (Kw) Leave a message (M) Check with Secretary (S) Go away and try alter (La)  Partially open Busy but can be interrupted Walk straight in (W) Knock and wait for invite (Kw) Take quick glance (G) Go away and try later (La)  Fully open Available for communication Walk straight in (W) Knock and wait for invitation (Kw) Knock and walk in (Ke) Take quick glance in (G) Open in new tab The user answers resulted in three states: A CLOSED DOOR indicated non-interruptible. A PARTLY OPEN DOOR indicated that a glance was possible (actually a few seconds of video), and a user could accept or reject the intrusion. A FULLY OPEN DOOR indicated communication availability. The variations in user responses for person and action (and the relationship with state) are shown in Fig. 3. Fig. 3 Open in new tabDownload slide User results from the DOORS study. Fig. 3 Open in new tabDownload slide User results from the DOORS study. The variations in the answers given, even from this relatively small sample, are very varied. On the horizontal axis the actions have been arranged in decreasing interruption level. In broad terms, the results follow a set of social rules that one might expect. For example, people are much less likely to interrupt a closed door if the person inside is of superior status (i.e. Boss's Boss is to the right of Boss which is to the right of Friend), However, the really interesting aspect is the overlap between different behaviours. It would be very difficult to construct a set of authoritative rules to cover such rich behaviour. Anderson et al. (1994) therefore used the metaphor to indicate available states and possible actions. As a result, during implementation, no restrictions were placed on actions within states. Thus, if users wished, they could enter a closed door, the only mediating factor being social acceptability. Very quickly, users fell into acceptable (though varied) behavioural patterns. The technique is therefore an interesting one. It provides the substance of the metaphor and very important pointers towards implementation. The technique illustrates the richness of metaphor and the varying interpretation in people's minds. It allows designers to separate out the social and cultural aspects of the interaction, while warning of the inherent dangers in too detailed an implementation. Thus the basic Office Doors metaphor provides the required functionality as a basic level, but leaves the interpretation to individual users. We recommend the use of this ethnographic fieldwork technique to generate possibilities for design such as workplace tools, objects, “phraseology” and common practices, as well as descriptions of norms of working behaviour, communication and control (MITS, 1994c). The technique allows the designer to generate a set of structured descriptions of potential metaphors that could be used as interface metaphors. We call this the Metaphor Set M. There will clearly be a set of pairings between our previously defined Functionality Set S and set M. 7 Step 3. Analyse metaphor-system pairings (mappings between S and M) Given that steps 1 and 2 have defined the system functionality, and described potential metaphors in some detail, the third step analyses particular metaphor-system pairings. This enables the designer to assess the effectiveness of mappings between the system (set S) and metaphor (set M) by examining the intersection of these two sets (Hammond and Allinson, 1987; Rogers et al., 1988; Anderson et al., 1994). The intersection between the metaphor and system sets provides four categories as illustrated in Fig. 4. Fig. 4 Open in new tabDownload slide The interaction of metaphor and system as applied to Human–Computer Interaction. Fig. 4 Open in new tabDownload slide The interaction of metaphor and system as applied to Human–Computer Interaction. This conceptualisation provides a number of distinctions that are illustrated using the example of the Macintosh wastebasket (we use italicised type for words that refer to metaphors): S+M+ features. Features that lie in the intersection between the two sets. Thus S+M+ features are those features of the system that map completely on to features of the metaphor. In the wastebasket, examples include the mapping of deletion to throwing in the bin and the ability to retrieve items that have been thrown away by taking them out of the bin if the bin has not been emptied. S+M−features. Features that lie within the set of system functionality but do not intersect with the set of metaphor features. In the case of the wastebasket such features include the ability to eject disks by dropping them into the wastebasket (which would mean disk deletion if this mapped onto the metaphor features) and the appearance of the wastebasket on top of the desk rather than underneath it. S−M+ features. Features that lie within the set of metaphor features but which do not intersect with the set of system features. In other words these are features of the real world metaphoric entity that do not apply in the context of the particular system under consideration. We characterise these features as the “conceptual baggage” that the metaphor brings with it to the interface. For example, real world wastebaskets have a finite volume and so will fill up if they are not emptied (although this is trivially true of the Macintosh wastebasket), and they tend to be found underneath desks rather than on them. S−M− features. Features that are neither part of the system functionality nor the metaphor. This area is included in the diagram merely to provide closure in a similar way to that provided by the Universal Set in set theoretical notation. The analysis enables the designer to examine a number of factors, which are dependent on the degree of overlap between the two sets of features, and which could influence the effectiveness of particular metaphors used at the human computer interface. Three examples of such features are: the extent to which the metaphor causes a user to make incorrect inferences about the system functionality (S−M+); the degree to which the system's core functionality maps onto the core features of the metaphor (S+M+); the extent to which the system functionality fails to map onto the metaphor features at all (S+M−). The model implies that these factors are intimately interrelated. In Fig. 3, for example, an increase in system features that can be characterised as S+M+ will cause a corresponding decrease in features categorised as S+M−. 7.1 Conceptual baggage: S−M+ compared with S+M+ It is likely that users will make inappropriate inferences about the functionality of the system from their own understanding of the metaphor (Douglas and Moran, 1983; Carroll et al., 1988). We suggest that this problem will occur whenever there is a high proportion of S−M+ features compared to S+M+ features. In other words, the majority of the features of the metaphor are inappropriate to the context of system usage so that the users will have inappropriate expectations of system behaviour. This problem is caused by what we term the “conceptual baggage” brought to the interface by the metaphor. Conceptual baggage can be thought of as features of a metaphor that are not utilised in a particular metaphor-system pairing (Anderson et al., 1994). Clearly, when selecting a metaphor, it is desirable to keep the amount of conceptual baggage to a minimum. This idea is analogous to Laurel's argument that a representation of intelligent software agents should lead the user to appropriate expectations about the complexity of potential agent behaviour (Laurel, 1990). Similarly, a metaphor used in any human computer interface should lead to appropriate expectations about the system by a user (Smyth and Knott, 1993). It is vitally important therefore that metaphors selected for use in interface design are those which can be thought of as minimising the S−M+ features. From Fig. 3 it is apparent that there are two strategies that can be used to effect this minimisation. The first is to select a metaphor with a restricted scope, the second is to expand the scope of the system so that it more faithfully maps onto the features of the metaphor. Both strategies will cause a reduction in conceptual baggage. In the latter strategy this would appear to encourage the creation of software that more closely follows the features of some real world metaphor. As many authors have noted, such an approach must be viewed with caution (Hammond and Allinson, 1987; Kay, 1990; Nelson, 1990) because blindly “following the metaphor” can lead to restrictive systems in which the ability to do anything truly new is lost. During the MITS project, an extensive investigation was carried out into the possible effects of conceptual baggage on interface usability. The study was carried out on the DOORS system which we have previously described (Anderson et al., 1994). In this paper we will illustrate how our analysis can be used to detect and support reasoning about conceptual baggage using the three metaphors employed in the study. The system functionality in the study allowed a number of users to interact with each other on a Video/Audio network. The metaphors were introduced to allow users to control communication. A user might be busy, and not wish to be interrupted. Others might be busy, but allow interruptions by certain people. At other times people might operate an open house. 7.1.1 Description of metaphor-system pairings Three pairings were chosen using techniques suggested by Carroll et al. (1988) which consider the mappings between metaphor and system at the levels of “tasks”, “methods” and “appearances” in a representative set of scenarios. The three metaphors were: office doors,dogs, and traffic lights. Office Doors. The first metaphor-system pairing adopted the office door as a metaphor for representing the availability of a user. Specifically, an open door corresponded to “available for communication”, a partially open door to “busy but interruptable” and finally a closed door to “not available for communication”. The office door is a very rich metaphor in this particular context, and there are a great number of features of the metaphor that are not supported by the system (S−M+). The system functionality, for example, does not allow doors to be locked, nor does it support “knocking on the door” or leaving a message pinned on it. Thus as Fig. 5 illustrates, the proportion of S−M+ features compared to S+M+ features is relatively high. In addition, most of the system functionality is accounted for by features of the metaphor (i.e. S+M− is small compared with S+M+). As a result, we can predict certain problems that the users might be expected to have. Fig. 5 Open in new tabDownload slide Characterisation of office doors/system pairing. Fig. 5 Open in new tabDownload slide Characterisation of office doors/system pairing. Users should find the system easy to use even if they have not encountered it before, not only because the metaphor seems contextually relevant, but also because the ratio of S+M− features to S+M+ features is quite low. For the same reason we would expect users to quickly explore the system and successfully utilise the underlying functionality. However, over time they might become frustrated because expected features were not in fact supported, as the conceptual baggage of this particular metaphor-system pairing is quite high. Office doors was therefore considered to have a high conceptual baggage content. Dogs. The second metaphor adopted was that of the dog to represent the availability of a user. Specifically, an attentive dog corresponded to “available for communication”, a digging dog to “busy but interruptable” and finally a sleeping dog to “not available for communication”. The characterisation of the relationship between this metaphor and the system is shown in Fig. 6. Fig. 6 Open in new tabDownload slide Characterisation of dogs/system pairing. Fig. 6 Open in new tabDownload slide Characterisation of dogs/system pairing. In this pairing, as in the previous case, there are a great number of potentially relevant features of the metaphor that are not supported by system functionality (S−M+). For example, our metaphoric Dogs cannot be trained to allow communications from specified people, nor will they adapt to familiar communicators. On the other hand, dogs do many things that doors do not. Thus it can be seen that the proportion of S−M+ features compared to S+M+ features is high so there is considerable conceptual baggage. However, very little of the system functionality is accounted for by features of this metaphor. Such a characterisation leads to different predictions about the patterns of user performance. Firstly it is likely that initially, users will not find the system intuitive, not only because the metaphor is less contextually relevant, but also because the ratio of S+M− features to S+M+ features is comparatively high. For the same reason even if users did explore the system and became familiar with the functionality, the boundary between S+M− and S+M+ features would be apparent. Dogs was therefore considered to be a rich but inappropriate metaphor in the context of this pairing. Traffic Lights. The third metaphor-system pairing adopted the traffic light as a metaphor for representing the availability of a user. Specifically, a green light corresponded to “available for communication”, an amber light to “busy but interruptible” and finally a red light to “not available for communication”. The characterisation of the relationship between this metaphor and the system is shown in Fig. 7. Fig. 7 Open in new tabDownload slide Characterisation of traffic-lights/system pairing. Fig. 7 Open in new tabDownload slide Characterisation of traffic-lights/system pairing. In this pairing there are few potentially relevant features of the metaphor that are not supported by the system. Thus the proportion of S−M+ features compared to S+M+ features is relatively low. There is considerably less conceptual baggage than in the previous two situations. As with dogs, very little of the system functionality is accounted for by features of the metaphor. This characterisation leads to further predictions about patterns of user performance. Users may not initially find the system intuitive, not only because the metaphor seems less contextually relevant, but also because the ratio of S+M− features to S+M+ features is quite high. For the same reason we would expect that even if users do explore the system and become familiar with the functionality, the boundary between S+M− and S+M+ features will be apparent. Finally, owing to the predicted lack of conceptual baggage, we expect that the users will be better able to distinguish between S−M+ features and S+M+ features associated with this pairing. Traffic Lights is therefore considered to be a sparse metaphor with limited appropriateness in the context of this pairing. This analysis illustrates how the pragmatic model can be used to make predictions about the potential of candidate metaphors. The contextual relevance of Office Doors together with the high amount of conceptual baggage may prove problematic with extended use. The poor mapping of Dogs to system functionality is likely to confuse users, though they may eventually be able to distinguish between S+M+ and S+M−. The Traffic Lights metaphor might not initially be very intuitive but the lack of conceptual baggage means that users are likely to recognise those features of the system associated with the pairing. Thus, TrafficLights would seem to be the best representation of a persons’ availability for communication, though Office Doors will offer better extensionality. Rich metaphors will always bring with them a considerable portion of conceptual baggage. How might a designer minimise this effect when a rich metaphor is required. We suggest that the solution lies in the choice of metaphors that encourage discovery on the part of the user. Although exploratory interfaces will place a higher cognitive load on the user (a principle at variance with standard interface design recommendations), these short term demands will rapidly be offset by increased long term user performance. 8 Step 4. Implementation: issues of representation, realism and consistency 8.1 How realistic should a metaphor be? Critical to the success of an interface metaphor is its ability to portray the object that carries the information to the user. It is vital that the user recognises the metaphor immediately, as this is a necessary first step to understanding the system functionality it implies. This issue was illustrated when users of Traffic Lights reported initial difficulty concerning the recognition of the metaphor. Only through exploration of the system did the users discover the rationale behind the choice of metaphor. Once the rationale had been understood, the users quickly took advantage of the system functionality. Interestingly, the act of exploration appeared to have a positive effect on the overall utility of this metaphor, which was reflected in user performance (Smyth and Knott, 1994), a finding also supported by Carroll et al. (1988). Similarly, subjective responses to the Little People system revealed difficulties in recognising the functionality of some animistic characterisations. One solution to this problem would be to choose realistic implementations of metaphors (i.e. choose a metaphor that reflects both the object itself and communicates the associated functionality). However, this solution can cause further difficulties when, as is often the case, a computer-based artefact offers additional functionality not normally associated with a real world entity (for example getting an ordered list of material in a wastepaper basket). One tempting design solution is to generate realistic, or high fidelity, computer based representations of real world entities. The rationale behind this approach was that a more realistic representation would facilitate recognition of the metaphor. In effect, the user's existing model of the real world artefact would be directly applied to the computer-based representation. While intuitively appealing, this approach does have a number of shortcomings. Firstly, by adopting what is, in effect, an analogy with the real world artefact, any novel functionality offered by the technology is not directly apparent to the user. Secondly, the real world model often shapes the user's expectations of the functionality associated with the system. If such functions are not provided, the system appears to the user to behave in a counter intuitive manner. Evidence for these conclusions was provided by a subject's reported difficulty in setting up a video link in the MILAN system, which adopted a realistic television metaphor, and confusion concerning the degree of privacy associated with a briefcase in the ROME interface (MITS, 1994b). In MILAN, a television set was adopted as a metaphor for the initiation and control of an Audio–Visual link. The users correctly identified the object as a television and consequently applied their real-world model of operating a television at a distance. This resulted in an extended search of the interface objects for a (non-existent) remote control, when in fact, the solution was to use a cursor. The second example concerned the use of the ROME interface, and, in particular, the operation of the briefcase. The intention of the briefcase was to provide users with a personal storage area for documents, which could be used in conjunction with the shared objects in the room. Confusion was reported concerning the degree of privacy associated with items in opened briefcases when other users were active in the room. The real-world model suggested that the contents of an open briefcase would be viewable by other people in the room (in the implementation, this was not the case). The real-world model of the artefact was an inappropriate representation of the computer based artefact and caused users to make incorrect assumptions as to the behaviour of the system. High fidelity representations, therefore, seem to compound the effects of the conceptual baggage associated with the pairing. Further, by adopting overt analogies with real world entities, the potential to communicate any novel functionality to the user will be diminished. Thus, decisions about the degree of realistic representation of a metaphor, based solely on system requirements and constraints, should be made in the understanding that they may have unforeseen implications on the user's expectation of system performance. 8.2 Consistency There are two types of consistency which are important: within-metaphor and between-metaphor. Within-metaphor consistency is concerned with consistency within a single metaphor. For example, the language of menu items should reflect the attributes normally associated with that metaphor. The choice of command language and terminology can have a positive reinforcing effect on the utility of a chosen metaphor. Finally, designers of metaphor based interfaces must acknowledge that many users have experience with particular interface styles. Thus, if a metaphor is to be widely accepted by such users it should reflect the look and feel of generic interface objects associated with the known system, as discussed in step 2. Metaphors are rarely used in isolation. It is common to have a number of metaphors simultaneously active in an interface. For example, most interfaces support the Cut–Copy Paste–Clipboard metaphor for object manipulation within and between documents, and applications. Alongside this metaphor will usually be the Desktop metaphor for system operation. Designers should avoid the Mixed Metaphor trap that is well known in language. The amusement normally derived from a mixed metaphor is based upon inconsistency resulting in conflicting images. For example, “shutting the stable door after the horse has bolted” is a good metaphor for indicating that it is too late to issue a security clamp down. Similarly, “the cat is out of the bag” is a good metaphor for indicating that information has leaked. However, to say “shutting the stable door after the cat is out of the bag” is a mixed metaphor that tends to cause amusement rather than emphasise the point being made. In a similar way, interface metaphors need to be consistent. The technique we have found useful is to ensure that each metaphor belongs to the same “family” of metaphors. A family of metaphors is a set of separate metaphors defined within a single higher level metaphor. So, one might use an Office metaphor as the higher level set, and define all lower level metaphors within this, for example Rooms, Doors, Secretaries and Postroom. This is possibly why Cut–Paste works well alongside the Desktop. A mathematical notation for representing metaphor and concepts such as mixed metaphors, metaphor families and consistency has been suggested by Alty and Knott, 1994). 8.3 Appropriateness Finally it is important to mention appropriateness. There are some instances where a metaphor might provide a solution to an interface problem but may not be appropriate. An inappropriate metaphor is one which carries with it connotations (usually cultural) which interfere with its suitability. Racist, sexist or ageist stereotypes come immediately to mind, but there are others. For example, a cartoon like metaphor might work well in practice, but be seen to give an inappropriate image for the company producing the software, or those using it. Appropriateness can only be evaluated in the context of the intended user population. One difficulty is that what may be appropriate today, may not be appropriate in a few years. 9 Step 5. Evaluation It is important to use evaluation techniques which can be administered in the working environment, while being sensitive to the nature of the metaphor's relationship with the underlying system functionality. The best technique is to observe users in situ using the metaphors to carry out real tasks on the system. The pedagogical model described earlier, allows designers to identify possible pairing issues, and the questionnaire approach used in the Office Doors, Dogs, Traffic Lights examples can be used to probe user understanding. Using both a video recording of the interactions together with the subject's verbal protocol is also a useful evaluation technique. Both these techniques provided a complementary data resource to that of the questionnaire and a record of the actual use of each interface. During the evaluation of each of the prototype systems supporting this paper, we found it essential to make a video recording of the interaction, since it provided a valuable resource in terms of both qualitative comparisons between candidates and as a record for systems designers. During evaluation, the following aspects are likely to be considered: The amount of conceptual baggage and its effects on user comprehension. An assessment of the seriousness of mapping errors. Misunderstandings caused by the S−M+ set and irritations caused by the S+M− set. Such aspects may be evaluated for a single metaphor or across a set of candidate metaphors. Inappropriateness of metaphors. Are there aspects of the metaphor that are inappropriate in the target environment? Extensibility. Does the metaphor provide new ideas for system functionality extension (i.e. can S−M+ features suggest new S features?) Consistency across metaphors (when there are a number of simultaneous metaphors operating). Degree of Realism. Is the metaphor too analogical? The purpose of the Evaluation phase is to assess the suitability of a metaphor (in situ) and thence provide feedback for improved design. 10 Step 6. Feedback on design In order to be considered useful in the design process, it is imperative that the evaluation techniques described can provide direct feedback into the re-design of the prototype interfaces. In the case of the DOORS system, for example, the evaluation demonstrated that the effect of conceptual baggage on system usability was as important as the need for sufficient mappings between metaphor and system. The evaluation also provided an empirical basis for making quantitative comparisons between the candidate metaphors of Office Doors, Dogs and Traffic Lights. In addition, it highlighted problems with particular aspects of the interface metaphors forming the prototype. Many users expected a system based on the office door to provide additional door-like functionality. These included the ability to lock a door (preventing all communication access except messaging); the automatic closing of a door once a connection is made; the idea of grouping the doors of members of a group into corridors, and the need for information on the physical location of each office. In the case of the ROME system, the evaluation enabled designers to specifically examine the problems users appeared to have with the briefcase by targeting the category-based questions at this particular interface metaphor (MITS, 1994b). In general, it was found that users metaphor-related expectation of functionality was higher than was actually supported by the system, causing them to make incorrect inferences about the system, as was the case with the Office Doors system. The solution to this problem, a reduction in “realism”, is discussed in the section concerned with implementation above. Finally, existing interface metaphors can be used to extend the functionality of a system. An example that came up in one of our workshops with software designers will illustrate this. A Library metaphor was being proposed to represent an information system. Users could browse the “shelves” and select “books”. The designers then forgot the current implementation and pursued implications of the metaphor itself. What happens in a real library? Well, a reader might be extracting a book when another reader attempts to retrieve a book from close by. Since books on shelves are ordered in relation to content, this means that the other reader might have similar interests to the first. A fruitful conversation might then ensue on the merits of books on this subject area. The designers then caste this projection of the metaphor back onto the system and suggested that we might extend its functionality to allow users accessing closely related information areas to be able (if they wished) to communicate with other users browsing the same areas at the same time. 11 Conclusions We offer these six steps: as a contribution to improved design of metaphors in user interfaces. These steps should be viewed as guidelines rather than prescriptions but we hope that the examples we have chosen from the MITS work make the implementation of these steps more understandable in context. Certainly, the software designers who attended our workshops were satisfied that they made a useful contribution to the implementation and evaluation of metaphor at the user interface. identifying system functionality; generation and description of potential metaphors; analysis of metaphor-system pairings; implementation issues: representation, realism, and consistency; evaluation; feedback on design. There are, as one would expect, similarities with other guidelines that have been suggested. For example, in Carroll and Thomas's guidelines their second guideline corresponds to our concern about being metaphor-led when defining system functionality. Their concern about the emotional tone corresponds to our appropriateness category. Their suggestion about metaphors from common domains corresponds to our suggestions to maintain consistency. Their exhortation to consider users and designers views of metaphor is echoed in our approach. The later guidelines of Carroll and Mack, attempt to provide a more concrete approach through the use of scenarios. Thus our approach does not conflict with these earlier attempts. What we have tried to do, however, is to provide some techniques and practices to assist designers in approaching the problem. Acknowledgements We would like to thank the MITS project partners for their help in refining the ideas expressed in this paper, in particular Marius and Julie Bergan, Chris Condon, Christian Heath, Asko Komsi and Paul Luff. We would also like to thank the representatives of various software companies whose comments have been of great importance in ensuring the practical utility of the techniques described. We gratefully acknowledge our colleagues at Rank Xerox Research Centre, Cambridge for their help with the implementation and evaluation of the Office Doors system Finally, the work reported in this paper was supported by RACE Directorate of the European Union, Project No. R:2094. References Agar and Hobbs, 1985 Agar M.H. Hobbs J.R. , How to grow schemata out of interviews Dougherty J.W.D. Directions in Cognitive Anthropology 1985 University of Illinois Press , Urbana, IL OpenURL Placeholder Text WorldCat Alty, 1993 Alty, J.L., 1993. Cooperative working and multimedia telecommunications. The Importance of Metaphor, Proceedings of RACE IS+N Conference, Paris, November 1993. Available from RACE Directorate. Alty and Knott, 1994 Alty, J.L., Knott, R.P., 1994. A Formal Notation for Metaphor Description. LUTCHI Internal Report No. 94/M/LUTCHI/0163, Loughborough University, UK. Alty and Knott, 1997 Alty, J.L., Knott, R.P., 1997. Metaphopr and interface design: extending the model. In: Bernd-Burkhard, B., Johanssen, J., Wittenberg, C., Stratz, G. (Eds.), Proceedings of the XIV Annual Conference on Human Decision Making and Manual Control, pp. 36–42, ISSN 0940-094X, No. 19. Anderson, 1994 Anderson, B., 1994. Cognitive Anthropology and User-Centred System Design: How to Enter an Office. LUTCHI Internal Report No. 94/M/LUTCHI/0162, Loughborough University, UK. Anderson et al., 1994 Anderson, B., Smyth, M.G., Knott, R.P., Bergan, M., Bergan, J., Alty, J.L., 1994. Minimising conceptual baggage: making choices about metaphor. People and Computers IX, Proceedings of HCI’94, 28–30 August, 1994, Glasgow, UK, pp. 179–194. Anderson and Alty, 1995 Anderson, B., Alty, J.L., 1995. Everyday theories, cognitive anthropology, and user-centred system design. People and Computers X, Proceedings of HCI’95, pp. 121–135. Blomberg et al., 1993 Blomberg J. Giacomi J. Mosher A. Swenton-Hall P. , Ethnographic field methods and their relation to design Schuler D. NamiokaSchuler A. Participatory Design: Principles and Practices 1993 Lawrence Erlbaum , London OpenURL Placeholder Text WorldCat Carroll, 1982 Carroll J.M. Thomas , Metaphor and the cognitive representation of computing systems , IEEE Trans. Systems Man Cybernet. SMC-12 ( 2 ) 1982 ) 107 – 116 Google Scholar Crossref Search ADS WorldCat Carroll and Mack, 1985 Carroll J.M. Mack R.L. , Metaphor, computing systems and active learning , Int. J. Man-Mach. Stud. 22 ( 1 ) 1985 ) 39 – 57 Google Scholar Crossref Search ADS WorldCat Carroll et al., 1988 Carroll J.M. Mack R.L. Kellogg W.A. , Interface metaphors and user interface design Helander M. Handbook of Human–Computer Interaction 1988 North-Holland , Amsterdam OpenURL Placeholder Text WorldCat Condon and Keuneke, 1994 Condon, C., Keuneke, S., 1994. Metaphors and layers of signification: the consequences for advanced user service interfaces, Proceedings of RACE IS&N Conference, Aachen, Germany, 7–9 September. Diaper, 1989 Diaper, D., 1989. Task Analysis for Human--Computer Interaction, Ellis Horwood. Douglas and Moran, 1983 Douglas S.A. Moran T.P. , Learning text editor semantics by analogy Proceedings of CHI ’83: Human Factors in Computing Systems 1983 ACM , New York OpenURL Placeholder Text WorldCat Erickson, 1990 Erickson T.D. , Working with interface metaphors Laurel B. Mountford S.J. The Art of Human Computer Interface Design 1990 Addison-Wesley , New York OpenURL Placeholder Text WorldCat Frake, 1962 Frake C. , Cultural ecology and ethnography , American Anthropologist 64 ( 1962 ) 53 – 59 Google Scholar Crossref Search ADS WorldCat Garfinkel, 1986 Garfinkel H. , Ethnomethodological studies of work 1986 Routledge and Kegan Paul , London Hammond and Allinson, 1987 Hammond, N., Allinson, L., 1987. The travel metaphor as design principle and training aid for navigating around complex systems. In: Diaper, D., Winder, R. (Eds.) People and Computers III, Proceedings of HCI’87, pp. 75–90. Hutchins, 1989 Hutchins E. , Metaphors for interface design Taylor M. Neel F. Bouwhuis D. The Structure of Multimodal Dialogue 1989 Elsevier , Amsterdam OpenURL Placeholder Text WorldCat Hughes et al., 1993 Hughes J.A. Somerville I. Bentley R. Randall D. , Designing with ethnography: making work visible , Interacting with Computers 5 ( 2 ) 1993 ) 239 – 253 Google Scholar Crossref Search ADS WorldCat Kay, 1990 Kay A. , User interface:a personal view Laurel B. Mountford S.J. The Art of Human Computer Interface Design 1990 Addison-Wesley , New York OpenURL Placeholder Text WorldCat Lakoff and Johnson, 1980 Lakoff G. Johnson M. , Metaphors We Live By 1980 University of Chicago Press , Chicago Laurel, 1990 Laurel B. , Interface agents: metaphors with character Laurel B. Mountford S.J. The Art of Human Computer Interface Design 1990 Addison-Wesley , New York OpenURL Placeholder Text WorldCat MITS, 1994a MITS, 1994a. Deliverable. D6 R2094/NOKIA/D6/DS//L/006/b1. MITS, 1994b MITS, 1994. Deliverable. D7 R2094/LUTCHI/CO/DS/R/007/b1. MITS, 1994c MITS, 1994. Deliverable. D8 R2094/LUTCHI/CO/DS//R/008/b1. Moran and Anderson, 1990 Moran, T.P., Anderson, R.J., 1990. The Workaday world as a Paradigm for CSCW, Computer-Supported Co-operative Work, CSCW’90, 1–10 October, Los Angeles, CA. Nardi and Miller, 1990 Nardi, B.A., Miller, J.R., 1990. An ethnographic study of distributed problem solving in spreadsheet development, Proceedings of Computer-Supported Co-operative Work, CSCW’90, 1–10 October, Los Angeles, CA. Nelson, 1990 Nelson T.H. , The right way to think about software design Laurel B. Mountford S.J. The Art of Human Computer Interface Design 1990 Addison-Wesley , New York OpenURL Placeholder Text WorldCat Richards, 1936 Richards I.A. , The Philosophy of Rhetoric 1936 Oxford University Press , Oxford Rogers et al., 1988 Rogers Y. Leiser R. Carr D. , Evaluating Metaphors for use at the User-System Interface Bullinger H-J. Protonotarios E.N. Bouwhuis D. Reim F. Eurinfo’88, Proceedings of the First European Conference on Information Technology for Organisational Systems, Athens, Greece, 16–20 May, 1988 1988 Elsevier , Amsterdam OpenURL Placeholder Text WorldCat Schon, 1983 Schon D.A. , The Reflective Practitioner: How Professionals Think in Action 1983 Basic Books , New York Smyth and Knott, 1993 Smyth, M., Knott, R.P., 1993. Metaphors in HCI, Proceedings of VAMMS’93, Visual Aspects of Man–Machine Systems, Prague, Czech Republic. Smyth and Knott, 1994 Smyth, M., Knott, R., 1994. The role of metaphor at the human computer interface, Proceedings of OzCHI’94, pp. 287–291. Smyth et al., 1995 Smyth, M., Anderson, B., Alty, J.L., 1995. Metaphor reflections and a tool for thought. People and Computers X, Proceedings of HCI’95, pp. 137–150. Wozny, 1989 Wozny L.A. , The application of metaphor, analogy, and conceptual models in computer systems , Interacting with Computers 1 ( 3 ) 1989 ) 273 – 283 Google Scholar Crossref Search ADS WorldCat Elsevier Science B.V.
TI - A framework for engineering metaphor at the user interface
JF - Interacting with Computers
DO - 10.1016/S0953-5438(00)00047-3
DA - 2000-12-01
UR - https://www.deepdyve.com/lp/oxford-university-press/a-framework-for-engineering-metaphor-at-the-user-interface-KmCDyGHX2o
SP - 301
EP - 322
VL - 13
IS - 2
DP - DeepDyve
ER -