Further Limitations of Metaphors

If we depend on metaphors to create user interfaces, we encounter not only the minor problems already mentioned, but also two more major problems: Metaphors are hard to find and they constrict our thinking.

Finding good metaphors

It may be easy to discover visual metaphors for physical objects like printers and documents. It can be difficult or impossible to find metaphors for processes, relationships, services, and transformations — the most frequent uses of software. It can be extremely daunting to find a useful visual metaphor for buying a ticket, changing channels, purchasing an item, finding a reference, setting a format, rotating a tool, or changing resolution; yet these operations are precisely the type of processes we use software to perform most frequently.

The problems with global metaphors

The most significant problem with metaphors, however, is that they tie our interfaces to mechanical age artifacts. An extreme example of this was Magic Cap, a handheld communicator interface introduced with some fanfare by General Magic in the mid-1990s. It relies on metaphor for almost every aspect of its interface. You access your messages from an inbox or a notebook on a desk. You walk down a hallway that is lined with doors representing secondary functions. You go outside to access third-party services, which as you can see in Figure 20-2, are represented by buildings on a street. You enter a building to configure a service, and so on. The heavy reliance on this metaphor means that you can intuit the basic functioning of the software; but the downside is that, after you understand its function, the metaphor adds significantly to the overhead of navigation. You must go back out onto the street to configure another service. You must go down the hallway and into the game room to play Solitaire. This may be normal in the physical world, but there is no reason for it in the world of software. Why not abandon this slavish devotion to metaphor and give the user easy access to functions? It turns out that a General Magic programmer later created a book marking shortcut facility as a kludgy add-on, but alas, too little too late.

Figure 20-2: The Magic Cap interface from General Magic was used in products from Sony and Motorola in the mid-1990s. It is a tour de force of metaphoric design. All the navigation in the interface, and most other interactions as well, were subordinated to the maintenance of spatial and physical metaphors. It was surely fun to design, but not particularly easy to use after you became an intermediate. This was a shame, because some of the lower-level, non-metaphoric data-entry interactions were quite sophisticated and well designed for the time.

General Magic's interface relies on what is called a global metaphor. This is a single, overarching metaphor that provides a framework for all the other metaphors in the system. The desktop of the original Macintosh is also considered a global metaphor.

A hidden problem of global metaphors is the mistaken belief that other lower-level metaphors consistent with them enjoy cognitive benefits by association. The temptation is irresistible to stretch the metaphor beyond simple function recognition: That software telephone also lets you dial with buttons just like those on our desktop telephones. We see software that has address books of phone numbers just like those in our pockets and purses. Wouldn't it be better to go beyond these confining, industrial-age technologies and deliver some of the real power of the computer? Why shouldn't our communications software allow multiple connections or make connections by organization or affiliation, or just hide the use of phone numbers altogether?

It may seem clever to represent your dial-up service with a picture of a telephone sitting on a desk, but it actually imprisons you in a limited design. The original makers of the telephone would have been ecstatic if they could have created a phone that let you call your friends just by pointing to pictures of them. They couldn't because they were restricted by the dreary realities of electrical circuits and Bakelite moldings. On the other hand, today we have the luxury of rendering our communications interfaces in any way we please — showing pictures of our friends is completely reasonable — yet we insist on holding these concepts back with representations of obsolete technology.

There are two snares involved in extending metaphors, one for the user and one for the designer. After the user depends on the metaphor for recognition, he expects consistency of behavior with the real-world object to which the metaphor refers. This causes the snare for the designer, who now, to meet user expectations, is tempted to render the software in terms of the metaphor's mechanical age referent. As we saw in Part I, transliterating mechanical processes onto the computer usually makes them worse than they were before.

Brenda Laurel has said (1991), "Interface metaphors rumble along like Rube Goldberg machines, patched and wired together every time they break, until they are so encrusted with the artifacts of repair that we can no longer interpret them or recognize their referents." It amazes me that software designers, who can finally create that dream-phone interface, give us the same old telephone simply because they were taught that a strong, global metaphor is a prerequisite to good user-interface design. Of all the misconceptions to emerge from Xerox PARC, the global metaphor myth is the most debilitating and unfortunate.

Idiomatic design is the future of interaction design. Using this paradigm, we depend on the natural ability of humans to learn easily and quickly as long as we don't force them to understand how and why. There is an infinity of idioms waiting to be invented, but only a limited set of metaphors waiting to be discovered. Metaphors give first-timers a penny's worth of value but cost them many dollars' worth of problems as they continue to use the software. It is always better to design idiomatically, using metaphors only when a truly appropriate and powerful one falls in our lap.

Use metaphors if you can find them, but don't bend your interface to fit some arbitrary metaphoric standard.

AXIOM 

Never bend your interface to fit a metaphor.

Macs and metaphors: A revisionist view

In the mid-1970s, the modern graphical user interface (GUI) was invented at Xerox Palo Alto Research Center (PARC). The GUI — as defined by PARC — consisted of many things: windows, buttons, mice, icons, visual metaphors, and drop-down menus. Together they have achieved an unassailable stature in the industry by association with the empirical superiority of the ensemble.

The first commercially successful implementation of the PARC GUI was the Apple Macintosh, with its desktop metaphor: the wastebasket, overlapping sheets of paper (windows), and file folders. The Mac didn't succeed because of these metaphors, however. It succeeded for several other reasons, including an overall attention to design and detail. The interaction design advances that contributed were:

• It defined a tightly restricted but flexible vocabulary for users to communicate with applications, based on a very simple set of mouse actions.

• It offered sophisticated direct manipulation of rich visual objects on the screen.

• It used square pixels at high resolution, which enabled the screen to match printed output very closely, especially the output of Apple's other new product: the laser printer.

Metaphors helped structure these critical design features and made for good marketing copy, but were never the main appeal. In fact, the early years were rather rocky for the Mac as people took time to grow accustomed to the new, GUI way of doing things. Software vendors were also initially gun-shy about developing for such a radically different environment (Microsoft being the exception).

However, people were eventually won over by the capability of the system to do what other systems couldn't: WYSIWYG (what you see is what you get) desktop publishing. The combination of WYSIWYG interfaces and high-quality print output (via the LaserWriter printer) created an entirely new market that Apple and the Mac owned for years. Metaphors were but a bit-player (no pun intended) in the Mac's success.