Don Gentner and Jakob Nielson Anti-MacThe Interface By exploring alternative interfaces that transcend the principles behind conven- tional graphical interfaces, a human-computer interface emerges that is based on language, a richer representa- tion of objects, expert users, and shared control. T recent user interface confer- ences, several speakers have lamented that the human interface is stuck. We seem to have settled on Athe WIMP (windows, icons, menus, point- er) model, and there is very little real innovation in interface design anymore. Physicists and mathematicians often stretch their imaginations by considering what the world would be like if some of their basic assumptions and principles were violated (for example, see [1]). This has led to new concepts such as non- Euclidean geometry, positrons, antimat- ter, and antigravity. At the least, violating basic assumptions is a useful mental exer- cise, but a surprising number of the resulting concepts have provided useful descriptions of the real world. In this article, we explore the types of interfaces that could result if we violate 70 August 1996/Vol. 39, No. 8 COMMUNICATIONS OF THE ACM ? Desk 10:01 a.m. ☞ Hallway 12 9 3 6 IN OUT '95 Figure 1. The Magic Cap interface is based on literal metaphors for desktops, buildings, and villages. each of the Macintosh human interface design princi- interface is not intended to be hostile to the Macin- ples. We focus on the Macintosh interface because it tosh, only different. In fact, human interface design- is a prime example of the current interface paradigm, ers at Apple and elsewhere have already incorporated and Apple Computer has published an explicit list of some of the Anti-Mac features into the Macintosh Macintosh human interface design principles [2]. desktop and applications. The Macintosh was These principles have not significantly changed since designed to be “the computer for the rest of us” and the introduction of the Macintosh; style guides for succeeded well enough that it became, as Alan Kay other popular graphical interfaces, such as Motif, once said, “the first personal computer good enough OPEN LOOK, and Windows [16, 18, 22], list a very to be criticized.” This article should be taken in the similar set of principles as the basis for their interfaces. same spirit. We should state at the outset that we are devoted The Macintosh was designed under a number of fans of the Macintosh human interface and frequent constraints, including: users of Macintosh computers. Our purpose is not to argue that the Macintosh human interface guidelines •It needed to sell to “naive users,” that is, users with- are bad principles, but rather to explore alternative out any previous computer experience. approaches to computer interfaces. The Anti-Mac •It was targeted at a narrow range of applications COMMUNICATIONS OF THE ACM August 1996/Vol. 39, No. 8 71 Anti-Mac principles are summa- Mac Anti-Mac rized in Table 1.) Metaphors Reality Metaphors Direct Manipulation Delegation The first Macintosh principle states that the interface should be See and Point Describe and Command based on metaphors with the familiar noncomputer world Consistency Diversity around us. In the Macintosh inter- WYSIWYG Represent Meaning face, computer files are represent- ed as documents in paper folders User Control Shared Control that are placed on a desktop. Files Feedback and Dialog System Handles Details are deleted by dragging them to the trash can. Many recent inter- Forgiveness Model User Actions faces have tried to overcome the Aesthetic Integrity Graphic Variet limitations of the desktop metaphor by extending it to some Modelessness Richer Cues other room or building metaphor (e.g., Bob or Magic Cap, Figure 1) Table 1. The Mac and Anti-Mac design principles or to a village metaphor (e.g., eWorld). These 3D designs try to (mostly office work, though entertainment and emulate virtual reality on a flat screen but often seem multimedia applications have been added later in to introduce a level of clunky indirectness in achiev- ways that sometimes break slightly with the stan- ing common user goals. They are navigationally cum- dard interface). bersome, asking users to go to the “other end of •It controlled relatively weak computational town” to pick up their email from the Post Office, and resources (originally a non-networked computer interactionally cumbersome, overloading users with with 128KB RAM, a 400KB storage device, and a additional windows and other interface elements dot-matrix printer). necessitated by the metaphor but not by the user’s •It was supported by highly impoverished communi- task. cation channels between the user and the comput- Although the use of metaphor may ease learning er (initially a small black-and-white screen with for the computer novice, it can also cripple the inter- poor audio output, no audio input, and no other face with irrelevant limitations and blind the design- sensors than the keyboard and a one-button er to new paradigms more appropriate for a mouse). computer-based application. The designers of the •It was a standalone machine that at most was con- Phelps farm tractor in 1901 based their interface on a nected to a printer. metaphor with the interface for the familiar horse: farmers used reins to control the tractor. The tractor These constraints have all been relaxed somewhat was steered by pulling on the appropriate rein, both during the 12 years since the introduction of the Mac- reins were loosened to go forward and pulled back to intosh, but we will explore what might happen if they stop, and pulling back harder on the reins caused the were to be eliminated completely. tractor to back up [5]. It’s clear in hindsight that this was a dead end, and automobiles have developed The Macintosh Human Interface Design Principles their own user interfaces without metaphors based on According to the Macintosh guidelines [2], the earlier technologies. Nonetheless, people today are design of human interfaces for Macintosh system designing information-retrieval interfaces based on software and applications is based on a number of metaphors with books, even though young folks fundamental principles of human-computer interac- spend more time flipping television channels and tion. These principles have led to excellent graphi- playing video games than they do turning the pages cal interfaces, but we wonder: How do these of books. principles limit the computer-human interface? The three classic problems with metaphors [9] What types of interfaces would result from violating are: these principles? We will address these two questions for each of the • The target domain has features not in the source Macintosh human interface design principles. (The domain (e.g., telling the user that “a word proces- Macintosh design principles and their corresponding sor is like a typewriter” would not lead the user to 72 August 1996/Vol. 39, No. 8 COMMUNICATIONS OF THE ACM look for the replace command). • The source domain has features not in the target domain (a type- writer has the ability to mark up any form you receive in the mail, but a user trying to do that on current computer systems will normally fail). • Some features exist in both domains but work very different- ly (the treatment of white space representing space characters, tabs, and line feeds is very differ- ent on typewriters and in word processors). Therefore, users may have trouble seeing beyond the metaphor to use the system in the ways it was intended. It is possible to design interfaces to map very closely to metaphors (e.g., Bob Mack’s NOSE–no-sur- prise editor–really did act like a typewriter in all respects), but those interfaces will often be very low-powered and suited mainly for walk-up-and-use situations. S an example of the limita- tions of the desktop meta- phor, consider the trash can Figure 2. We wish to convert all the PICT files into icons. This task on the Macintosh desktop. It involves several steps and would be very difficult to accomplish with direct Ais a fine metaphor for the wastebas- manipulation. A simple scripting language provides a natural specification ket in an office. In both cases we of the task. dispose of objects by putting them in the trash can and we’re able to retrieve documents by the trash can metaphor, even though it does not we had thrown out until the trash is emptied. Howev- have an analogy in the real world. er, the limits of the single-trash-can metaphor has led Metaphors not only constrain and mislead users, to a system that fails to meet the user’s needs and they can also limit designers’ ability to invent more causes confusion by masking the realities of the powerful interface mechanisms. For example, we are implementation. In the underlying implementation, as guilty as anybody for using the tired book there are separate trash containers for each volume, metaphor: When we recently designed the user inter- such as a hard disk or a floppy disk, but to avoid the face to 300MB worth of Sun’s online documentation, confusion of multiple trash cans in the interface, the we used a book metaphor to unify the icons, the contents of the trash containers for all mounted vol- vocabulary, and the hierarchical structure of the umes are combined and shown as a single desktop user’s navigation. Our excuse was that the interface trash can. Because there is only one trash can in the will display information originally written as separate metaphor, if the user empties the trash to create printed manuals and that it would have been confus- room on a floppy disk, the trash contents on both the ing to use a free-form hyperspace model to represent floppy and the hard disk are deleted, even though this text.