Intuition is a middle ground between having consciously learned something and knowing something instinctively. If we have learned that things glowing red can burn us, we tend to classify all red-glowing things as potentially dangerous until proven otherwise. We don’t necessarily know that the particular red-glowing thing is a danger, but it gives us a safe place to begin our exploration.
What we commonly refer to as intuition is actually a mental comparison between a new experience and the things we have already learned. You instantly intuit how to work a wastebasket icon, for example, because you once learned how a real wastebasket works, thereby preparing your mind to make the connection years later. But you didn’t intuit how to use the original wastebasket. It was just an extremely easy thing to learn. This brings us to the third type of interface, based on the fact that the human mind is an incredibly powerful learning machine that constantly and effortlessly learns new things.
Idiomatic interfaces
Idiomatic design, what Ted Nelson has called “the design of principles,” is based on the way we learn and use idioms — figures of speech like “beat around the bush” or
“cool.” Idiomatic user interfaces solve the problems of the previous two interface types by focusing not on technical knowledge or intuition of function, but rather on the learning of simple, nonmetaphorical visual and behavioral idioms to accomplish goals and tasks.
18_084113 ch13.qxp 4/3/07 6:06 PM Page 274
274
Part II: Designing Behavior and Form
Idiomatic expressions don’t provoke associative connections the way that metaphors do. There is no bush and nobody is beating anything. Idiomatically speaking, something can be both cool and hot and be equally desirable. We understand the idiom simply because we have learned it and because it is distinctive, not because we understand it or because it makes subliminal connections in our minds.
Yet, we are all capable of rapidly memorizing and using such idioms: We do so almost without realizing it.
If you cannot intuit an idiom, neither can you reason it out. Our language is filled with idioms that, if you haven’t been taught them, make no sense. If we say, “Uncle Joe kicked the bucket,” you know what we mean even though there is no bucket or kicking involved. You can’t know this by thinking through the various permutations of smacking pails with your feet. You can only learn this from context in something you read or by being consciously taught it. You remember this obscure connection between buckets, kicking, and dying only because humans are good at remembering things like this.
The human mind has a truly amazing capacity to learn and remember large numbers of idioms quickly and easily without relying on comparisons to known situations or an understanding of how or why they work. This is a necessity, because most idioms don’t have metaphoric meaning at all, and the stories behind most others were lost ages ago.
Graphical interfaces are largely idiomatic
It turns out that most of the elements of intuitive graphical interfaces are actually visual idioms. Windows, title bars, close boxes, screen-splitters, hyperlinks, and drop-downs are things we learn idiomatically rather than intuit metaphorically.
The Macintosh’s use of the trashcan to unmount an external FireWire disk before removing it is purely idiomatic (and many designers consider it a poor idiom), despite the visual metaphor of the trash can itself.
The ubiquitous mouse input device is not metaphoric of anything, but rather is learned idiomatically. There is a scene in the movie Star Trek IV where Scotty returns to 20th-century Earth and tries to speak into a mouse. There is nothing about the physical appearance of the mouse that indicates its purpose or use, nor is it comparable to anything else in our experience, so learning it is not intuitive.
However, learning to point at things with a mouse is incredibly easy. Someone probably spent all of three seconds showing it to you the first time, and you mastered it from that instant on. We don’t know or care how mice work, and yet even small children can operate them just fine. That is idiomatic learning.
18_084113 ch13.qxp 4/3/07 6:06 PM Page 275
Chapter 13: Metaphors, Idioms, and Affordances
275
Ironically, many of the familiar GUI elements that are often thought of as metaphoric are actually idiomatic. Artifacts like resizable windows and endlessly nested file folders are not really metaphoric — they have no parallel in the real world. They derive their strength only from their easy idiomatic learnability.
Good idioms must be learned only once
We are inclined to think that learning interfaces is hard because of our condition-ing based on experience with implementation-centric software. These interfaces are very hard to learn because you need to understand how the software works internally to use them effectively. Most of what we know we learn without understanding: things like faces, social interactions, attitudes, melodies, brand names, the arrangement of rooms, and furniture in our houses and offices. We don’t understand why someone’s face is composed the way it is, but we know that face. We recognize it because we have looked at it and automatically (and easily) memorized it.
All idioms must be learned; good idioms need to be learned only
DESIGN
principle
once.
The key observation about idioms is that although they must be learned, they are very easy to learn, and good ones need to be learned only once. It is quite easy to learn idioms like “neat” or “politically correct” or “the lights are on but nobody’s home” or “in a pickle” or “take the red-eye” or “grunge.” The human mind is capable of picking up idioms like these from a single hearing. It is similarly easy to learn idioms like radio buttons, close boxes, drop-down menus, and combo boxes.
Branding and idioms
Marketing and advertising professionals understand well the idea of taking a simple action or symbol and imbuing it with meaning. After all, synthesizing idioms is the essence of product branding, in which a company takes a product or company name and imbues it with a desired meaning. The golden arches of McDonalds, the three diamonds of Mitsubishi, the five interlocking rings of the Olympics, even Microsoft’s flying window are nonmetaphoric idioms that are instantly recognizable and imbued with common meaning. The example of an idiomatic symbol shown in Figure 13-1 illustrates its power.
18_084113 ch13.qxp 4/3/07 6:06 PM Page 276
276
Part II: Designing Behavior and Form
Figure 13-1 Here is an idiomatic symbol that has been imbued with meaning from its use, rather than by any connection to other objects. For anyone who grew up in the 1950s and 1960s, this otherwise meaningless symbol has the power to evoke a shiver of fear because it represents nuclear radiation. Visual idioms, such as the American flag, can be just as powerful as metaphors, if not more so. The power comes from how we use them and associate them, rather than from any innate connection to real-world objects.
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 changing channels, purchasing an item, finding a reference, setting a format, changing a photograph’s resolution, or performing statistical analysis, yet these operations are precisely the type of processes we use software to perform most frequently.
Computers and digital products are so powerful because of their ability to manage incredibly complex relationships within very large sets of data. Their very utility is based upon the fact that the human mind is challenged by such multidimensional problems, so almost by def
inition, these processes are not well suited to a simple, physical analog that people “automatically” comprehend.
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
18_084113 ch13.qxp 4/3/07 6:06 PM Page 277
Chapter 13: Metaphors, Idioms, and Affordances
277
in the mid-1990s. It relies on metaphors 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 13-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 bookmarking shortcut facility as a kludgy add-on, but alas, too little too late.
Figure 13-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 was not particularly easy to use after you became an intermediate. This was a shame, because some of the lower-level,
nonmetaphoric, 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 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
18_084113 ch13.qxp 4/3/07 6:06 PM Page 278
278
Part II: Designing Behavior and Form
software telephone also lets us 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 discussed in Chapter 2, transliterating mechanical processes onto the computer usually makes them worse than they were before.
Take the example of the ubiquitous file folder in modern computer operating systems. As a mechanism for organizing documents, it is quite easy to learn and understand because of its similarity to a physical file folder in a file cabinet. Unfortunately, as is the case with many metaphoric user interfaces, it functions a bit differently than its real world analog, which has the potential to create cognitive friction on the part of users. For example, in the world of paper, no one nests folders 10 layers deep, which makes it difficult for novice computer users to come to terms with the navigational structures of an operating system.
There are also gravely limiting consequences to the implementation of this mechanism. In the world of paper, it is impossible for the same document to be located in two different places in the filing cabinet, and as a result, filing is executed with a single organization scheme (such as alphabetically by name or numerically by account number). Our digital products are not intrinsically bound by such limitations, but blind adherence to an interface metaphor has drastically limited our ability to file a single document according to multiple organization schemes.
18_084113 ch13.qxp 4/3/07 6:06 PM Page 279
Chapter 13: Metaphors, Idioms, and Affordances
279
As Brenda Laurel said, “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 us that 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.
DESIGN
Never bend your interface to fit a metaphor.
principle
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.
18_084113 ch13.qxp 4/3/07 6:06 PM Page 280
280
Part II: Designing Behavior and Form
It offered sophisticated, direct manipulation of rich visua
l 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.
Building Idioms
When graphical user interfaces were first invented, they were so clearly superior that many observers credited the success to the interfaces’ graphical nature. This was a natural, but incorrect, assumption. The first GUIs, such as the original Mac, were better primarily because the graphical nature of their interfaces required a restriction of the range of vocabulary by which the user interacted with the system.
In particular, the input they could accept from the user went from an unrestricted command line to a tightly restricted set of mouse-based actions. In a command-line interface, users can enter any combination of characters in the language — a virtually infinite number. In order for a user’s entry to be correct, he needs to know exactly what the program expects. He must remember the letters and symbols with exacting precision. The sequence can be important, and sometimes even capitaliza-tion matters.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 39
