The Anti-Mac Interface

Summary: We reverse all of the core design principles behind the Macintosh human interface guidelines to arrive at the characteristics of the Internet desktop. Originally published as: Gentner, D., and Nielsen, J.: The Anti-Mac interface, Communications of the ACM 39, 8 (August 1996), 70–82. (See also: my appreciation of the Macintosh on its 25th anniversary.) By exploring alternative interfaces that transcend the principles behind conventional graphical interfaces, a human-computer interface emerges that is based on language, a richer representation of objects, expert users, and shared control. At recent user interface conferences, several speakers have lamented that the human interface is stuck. We seem to have settled on the WIMP (windows, icons, menus, pointer) 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, antimatter, and antigravity. At the least, violating basic assumptions is a useful mental exercise, 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 each of the Macintosh human interface design principles. We focus on the Macintosh interface because it is a prime example of the current interface paradigm, and Apple Computer has published an explicit list of Macintosh human interface design principles [2]. These principles have not significantly changed since the introduction of the Macintosh; style guides for other popular graphical interfaces, such as Motif, OPEN LOOK, and Windows [16, 18, 22], list a very similar set of principles as the basis for their interfaces. We should state at the outset that we are devoted fans of the Macintosh human interface and frequent users of Macintosh computers. Our purpose is not to argue that the Macintosh human interface guidelines are bad principles, but rather to explore alternative approaches to computer interfaces. The Anti-Mac interface is not intended to be hostile to the Macintosh, only different. In fact, human interface designers at Apple and elsewhere have already incorporated some of the Anti-Mac features into the Macintosh desktop and applications.

The Macintosh was designed to be "the computer for the rest of us" and succeeded well enough that it became, as Alan Kay once said, "the first personal computer good enough to be criticized." This article should be taken in the same spirit. The Macintosh was designed under a number of constraints, including: It needed to sell to "naive users," that is, users without any previous computer experience. It was targeted at a narrow range of applications (mostly office work, though entertainment and multimedia applications have been added later in ways that sometimes break slightly with the standard interface). It controlled relatively weak computational resources (originally a non-networked computer with 128KB RAM, a 400KB storage device, and a dot-matrix printer). It was supported by highly impoverished communication channels between the user and the computer (initially a small black-and-white screen with poor audio output, no audio input, and no other sensors than the keyboard and a one-button mouse). It was a standalone machine that at most was connected to a printer. These constraints have all been relaxed somewhat during the 12 years since the introduction of the Macintosh, but we will explore what might happen if they were to be eliminated completely. The Macintosh Human Interface Design Principles The Anti-Mac Interface Conclusions References The Macintosh Human Interface Design Principles According to the Macintosh guidelines [2], the design of human interfaces for Macintosh system software and applications is based on a number of fundamental principles of human-computer interaction. These principles have led to excellent graphical interfaces, but we wonder: How do these principles limit the computer-human interface? What types of interfaces would result from violating these principles? We will address these two questions for each of the Macintosh human interface design principles. (The Macintosh design principles and their corresponding Anti-Mac principles are summarized in Table 1.) Table 1. The Mac and Anti-Mac design principles. Mac Anti-Mac Metaphors Reality Direct Manipulation Delegation See and Point Describe and Command Consistency Diversity WYSIWYG Represent Meaning User Control Shared Control Feedback and Dialog System Handles Details Forgiveness Model User Actions Aesthetic Integrity Graphic Variety Modelessness Richer Cues Metaphors The first Macintosh principle states that the interface should be based on metaphors with the familiar noncomputer world around us. In the Macintosh interface, computer files are represented as documents in paper folders that are placed on a desktop.

