to the top publications

On Magic Features in (Spatial) Metaphors

Andreas Dieberger
Georgia Institute of Technology
School for Literature, Communication & Culture
Atlanta, GA 30332-0165
andreas.dieberger@acm.org

SigLink Newsletter, Vol.4, Nr.3, December 1995

Introduction

Every computer system creates the illusion of a virtual world containing objects to manipulate [1]. This is especially true in modern graphical user interfaces. In some systems this virtual world, defined by the user interface metaphor, is made explicit in others it is not. Explicit spatial metaphors allow users to transfer navigational skills developed in the domain from which the metaphor is drawn, but constraints of the metaphor may limit the efficiency of the user interface. To overcome these constraints magic features can be introduced that go beyond the spatial metaphor. This paper advocates that magic features need to be designed differently enough to be noticeable as something special and that they can be based on metaphors taken from source domains where their special behavior may be considered normal.

"Spatial" User Interfaces

To speak of navigation in the user interface may seem reasonable only in systems making explicit use of a spatial metaphor like a desktop, a room, and so forth. Navigation essentially is a planning task to answer the following questions however:

These questions have to be answered over and over again when using computer systems - especially when using hypertext systems. Even when there is no explicit space to navigate in, these questions hint at the existence of an implicit space. This space may simply be defined by a neighborhood or connectedness relation between objects in the space. Both user interfaces and hypertext therefore can be seen as a spatial environment.

Navigation Problems

Spatial concepts in user interfaces often are hidden for a reason: the spatial metaphor can be an obstacle to navigate efficiently. For example when navigating using a strict building metaphor one has to navigate the whole way from a location A to location B. Similarly in a space defined by a folder tree navigation may require to move up to the root node and then all the way down to reach another node at the bottom of the folder tree.

A quicker and more efficient way to get from A to B in these examples is a shortcut from A to B -- for example by defining an alias in the folder-tree or by defining a magic door in the building example. These features allows to tunnel through the space in one step. This tunneling feature is a disruption of the spatial metaphor however as it connects two remote locations in a single step. The spatial separation of A and B normally has a reason -- for instance to group related files into folders. The shortcut disturbs this organization. (Footnote: Aliases also allow to point out relationships between otherwise distant items in the folder space.) Note that while we have an accepted word for such a feature in the file space, we do not have one for the building structure. It should also be pointed out that this connection makes the distance between A and B asymmetric -- while A is close to B now (via the new connection) B is still as far from A as it was before, because both alias and magic door typically are one-way connections.

Magic features for navigation

The two features above create a short connection between two distant locations in term of the spatial metaphor. Should something like that occur in the everyday world we probably would speak of magic. These features are therefore called magic feature. "Magic in a user interface is generally understood to be a liberation from the constraints of the physical world, taking advantage of the flexibility inherent in software."[2] There are other examples for magic features in user interfaces -- always depending on how strictly one interprets the underlying metaphor (see also [5] for a discussion of magic in user interfaces).

Most magic features appear as magic only when the spatial concept of the interface is made explicit. An example is the find command in a file system. As the file space is not made explicit, the find command (which provides a short-cut through the folder space) is not perceived as a magic feature. However users often construct their own model of how software works internally (frequently using spatial concepts for navigation) and the magic features may be difficult to understand in terms of these models. Therefore they are in the paradox situation of being on the one hand an important ingredient to make a (spatial) user interface more usable and at the same time they might be a usability problem when not designed well.

What about hypertext?

In hypertext we often are in a similar situation as in the find command. Linking essentially moves the user in an abstract space without giving much indication on the whereabouts. When calculating clusters in hypertexts a neighborhood relation is defined that makes the structure of the hypertext explicit. Links that do not fit into that clustering scheme then become shortcuts and magic features.

Another example is the structure inherent in the World Wide Web: Collection of Web-pages also form clusters that are located on the same server or in the same directory, or they form clusters around a topic even when located on several servers. Links leading out of such a cluster again lead to another context and therefore are magic features. But also the structure of the Web is hidden (it is noticeable through changing load times and URLs). It is advantageous that users don't have to know the location of Web nodes but they often are unpleasantly reminded of the Web's distributed nature when encountering particularly long load times or "server doesn't respond" messages.

Making magic features usable

The gist of all that is that the system should point out in advance if a transition in the abstract space of the information system / hypertext leads to a different context (= far away) or not. Magic features allow rapid change of context but when this change is not announced users are not prepared for this change and may be disoriented at first. When designing the user interface one of the objectives is therefore to help users grasp the context switch.

In general two things are necessary for that:

  1. Point out that a magic feature is special.
  2. The process of the context change has to be enacted (see [3] and [7] for more information on the concept of enactment), so that more information about the working of the magic feature and its destination is provided.

