Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| anti-mac_interface [2020-06-29 14:30] – nik | anti-mac_interface [2026-01-04 16:58] (current) – nik | ||
|---|---|---|---|
| Line 3: | Line 3: | ||
| (via https:// | (via https:// | ||
| - | by Dona Gentner | + | by Dona Gentner and Jakoba Nielsen |
| At recent user interface conferences, | At recent user interface conferences, | ||
| Line 21: | Line 21: | ||
| 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. | 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 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? | 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.) | 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.) | ||
| - | Metaphors | + | ===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 3D 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. 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, | 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 3D 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. 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, | ||
| The three classic problems with metaphors [9] are: | 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" | + | * The target domain has features not in the source domain (e.g., telling the user that "a word processor is like a typewriter" |
| - | 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 has 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, | 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 has 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, | ||
| Line 42: | Line 43: | ||
| 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. | 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 | + | ===Direct Manipulation=== |
| Using direct manipulation, | Using direct manipulation, | ||
| Line 48: | Line 49: | ||
| 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). If the conversion requires several steps, this will be a very tedious process with direct manipulation, | 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). If the conversion requires several steps, this will be a very tedious process with direct manipulation, | ||
| - | See-and-Point | + | ===See-and-Point=== |
| The see-and-point principle states that users interact with the computer by pointing at the objects they can see on the screen. It's as if we have thrown away a million years of evolution, lost our facility with expressive language, and been reduced to pointing at objects in the immediate environment. Mouse buttons and modifier keys give us a vocabulary equivalent to a few different grunts. We have lost all the power of language, and can no longer talk about objects that are not immediately visible (all files more than one week old), objects that don't exist yet (future messages from my boss), or unknown objects (any guides to restaurants in Boston). | The see-and-point principle states that users interact with the computer by pointing at the objects they can see on the screen. It's as if we have thrown away a million years of evolution, lost our facility with expressive language, and been reduced to pointing at objects in the immediate environment. Mouse buttons and modifier keys give us a vocabulary equivalent to a few different grunts. We have lost all the power of language, and can no longer talk about objects that are not immediately visible (all files more than one week old), objects that don't exist yet (future messages from my boss), or unknown objects (any guides to restaurants in Boston). | ||
| Line 54: | Line 55: | ||
| If we want to order food in a country where we don't know the language at all, we're forced to go into the kitchen and use a see-and-point interface. With a little understanding of the language, we can point at menus to select our dinner from the dining room. But language allows us to discuss exactly what we would like to eat with the waiter or chef. Similarly, computer interfaces must evolve to let us utilize more of the power of language. Adding language to the interface allows us to use a rich vocabulary and gives us basic linguistic structures such as conditionals. Language lets us refer to objects that are not immediately visible. For example, we could say something like " | If we want to order food in a country where we don't know the language at all, we're forced to go into the kitchen and use a see-and-point interface. With a little understanding of the language, we can point at menus to select our dinner from the dining room. But language allows us to discuss exactly what we would like to eat with the waiter or chef. Similarly, computer interfaces must evolve to let us utilize more of the power of language. Adding language to the interface allows us to use a rich vocabulary and gives us basic linguistic structures such as conditionals. Language lets us refer to objects that are not immediately visible. For example, we could say something like " | ||
| - | Consistency | + | ===Consistency=== |
| Consistency is one of those principles that sounds like a great idea when you first come across it, but it is very difficult to apply the principle in any real situation where there is a wide array of conflicting things with which you can be consistent [8]. | Consistency is one of those principles that sounds like a great idea when you first come across it, but it is very difficult to apply the principle in any real situation where there is a wide array of conflicting things with which you can be consistent [8]. | ||
| Line 62: | Line 63: | ||
| Note that consistency is not symmetrical. Whereas we argue that objects with similar functions need not have consistent appearances or controls, it is still important objects with similar appearances have similar behavior and functions. Except as a joke, a pen that looks like a tennis shoe will not be very useful. | Note that consistency is not symmetrical. Whereas we argue that objects with similar functions need not have consistent appearances or controls, it is still important objects with similar appearances have similar behavior and functions. Except as a joke, a pen that looks like a tennis shoe will not be very useful. | ||
| - | WYSIWYG | + | ===WYSIWYG=== |
| What You See Is What You Get (WYSIWYG) means your document, as it appears on the screen, accurately reflects what it will look like when it is printed. This is certainly a big improvement over earlier computer-based text formatting systems such as troff, in which there was no obvious relation between the document' | What You See Is What You Get (WYSIWYG) means your document, as it appears on the screen, accurately reflects what it will look like when it is printed. This is certainly a big improvement over earlier computer-based text formatting systems such as troff, in which there was no obvious relation between the document' | ||
| Line 74: | Line 75: | ||
| In some sense, WYSIWYG is equivalent to the horselike tractor we discussed earlier in connection with metaphors. WYSIWYG assumes people want paper-style reports: Information might be produced (and even consumed) on screen, but it should still be structured the same way it was on paper. These days, however, who has time to read all the documents we get? In reality, people rarely read information from beginning to end the way they would have read a report in the good old days where even busy managers got at most a single report per day. Instead, electronic information should be modularized and presented in ways that encourage people to read as little as possible by popping information of interest to the specific user to the top, while enabling each user to link to backup information as needed. Object-oriented authoring and reading would allow the same piece of information to be presented at multiple levels and possibly from different perspectives. We should also mention that not all users can see. For blind users, information that is encoded with SGML-like rich intentional attributes can be represented in alternative formats (e.g., sound) in a much more usable fashion than is possible with simple screen readers that are limited to reading aloud from the pixels on the screen without knowing what they mean. | In some sense, WYSIWYG is equivalent to the horselike tractor we discussed earlier in connection with metaphors. WYSIWYG assumes people want paper-style reports: Information might be produced (and even consumed) on screen, but it should still be structured the same way it was on paper. These days, however, who has time to read all the documents we get? In reality, people rarely read information from beginning to end the way they would have read a report in the good old days where even busy managers got at most a single report per day. Instead, electronic information should be modularized and presented in ways that encourage people to read as little as possible by popping information of interest to the specific user to the top, while enabling each user to link to backup information as needed. Object-oriented authoring and reading would allow the same piece of information to be presented at multiple levels and possibly from different perspectives. We should also mention that not all users can see. For blind users, information that is encoded with SGML-like rich intentional attributes can be represented in alternative formats (e.g., sound) in a much more usable fashion than is possible with simple screen readers that are limited to reading aloud from the pixels on the screen without knowing what they mean. | ||
| - | User Control | + | ===User Control=== |
| It has become almost a religious crusade among WIMP advocates that the user should be in control---the user, not the computer, should initiate and control actions. The negative side of user control is that the user has to be in control. There are many situations where we do not want to be in control: flying an airliner, for example, or watching our toast in the morning to see that it doesn' | It has become almost a religious crusade among WIMP advocates that the user should be in control---the user, not the computer, should initiate and control actions. The negative side of user control is that the user has to be in control. There are many situations where we do not want to be in control: flying an airliner, for example, or watching our toast in the morning to see that it doesn' | ||
| Line 82: | Line 83: | ||
| Even if it were desirable, full control is becoming impossible with networked computers. User control assumes you are the only actor in the system, but these days, millions of people are on the Internet and can change the system behind your back. Indeed, it is one of the benefits of the Internet that new resources appear without any work on your part. It would be possible to conceptualize the Internet as a groupware application with 40 million users, but in reality, it is better thought of as a system without any centralized control in which things just happen without other users' asking you what you would like. | Even if it were desirable, full control is becoming impossible with networked computers. User control assumes you are the only actor in the system, but these days, millions of people are on the Internet and can change the system behind your back. Indeed, it is one of the benefits of the Internet that new resources appear without any work on your part. It would be possible to conceptualize the Internet as a groupware application with 40 million users, but in reality, it is better thought of as a system without any centralized control in which things just happen without other users' asking you what you would like. | ||
| - | Feedback and Dialog | + | ===Feedback and Dialog=== |
| This principle states that the computer interface should provide the user with clear and immediate feedback on any actions initiated by the user. It is closely connected with the previous principle of user control: If the user is required to be in control of all the details of an action, then the user's needs detailed feedback. But if a sequence of activities can be delegated to an agent or encapsulated in a script, then there is no longer a need for detailed and continuous feedback. The user doesn' | This principle states that the computer interface should provide the user with clear and immediate feedback on any actions initiated by the user. It is closely connected with the previous principle of user control: If the user is required to be in control of all the details of an action, then the user's needs detailed feedback. But if a sequence of activities can be delegated to an agent or encapsulated in a script, then there is no longer a need for detailed and continuous feedback. The user doesn' | ||
| Line 88: | Line 89: | ||
| A supervisor interacts very intensely with a new employee and solicits detailed progress reports, but as the employee gains experience and the supervisor gains confidence, the need for this detailed feedback and dialog decreases. The supervisor can assign complex tasks and be confident that "no news is good news." Rather than always providing the user with feedback on activities, the computer should be more flexible in the amount of feedback it provides. Initially, the computer could provide detailed feedback to familiarize the user with its operations and instill confidence; then the feedback could be scaled back over time and restricted to unusual circumstances or times when the user requests more feedback. | A supervisor interacts very intensely with a new employee and solicits detailed progress reports, but as the employee gains experience and the supervisor gains confidence, the need for this detailed feedback and dialog decreases. The supervisor can assign complex tasks and be confident that "no news is good news." Rather than always providing the user with feedback on activities, the computer should be more flexible in the amount of feedback it provides. Initially, the computer could provide detailed feedback to familiarize the user with its operations and instill confidence; then the feedback could be scaled back over time and restricted to unusual circumstances or times when the user requests more feedback. | ||
| - | Forgiveness | + | ===Forgiveness=== |
| The forgiveness principle states that user actions should generally be reversible and that users should be warned if they try to do something that will cause irreversible data loss. But even forgiveness can have a negative side. Consider as an example the common case where a user wants to copy a file to a floppy that does not have enough free space. The Macintosh gives an error message explaining there is not enough room and we must throw away 125K. But when we throw away some files and again attempt to copy the file, we get another error message stating there is not enough room unless we empty the trash, and asking if we want to empty the trash now. In this case forgiveness becomes a nuisance. The underlying problem here is that the computer has a very meager understanding of the interaction history. A stateless interface is doomed to present the inappropriate message because it cannot relate the user's action to its own prior recommendation to delete files. The computer needs to build a deeper model of our intentions and history. | The forgiveness principle states that user actions should generally be reversible and that users should be warned if they try to do something that will cause irreversible data loss. But even forgiveness can have a negative side. Consider as an example the common case where a user wants to copy a file to a floppy that does not have enough free space. The Macintosh gives an error message explaining there is not enough room and we must throw away 125K. But when we throw away some files and again attempt to copy the file, we get another error message stating there is not enough room unless we empty the trash, and asking if we want to empty the trash now. In this case forgiveness becomes a nuisance. The underlying problem here is that the computer has a very meager understanding of the interaction history. A stateless interface is doomed to present the inappropriate message because it cannot relate the user's action to its own prior recommendation to delete files. The computer needs to build a deeper model of our intentions and history. | ||
| - | Perceived Stability | + | ===Perceived Stability=== |
| Perceived stability means that elements in the computer interface should not be changed without the user's involvement. For example, icons on the desktop and windows should reappear as they were when the user last closed them. But it is a sure sign of a lack of confidence if a person' | Perceived stability means that elements in the computer interface should not be changed without the user's involvement. For example, icons on the desktop and windows should reappear as they were when the user last closed them. But it is a sure sign of a lack of confidence if a person' | ||
| Line 100: | Line 101: | ||
| The World-Wide Web is a prime illustration of the advantages of shared control in user interfaces. The Web changes constantly, and every time users connect to a home page, they might be presented with a completely new interface. For example, AT&T; changes its home page daily [3], and in designing Sun's home page we decided we needed to change it drastically every month to keep the users' interest [14]: Stability can be boring! Denying the principle of perceived stability can often make the interface simpler and more intuitive. We can be easily overwhelmed by all the capabilities of a large application, | The World-Wide Web is a prime illustration of the advantages of shared control in user interfaces. The Web changes constantly, and every time users connect to a home page, they might be presented with a completely new interface. For example, AT&T; changes its home page daily [3], and in designing Sun's home page we decided we needed to change it drastically every month to keep the users' interest [14]: Stability can be boring! Denying the principle of perceived stability can often make the interface simpler and more intuitive. We can be easily overwhelmed by all the capabilities of a large application, | ||
| - | Aesthetic Integrity | + | ===Aesthetic Integrity=== |
| The principle of aesthetic integrity states that the graphic design of the interface should be simple, clean, and consistent. Screens should be visually pleasant and easy to understand. Part of the need for aesthetic integrity derives from the limited expressiveness of current computers. If computers could communicate with a richer language, it would not be so important that everything have a " | The principle of aesthetic integrity states that the graphic design of the interface should be simple, clean, and consistent. Screens should be visually pleasant and easy to understand. Part of the need for aesthetic integrity derives from the limited expressiveness of current computers. If computers could communicate with a richer language, it would not be so important that everything have a " | ||
| Line 106: | Line 107: | ||
| As an extreme example, the old user interface to the Internet had great aesthetic integrity, with one " | As an extreme example, the old user interface to the Internet had great aesthetic integrity, with one " | ||
| - | Modelessness | + | ===Modelessness=== |
| Modelessness means the computer interface should not have distinct modes that restrict the user's actions depending on the mode he or she is in. Users should be able to perform any task at any time. Although modelessness seems to be an object of veneration among some Macintosh interface designers, even the section on modelessness in the Macintosh Human Interface Guidelines [2] is primarily devoted to explaining how to use modes successfully. The basic problem presented by modelessness is that the user cannot cope with everything at once. Users need the interface to narrow their attention and choices so they can find the information and actions they need at any particular time. Real life is highly moded [11]: What you can do in the swimming pool is different from what you can do in the kitchen, and people can easily distinguish between the two because of the richness of the experience and the ease with which we can move between environments. | Modelessness means the computer interface should not have distinct modes that restrict the user's actions depending on the mode he or she is in. Users should be able to perform any task at any time. Although modelessness seems to be an object of veneration among some Macintosh interface designers, even the section on modelessness in the Macintosh Human Interface Guidelines [2] is primarily devoted to explaining how to use modes successfully. The basic problem presented by modelessness is that the user cannot cope with everything at once. Users need the interface to narrow their attention and choices so they can find the information and actions they need at any particular time. Real life is highly moded [11]: What you can do in the swimming pool is different from what you can do in the kitchen, and people can easily distinguish between the two because of the richness of the experience and the ease with which we can move between environments. | ||
| - | The Anti-Mac Interface | + | ===The Anti-Mac Interface=== |
| Although this article starts as an exploration of alternatives to the individual Macintosh human interface principles, it has not quite ended up that way. Just as the Macintosh design principles are interrelated and give a resulting coherence to the Macintosh interface, violation of those principles also points to a coherent interface design that we call the Anti-Mac interface. | Although this article starts as an exploration of alternatives to the individual Macintosh human interface principles, it has not quite ended up that way. Just as the Macintosh design principles are interrelated and give a resulting coherence to the Macintosh interface, violation of those principles also points to a coherent interface design that we call the Anti-Mac interface. | ||
| Line 122: | Line 123: | ||
| * Shared control | * Shared control | ||
| - | The Central Role of Language | + | ===The Central Role of Language=== |
| Over the past million years, humans have evolved language as our major communication mode. Language lets us refer to things not immediately present, reason about potential actions, and use conditionals and other concepts not available with a see-and-point interface. Another important property of language missing in graphical interfaces is the ability to encapsulate complex groups of objects or actions and refer to them with a single name. An interface that can better exploit human language will be both more natural and more powerful. Finally, natural languages can cope with ambiguity and fuzzy categories. Adding the ability to deal with imprecise language to the computer interface will increase the computer' | Over the past million years, humans have evolved language as our major communication mode. Language lets us refer to things not immediately present, reason about potential actions, and use conditionals and other concepts not available with a see-and-point interface. Another important property of language missing in graphical interfaces is the ability to encapsulate complex groups of objects or actions and refer to them with a single name. An interface that can better exploit human language will be both more natural and more powerful. Finally, natural languages can cope with ambiguity and fuzzy categories. Adding the ability to deal with imprecise language to the computer interface will increase the computer' | ||
| Line 128: | Line 129: | ||
| We are not proposing, however, what AI researchers would call a " | We are not proposing, however, what AI researchers would call a " | ||
| - | A Richer Internal Representation of Objects | + | ===A Richer Internal Representation of Objects=== |
| Current interfaces have access to very little information about the objects he user deals with. For example, the only information known about a file may be its name, size, and modification date; the type of data it contains; and the application that created it. In order to deal more effectively with these objects, the computer needs a much richer representation of them. For a document, this representation could include its authors, topic matter, keywords, and importance; whether there are other copies; what other documents it is related to; and so forth. The list of attributes is similar to what would be needed by a good secretary who was expected to handle the documents intelligently. It is not necessary for the secretary to fully understand the document' | Current interfaces have access to very little information about the objects he user deals with. For example, the only information known about a file may be its name, size, and modification date; the type of data it contains; and the application that created it. In order to deal more effectively with these objects, the computer needs a much richer representation of them. For a document, this representation could include its authors, topic matter, keywords, and importance; whether there are other copies; what other documents it is related to; and so forth. The list of attributes is similar to what would be needed by a good secretary who was expected to handle the documents intelligently. It is not necessary for the secretary to fully understand the document' | ||
| - | A More Expressive Interface | + | ===A More Expressive Interface=== |
| The richer internal representation of objects will allow more intelligent interpretation of user commands, but it will also be reflected in a more expressive interface with a richer external representation. The Macintosh interface was originally designed for a 9-inch display that contained less than 200,000 black-and-white pixels. It is remarkable how well it has translated to today' | The richer internal representation of objects will allow more intelligent interpretation of user commands, but it will also be reflected in a more expressive interface with a richer external representation. The Macintosh interface was originally designed for a 9-inch display that contained less than 200,000 black-and-white pixels. It is remarkable how well it has translated to today' | ||
| Line 138: | Line 139: | ||
| In addition to richer output, richer input devices will allow the user more flexibility in manipulating objects, and monitoring devices like active badges [20] will allow the computer to accommodate the user's needs without explicit commands. | In addition to richer output, richer input devices will allow the user more flexibility in manipulating objects, and monitoring devices like active badges [20] will allow the computer to accommodate the user's needs without explicit commands. | ||
| - | Expert Users | + | ===Expert Users=== |
| The GUIs of contemporary applications are generally well designed for ease of learning, but there often is a trade-off between ease of learning on one hand, and ease of use, power, and flexibility on the other hand. Although you could imagine a society where language was easy to learn because people communicated by pointing to words and icons on large menus they carried about, humans have instead chosen to invest many years in mastering a rich and complex language. Today' | The GUIs of contemporary applications are generally well designed for ease of learning, but there often is a trade-off between ease of learning on one hand, and ease of use, power, and flexibility on the other hand. Although you could imagine a society where language was easy to learn because people communicated by pointing to words and icons on large menus they carried about, humans have instead chosen to invest many years in mastering a rich and complex language. Today' | ||
| Line 144: | Line 145: | ||
| It is sometimes claimed that humans have limited cognitive abilities and therefore will not be able to handle increasingly complex computers. Even though the human brain may stay about the same for the foreseeable future, it is demonstrably not true that a fixed human brain implies fixed abilities to use specific systems. As an example, consider the ability to survive in a jungle without modern weapons. Most readers of this article would probably fare rather poorly if they were dropped in a jungle and told to catch dinner with their bare hands. At the same time, anybody born and raised in the same jungle would probably perform the dinner-catching task superbly. The difference in performance between the two groups is due to the benefits of having grown up in an environment and fully internalized its signals and rules. As the example shows, two people with the same brain capacity can have very different capabilities when it comes to using a given system. We predict that people who have grown up with computers will be much more capable as computer users than the current generation of users. Thus, they will be able to use (and will in fact, demand) expressive interfaces with advanced means of expressing their wants. | It is sometimes claimed that humans have limited cognitive abilities and therefore will not be able to handle increasingly complex computers. Even though the human brain may stay about the same for the foreseeable future, it is demonstrably not true that a fixed human brain implies fixed abilities to use specific systems. As an example, consider the ability to survive in a jungle without modern weapons. Most readers of this article would probably fare rather poorly if they were dropped in a jungle and told to catch dinner with their bare hands. At the same time, anybody born and raised in the same jungle would probably perform the dinner-catching task superbly. The difference in performance between the two groups is due to the benefits of having grown up in an environment and fully internalized its signals and rules. As the example shows, two people with the same brain capacity can have very different capabilities when it comes to using a given system. We predict that people who have grown up with computers will be much more capable as computer users than the current generation of users. Thus, they will be able to use (and will in fact, demand) expressive interfaces with advanced means of expressing their wants. | ||
| - | Shared Control | + | ===Shared Control=== |
| But the entire burden should not be on the individual user. Computer-based agents have gotten attention from computer scientists and human interface designers in recent years, but their capabilities have not yet progressed beyond the most simple-minded tasks. Before people will be willing to delegate complex tasks to agents, we need agents skilled both in specific task areas and in communicating with users. The recent rapid rise in use of the Web illustrates the advantage of sharing control of your computer world with other people. By relinquishing control over a portion of the world, you can utilize the products of other people' | But the entire burden should not be on the individual user. Computer-based agents have gotten attention from computer scientists and human interface designers in recent years, but their capabilities have not yet progressed beyond the most simple-minded tasks. Before people will be willing to delegate complex tasks to agents, we need agents skilled both in specific task areas and in communicating with users. The recent rapid rise in use of the Web illustrates the advantage of sharing control of your computer world with other people. By relinquishing control over a portion of the world, you can utilize the products of other people' | ||
| Line 150: | Line 151: | ||
| A computer environment in which both humans and computer-based agents have active roles implies a mixed locus of control [13]. The user's environment will no longer be completely stable, and the user will no longer be totally in control. For general sanity, users still need to determine the balance of control in the different parts of their environment, | A computer environment in which both humans and computer-based agents have active roles implies a mixed locus of control [13]. The user's environment will no longer be completely stable, and the user will no longer be totally in control. For general sanity, users still need to determine the balance of control in the different parts of their environment, | ||
| - | Mutually Reinforcing Design Principles | + | ===Mutually Reinforcing Design Principles=== |
| During the relatively short history of computing, several changes have taken place in the ways computers are used and in the people who form the main user community. These changes in usage and users lead to important changes in user interfaces. Highly usable designs reflect a set of principles that are mutually reinforcing and that match the needs of the main users and their tasks. | During the relatively short history of computing, several changes have taken place in the ways computers are used and in the people who form the main user community. These changes in usage and users lead to important changes in user interfaces. Highly usable designs reflect a set of principles that are mutually reinforcing and that match the needs of the main users and their tasks. | ||
| Line 160: | Line 161: | ||
| The Anti-Mac principles outlined here are optimized for the category of users and data that we believe will be dominant in the future: people with extensive computer experience who want to manipulate huge numbers of complex information objects while being connected to a network shared by immense numbers of other users and computers. These new user interface principles also reinforce each other, just as the Mac principles did. The richer internal representation of objects naturally leads to a more expressive external representation and to increased possibilities for using language to refer to objects in sophisticated ways. Expert users will be more capable of expressing themselves to the computer using a language-based interface and will feel more comfortable with shared control of the interface because they will be capable of understanding what is happening, and the expressive interface will lead to better explanations. | The Anti-Mac principles outlined here are optimized for the category of users and data that we believe will be dominant in the future: people with extensive computer experience who want to manipulate huge numbers of complex information objects while being connected to a network shared by immense numbers of other users and computers. These new user interface principles also reinforce each other, just as the Mac principles did. The richer internal representation of objects naturally leads to a more expressive external representation and to increased possibilities for using language to refer to objects in sophisticated ways. Expert users will be more capable of expressing themselves to the computer using a language-based interface and will feel more comfortable with shared control of the interface because they will be capable of understanding what is happening, and the expressive interface will lead to better explanations. | ||
| - | Conclusions | + | ===Conclusions=== |
| First, to avoid misunderstandings, | First, to avoid misunderstandings, | ||
| Line 170: | Line 171: | ||
| To realize the full benefits from the Anti-Mac approach, we argue, it will not be sufficient to retrofit its features one at a time to systems that basically follow current user interface architectures. We believe an integrated design that builds a new user interface from the bottom up will be more coherent and will have a better potential for increasing user productivity by at least an order of magnitude. A full Anti-Mac system will likely have to be based on deep object structures in an architecture that supports network-distributed objects and detailed attributes that are sufficiently standardized to be shared among multiple functionality modules. Realistically speaking, such a complete redesign will take some time to appear. Even if the full system were not to appear for several years to come, it is necessary for detailed research to begin now to develop the needed features and to collect usability data on how the Anti-Mac characteristics should be shaped to truly meet users' needs. | To realize the full benefits from the Anti-Mac approach, we argue, it will not be sufficient to retrofit its features one at a time to systems that basically follow current user interface architectures. We believe an integrated design that builds a new user interface from the bottom up will be more coherent and will have a better potential for increasing user productivity by at least an order of magnitude. A full Anti-Mac system will likely have to be based on deep object structures in an architecture that supports network-distributed objects and detailed attributes that are sufficiently standardized to be shared among multiple functionality modules. Realistically speaking, such a complete redesign will take some time to appear. Even if the full system were not to appear for several years to come, it is necessary for detailed research to begin now to develop the needed features and to collect usability data on how the Anti-Mac characteristics should be shaped to truly meet users' needs. | ||
| - | Acknowledgments | + | ===Acknowledgments=== |
| We would like to thank Bruce Tognazzini, Ellen Isaacs, Robin Jeffries, Jonathan Grudin, Tom Erickson, and the members of the human interface group at SunSoft for valuable comments on this article. | We would like to thank Bruce Tognazzini, Ellen Isaacs, Robin Jeffries, Jonathan Grudin, Tom Erickson, and the members of the human interface group at SunSoft for valuable comments on this article. | ||
| Line 176: | Line 177: | ||
| References | References | ||
| - | | + | * |
| - | 2. Apple Computer. Macintosh Human Interface Guidelines. Addison-Wesley, | + | |
| - | 3. AT&T.; Home page at URL http:// | + | |
| - | 4. Brennan, S. E. Conversation as direct manipulation: | + | |
| - | 5. Clymer, F. Treasury of Early American Automobiles. McGraw-Hill, | + | |
| - | 6. Cypher, A. Eager: Programming repetitive tasks by example. In Proceedings of the ACM CHI'91 Conference Human Factors in Computing Systems (New Orleans, April 28--May 2) 1991,. pp. 33--39. | + | |
| - | 7. Gentner, D. R. Interfaces for learning: motivation and locus of control. In Cognitive Modelling and Interactive Environments in Language Learning, F. L. Engel, D. G. Bouwhuis, T. Boesser, and G. d' | + | |
| - | 8. Grudin, J. The case against user interface consistency. Commun. ACM 32, 10 (1989), 1164--1173. | + | |
| - | 9. Halasz, F., and Moran, T. P. Analogy considered harmful. In Proceedings of the ACM Conference on Human Factors in Computer Systems (Gaithersburg, | + | |
| - | 10. Hill, W.C., Hollan, J.D., Wroblewski, D., and McCandless, T. Edit wear and read wear. In Proceedings of the ACM CHI'92 Conference on Human Factors in Computing Systems., (Monterey, Calif., May 3--7) 1992, pp. 3--9. | + | |
| - | 11. Johnson, J. Modes in non-computer devices. Int. J. Man-Mach. Stud. 32 (1990), 423--438. | + | |
| - | 12. Malone, T. W., Grant, K. R., Turbak, R. A., Brobst, S. A., and Cohen, M. D. Intelligent information-sharing systems. Commun. ACM 30, 5 (1987), 484--497. | + | |
| - | 13. Nielsen, J. Noncommand user interfaces. Commun. ACM 36, 4 (1993), 83--99. | + | |
| - | 14. Nielsen, J. Interface design for Sun's WWW site. (June 1995). URL: http:// | + | |
| - | 15. Nielsen, J., and Sano, D. SunWeb: User interface design for Sun Microsystems' | + | |
| - | 16. Open Software Foundation.OSF/ | + | |
| - | 17. Shneiderman, | + | |
| - | 18. Sun Microsystems, | + | |
| - | 19. Tognazzini, B. The Starfire video prototype project: A case history. In Proceedings of the ACM CHI'94 Conference on Human Factors in Computing Systems (Boston, April 24--28), pp. 99--105. Film clips available at http:// | + | |
| - | 21. Weiser, M. The computer for the 21st century. Sci. Am. 265, 3 (1991), 94--104. | + | |
| - | 22. The Windows Interface: An Application Design Guide. Microsoft Press, Redmond, Wash., 1992. | + | |
| - | About the Authors: | + | ===About the Authors:=== |
| - | DON GENTNER is Senior Staff Engineer in Human Computer Interaction at Sun Microsystems. He works on human interface designs for current products and thinks about how people interact with technology. Email: don.gentner@sun.com, | + | DON GENTNER is Senior Staff Engineer in Human Computer Interaction at Sun Microsystems. He works on human interface designs for current products and thinks about how people interact with technology. Email: don.gentner@sun.com, |
| - | JAKOB NIELSEN is Distinguished Engineer for Desktop Technology at Sun Microsystems, | + | JAKOB NIELSEN is Distinguished Engineer for Desktop Technology at Sun Microsystems, |