Files are deleted by dragging them to the trash can. Many recent interfaces have tried to overcome the limitations of the desktop metaphor by extending it to some other room or building metaphor (e.g., Bob or Magic Cap, Figure 1) or to a village metaphor (e.g., eWorld). These 3-D designs try to emulate virtual reality on a flat screen but often seem to introduce a level of clunky indirectness in achieving common user goals. They are navigationally cumbersome, asking users to go to the "other end of town" to pick up their email from the Post Office, and interactionally cumbersome, overloading users with additional windows and other interface elements necessitated by the metaphor but not by the user's task. (Note the link in the upper right to move out into the hallway, as shown in the next screenshot.) Figure 1. The Magic Cap interface is based on literal metaphors for desktops, buildings, and villages. Although the use of metaphor may ease learning for the computer novice, it can also cripple the interface with irrelevant limitations and blind the designer to new paradigms more appropriate for a computer-based application. The designers of the Phelps farm tractor in 1901 based their interface on a metaphor with the interface for the familiar horse: farmers used reins to control the tractor. The tractor was steered by pulling on the appropriate rein, both reins were loosened to go forward and pulled back to stop, and pulling back harder on the reins caused the tractor to back up [5]. It's clear in hindsight that this was a dead end, and automobiles have developed their own user interfaces without metaphors based on earlier technologies. Nonetheless, people today are designing information-retrieval interfaces based on metaphors with books, even though young folks spend more time flipping television channels and playing video games than they do turning the pages of books. The three classic problems with metaphors [9] are: The target domain has features not in the source domain (e.g., telling the user that "a word processor is like a typewriter" would not lead the user to look for the replace command). The source domain has features not in the target domain (a typewriter 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 differently (the treatment of white space representing space characters, tabs, and line feeds is very different 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-surprise 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. As an example of the limitations of the desktop metaphor, consider the trash can on the Macintosh desktop. It is a fine metaphor for the wastebasket in an office. In both cases we dispose of objects by putting them in the trash can and we're able to retrieve documents we had thrown out until the trash is emptied. However, the limits of the single-trash-can metaphor have led to a system that fails to meet the user's needs and causes confusion by masking the realities of the implementation. In the underlying implementation, there are separate trash containers for each volume, such as a hard disk or a floppy disk, but to avoid the confusion of multiple trash cans in the interface, the contents of the trash containers for all mounted volumes are combined and shown as a single desktop trash can. Because there is only one trash can in the metaphor, if the user empties the trash to create room on a floppy disk, the trash contents on both the floppy and the hard disk are deleted, even though there was no need to delete files from the hard disk's trash can. The desktop metaphor has enforced a limitation on the interface that does not serve the user's real needs. An alternative approach would be to simply cross out files and have them disappear (perhaps to a temporary limbo before being permanently discarded). This approach avoids the problems caused by the trash can metaphor, even though it does not have an analogy in the real world. Metaphors not only constrain and mislead users, they can also limit designers' ability to invent more powerful interface mechanisms. For example, we are as guilty as anybody for using the tired book metaphor: When we recently designed the user interface to 300MB worth of Sun's online documentation, we used a book metaphor to unify the icons, the vocabulary, and the hierarchical structure of the user's navigation.

Our excuse was that the interface will display information originally written as separate printed manuals and that it would have been confusing to use a free-form hyperspace model to represent this text. There is no doubt, however, that the book metaphor prevented us from introducing desirable features like the ability to reorder the chapters according to their relevance scores after a search. The desktop metaphor assumes we save training time by taking advantage of the time that users have already invested in learning to operate the traditional office with its paper documents and filing cabinets. But the next generation of users will make their learning investments with computers, and it is counterproductive to give them interfaces based on awkward imitations of obsolete technologies. Instead, we need to develop new interface paradigms based on the structure of computer systems and the tasks users really have to perform, rather than paradigms that enshrine outmoded technology. The way to advance the interface is not to develop ever-more-faithful imitations of the desktop, but instead to escape the limitations of the desktop especially as computers themselves become ubiquitous [21] and are used away from the desk. Direct Manipulation Using direct manipulation, users interact directly with objects in the interface [17]. The archetypal example is to move a file from one directory to another by opening the original folder and using the mouse pointer to drag the file icon to the destination folder. This procedure works well for simple actions with a small number of objects, but as the number of actions or objects increases, direct manipulation quickly becomes repetitive drudgery. The dark side of a direct manipulation interface is that you have to directly manipulate everything. Instead of an executive who gives high-level instructions, the user is reduced to an assembly line worker who must carry out the same task over and over. Direct manipulation also means that users must always operate at the atomic level. They cannot group a related series of basic actions into one high-level action or use conditionals. Suppose we have a group of images and want to convert all of the PICT files into icons (see Figure 2). Figure 2. We wish to convert all the PICT files into icons. This task involves several steps and would be very difficult to accomplish with direct manipulation. A simple scripting language provides a natural specification of the task. If the conversion requires several steps, this will be a very tedious process with direct manipulation, but a simple scripting language provides a natural means for specifying this task.