User:Natasa Siencnik/notes/gentner/: Difference between revisions
(Created page with "== Abstract == '''Don Gentner / Jakob Nielson:''' The Anti-Mac Interface. In: <i>Communications of the ACM.</i> August 1996, Vol. 39, N°8. <br /> <br /> <div style="column-count...") |
|||
(One intermediate revision by the same user not shown) | |||
Line 14: | Line 14: | ||
#*designed for naive users without any previous computer experience | #*designed for naive users without any previous computer experience | ||
#*targeted at a narrow range of applications (office work, entertainment, multimedia) | #*targeted at a narrow range of applications (office work, entertainment, multimedia) | ||
#*weak computational | #*weak computational resources (computer with 128KB RAM, 400KB storage device, printer) | ||
#*supported by poor communication channels (screen, keyboard, mouse) | #*supported by poor communication channels (screen, keyboard, mouse) | ||
====Human Interface Design Principles==== | ====Human Interface Design Principles==== | ||
*based on fundamental principles of human-computer interaction | |||
*how do these principles limit the computer-human interface? | |||
#Metaphors | #Metaphors from familiar non-computer world | ||
#*computer files represented as documents in paper folders placed on desktop | #*computer files represented as documents in paper folders placed on desktop | ||
#*files deleted by dragging them to the trash can | #*files deleted by dragging them to the trash can | ||
#*trying to overcome the limitations of the desktop metaphor (rooms, buildings, village) | #*trying to overcome the limitations of the desktop metaphor (rooms, buildings, village) | ||
#*automobiles have developed their own interfaces without metaphors based on horses | #*automobiles have developed their own interfaces without metaphors based on horses | ||
# | #Problems with Metaphors | ||
#*target domain has features not in the source domain (e.g. replace command in text editor) | #*target domain has features not in the source domain (e.g. replace command in text editor) | ||
#*source domain has features not in the target domain (e.g. marking of typewriters) | #*source domain has features not in the target domain (e.g. marking of typewriters) | ||
#*some features exist in both domains but work differently (e.g. white space as character) | #*some features exist in both domains but work differently (e.g. white space as character) | ||
#Trash Can Metaphor | #Trash Can Metaphor | ||
#*single-trash-can metaphor has led to a system that fails to meet user's needs | |||
#*to avoid the confusion of multiple trash cans in the interface, all trash cans are combined | |||
#*when user empties the trash to create room on a floppy disk, both trash cans are deleted | |||
#*this is a limitation that does not serve the user's real needs | |||
#Desktop Metaphor | |||
#*save training time by taking advantage of having learned to operate a traditional office | |||
#*next generation of users will make their learning investments with computers | |||
#Direct Manipulation | |||
#*users interact directly with objects in the interface (e.g. drag and drop a document) | |||
#*user cannot group a related series of basic actions into one high-level action | |||
#See-and-Point | |||
#*users interact with computer by pointing at the objects they see on the screen | |||
#*we have lost all power of language, and cannot talk about objects that are not visible (yet) | |||
#*utilize more of the power of language to communicate more precisely | |||
#Consistency | |||
#*difficult to apply in real situation with wide array of conflicting things | |||
#*learning will be reduced if objects with similar function always look / behave alike | |||
#*in real life we have a wide range of appearances and they can still be easily recognizable | |||
#WYSIWYG | |||
#*what you see is what you get > document on the screen will look the same when printed | |||
#*problem that it is usually equivalent to WYSIATI (what you see is all there is) | |||
#*WYSIWYG document only shows final printed representation, not the user's intentions | |||
#*Standard Generalized Markup Language (SGML) preserves semantic meaning | |||
#*might be useful to have a different representation when preparing the document | |||
#*electronic information should be modularized and enabled to link to backup information | |||
#User Control | |||
#*many situations where we do not want to be in control > delegate to machines | |||
#*even if control is desirable, full control is becoming impossible with networked computers | |||
#Feedback and Dialog | |||
#*computer interface should provide the user with clear and immediate feedback on actions | |||
#*delegation of sequence of activities to an agent or encapsulated in a script | |||
#*then there is no longer a need for detailed and continuous feedback | |||
#Forgiveness | |||
#*user actions should generally be reversible and users should be warned of data loss | |||
#*computer needs to build a deeper model of our intentions and history | |||
#Perceived Stability | |||
#*elements in the computer interface should not be changed without user's involvement | |||
#*but dividing control between the user and the computer or networked computers | |||
#*stability can be boring | |||
#Aesthetic Integrity | |||
#*graphic design of the interface should be simple, clean, and consistent | |||
#*if computers could communicate with richer language, look would be less important | |||
#*richness can increase usability by making it easier to distinguish | |||
#Modelessness | |||
#*computer interface should not have distinct modes that restrict the user's actions | |||
#*users should be able to perform any task at any time | |||
#*problem of modelessness > user cannot cope with everything at once | |||
====Anti-Mac Interface==== | |||
#Central Role of Language | |||
#*language lets us refer to things not immediately present, potential actions | |||
#*encapsulate complex groups of objects or actions and refer to them with single name | |||
#*ability to deal with imprecise language will increase the computer's flexibility | |||
#*command line interfaces have some of the advantages of language | |||
#*command line interfaces have rich syntactic structure to form complex commands | |||
#*but only a limited number of commands and cannot tolerate synonyms, misspellings | |||
#Richer Internal Representation of Objects | |||
#*current interfaces have access to very little information about the used objects | |||
#*the only information about a file may be its name, size, and modification date, | |||
#*the type of data it contains, and the application that created it | |||
#*but it could include its authors, topic matter, keyword, importance, relations | |||
#More Expressive Interface | |||
#*richer internal representation of objects will allow more intelligent interpretation | |||
#*but it will also be reflected in a more expressive interface with external representation | |||
#*variety adds visual interest and helps us quickly to locate e.g. books in a shelve | |||
#Expert Users | |||
#*think about trade-offs between ease of learning and power in new interfaces | |||
#Shared Control | |||
#*computer-based agents have not yet progressed beyond simple tasks | |||
#*users still need to determine the balance of control in their environment | |||
====Conclusions==== | |||
*Macintosh interface as a starting point for considering future needs of user interfaces | |||
*outlines are impractical with the current state of computers and software | |||
*language understanding is still in its infancy | |||
*interface designers need to start work for the next generation of computers |
Latest revision as of 19:47, 23 October 2010
Abstract
Don Gentner / Jakob Nielson: The Anti-Mac Interface. In: Communications of the ACM. August 1996, Vol. 39, N°8.
Introduction
- Alternative Interfaces
- human interface is stuck, very little innovation in interface design anymore
- user has settled on the WIMP (windows, icons, menus, pointer) model
- violating basic assumptions as useful mental exercise to find new concepts
- article explores possible types of interfaces that could result in such a violation
- focus on Macintosh interface as prime example of current interface paradigm
- Macintosh Design
- designed for naive users without any previous computer experience
- targeted at a narrow range of applications (office work, entertainment, multimedia)
- weak computational resources (computer with 128KB RAM, 400KB storage device, printer)
- supported by poor communication channels (screen, keyboard, mouse)
Human Interface Design Principles
- based on fundamental principles of human-computer interaction
- how do these principles limit the computer-human interface?
- Metaphors from familiar non-computer world
- computer files represented as documents in paper folders placed on desktop
- files deleted by dragging them to the trash can
- trying to overcome the limitations of the desktop metaphor (rooms, buildings, village)
- automobiles have developed their own interfaces without metaphors based on horses
- Problems with Metaphors
- target domain has features not in the source domain (e.g. replace command in text editor)
- source domain has features not in the target domain (e.g. marking of typewriters)
- some features exist in both domains but work differently (e.g. white space as character)
- Trash Can Metaphor
- single-trash-can metaphor has led to a system that fails to meet user's needs
- to avoid the confusion of multiple trash cans in the interface, all trash cans are combined
- when user empties the trash to create room on a floppy disk, both trash cans are deleted
- this is a limitation that does not serve the user's real needs
- Desktop Metaphor
- save training time by taking advantage of having learned to operate a traditional office
- next generation of users will make their learning investments with computers
- Direct Manipulation
- users interact directly with objects in the interface (e.g. drag and drop a document)
- user cannot group a related series of basic actions into one high-level action
- See-and-Point
- users interact with computer by pointing at the objects they see on the screen
- we have lost all power of language, and cannot talk about objects that are not visible (yet)
- utilize more of the power of language to communicate more precisely
- Consistency
- difficult to apply in real situation with wide array of conflicting things
- learning will be reduced if objects with similar function always look / behave alike
- in real life we have a wide range of appearances and they can still be easily recognizable
- WYSIWYG
- what you see is what you get > document on the screen will look the same when printed
- problem that it is usually equivalent to WYSIATI (what you see is all there is)
- WYSIWYG document only shows final printed representation, not the user's intentions
- Standard Generalized Markup Language (SGML) preserves semantic meaning
- might be useful to have a different representation when preparing the document
- electronic information should be modularized and enabled to link to backup information
- User Control
- many situations where we do not want to be in control > delegate to machines
- even if control is desirable, full control is becoming impossible with networked computers
- Feedback and Dialog
- computer interface should provide the user with clear and immediate feedback on actions
- delegation of sequence of activities to an agent or encapsulated in a script
- then there is no longer a need for detailed and continuous feedback
- Forgiveness
- user actions should generally be reversible and users should be warned of data loss
- computer needs to build a deeper model of our intentions and history
- Perceived Stability
- elements in the computer interface should not be changed without user's involvement
- but dividing control between the user and the computer or networked computers
- stability can be boring
- Aesthetic Integrity
- graphic design of the interface should be simple, clean, and consistent
- if computers could communicate with richer language, look would be less important
- richness can increase usability by making it easier to distinguish
- Modelessness
- computer interface should not have distinct modes that restrict the user's actions
- users should be able to perform any task at any time
- problem of modelessness > user cannot cope with everything at once
Anti-Mac Interface
- Central Role of Language
- language lets us refer to things not immediately present, potential actions
- encapsulate complex groups of objects or actions and refer to them with single name
- ability to deal with imprecise language will increase the computer's flexibility
- command line interfaces have some of the advantages of language
- command line interfaces have rich syntactic structure to form complex commands
- but only a limited number of commands and cannot tolerate synonyms, misspellings
- Richer Internal Representation of Objects
- current interfaces have access to very little information about the used objects
- the only information about a file may be its name, size, and modification date,
- the type of data it contains, and the application that created it
- but it could include its authors, topic matter, keyword, importance, relations
- More Expressive Interface
- richer internal representation of objects will allow more intelligent interpretation
- but it will also be reflected in a more expressive interface with external representation
- variety adds visual interest and helps us quickly to locate e.g. books in a shelve
- Expert Users
- think about trade-offs between ease of learning and power in new interfaces
- Shared Control
- computer-based agents have not yet progressed beyond simple tasks
- users still need to determine the balance of control in their environment
Conclusions
- Macintosh interface as a starting point for considering future needs of user interfaces
- outlines are impractical with the current state of computers and software
- language understanding is still in its infancy
- interface designers need to start work for the next generation of computers