Taking the example of the alias in a file system, in particular the alias in the Macintosh file system. An alias to a folder looks very similar to the folder itself (they are distinguished by the name which is written in italics in the alias and by default has the world "alias" appended to it. However this name can be changed and it does not have to bear any resemblance to the object pointed at -- see figure).

Macintosh folder and alias of a folder

Objects and their aliases look too similar

This design makes the alias easier to understand at first but the similarity does not help understanding that it actually is a shortcut through the folder space and not identical to the real thing. Using the alias also does not really show that the user moves to another part of the folder space - maybe even to a folder located on another machine on the network.

Similarly in the WWW link anchors give information about their destination only when the author of the page thinks that is necessary. Systems like the Audible Web, that uses sound to give information about the link destination and the transfer process therefore are a step in the right direction. They provide more context information for the linking process [6] and can show if a link goes to a "close" or "distant" page.

Which metaphors to use for magic features?

Because magic features work differently they have to be learnt as separate features. They normally break the metaphor of the overall user interface and therefore they cannot be explored using the same affordances as the remaining user interface. Gaver wrote in [4]: Exploration of afforded actions leads to discovery of the system, rather than knowledge of the system metaphor leading to expectations of its affordances. To explore the affordances of magic features, these features first need to be pointed out as something special however. Otherwise users will be confused.

When the source domain of a metaphor comes from the everyday world then the metaphor for a magic feature that breaks this metaphor has to come from a magic world, so to speak. Examples are metaphors taken from theater or cinema like magic mirrors, teleporters, warp-drive and so forth. Such concepts can almost be considered general knowledge nowadays and therefore they are good candidates for metaphors for magic features.

(Footnote: As an interesting aside it should be mentioned that user interface metaphors themselves may serve as source domains for new metaphors. Where the Macintosh user interface once may have been explained with sentences as "like a desk and pieces of paper and a trashcan" to a novice, newer user interfaces sometimes are explained with sentences like "this thing works like a Macintosh folder" -- the user interface thus is a magic world that serves as source domain for new metaphors. Metaphors today often are a tangled web of metaphors and not always is it beneficial to try to untangle this web [9]).

Conclusions

Information spaces often do not use spatial metaphors for navigation because these metaphors sometimes hinder efficient navigation. To avoid consistency problems with the navigation metaphor the structure of the information space is hidden instead. When we accept that there are types of navigation that break the metaphor, while many others don't we do not have to hide the structure of the information space any more. Instead of mixing normal and special navigation and confusing users we can point out these magic features as something that goes beyond the basic metaphor and has to be learnt separately. To make magic features easier to understand we again can use metaphors -- these metaphors have to come from another source domain however. They have to be clearly marked as something special with their own affordances and they have to be enacted so that users can learn how they work.

Kaplan and Moulthrop wrote in [8, p.208]: We will have to re-think our conception of space in hypermedia, and by extension, the dominant metaphor of navigation that we use to describe transactions within it. A combination of real world and magic world metaphors may be what they argue for. It allows to create information spaces that go beyond a simple real-world space concept and still are understandable.

Acknowledgments

This work is made possible by a research grant from the Austrian "Fonds zur Förderung der wissenschaftlichen Forschung" (Dr. Erwin Schrödinger Stipendium), Grant J01021-MAT. I also wish to thank Werner Kuhn for valuable comments on early drafts of this paper.

References

[1] Tognazzini, B.: "Tog on Interface", Addison-Wesley, 1992

[2] Kuhn, W.: "7±2 Questions and Answers about Metaphors for GIS User Interfaces", in: Nyerges T.L. et al. (Eds.): "Cognitive Aspects of Human-Computer Interaction for Geographic Information Systems", Kluwer Academic Publishers, 1995, pp. 113-122

[3] Laurel, B.: "Computers as Theater", Addison-Wesley, 1993

[4] Gaver, W.W.: "Technology Affordances", Proc. of CHI'91, New Orleans, 1991, pp. 79-84

[5] Tognazzini, B.: "Principles, Techniques, and Ethics of Stage Magic and Their Application to Human Interface Design", Proc. of InterCHI'93, Amsterdam, 1993, pp. 355-362

[6] Albers, M., Bergman, E.: " The Audible Web: Auditory Enhancements for Mosaic", CHI'95 Conference Companion, pp. 318-319

[7] Bernstein, M.: "Enactment in Information Farming", Proc. of Hypertext'93, Seattle, pp. 242-249

[8] Kaplan, N., Moulthrop, S.: "Where No Mind Has Gone Before: Ontological Design for Virtual Spaces", Proc. of ECHT'94, Edinburgh, pp. 206-216

[9] Gaver, W.W.: "Oh What a Tangled Web We Weave: Metaphor and Mapping in Graphical Interfaces", CHI'95 Conference Companion, pp. 270-271

last modified 8/1999
andreas.dieberger@acm.org