Design and Interaction, Part 2 31 January 2006 Kathy E. Gill

Our goal : flow  The process of an optimal experience  The activity feels seamless  It is intrinsically enjoyable  Individual loses self-consciousness

Eight Golden Rules of Interface Design (1/3)  Strive for consistency (the most frequently violated rule): Terminology Prompts Menus Help screens Color Layout Capitalization Fonts

Eight Golden Rules of Interface Design (2/3)  Let frequent users use shortcuts Abbreviations Special keys Hidden commands Macro facilities  Offer informative feedback  Design dialogs to yield closure Sequences of actions should be organized into groups Beginning, middle, and an end

Eight Golden Rules of Interface Design (3/3)  Offer error prevention and simple error handling  Permit easy reversal of actions  Support internal locus of control  Reduce short-term memory load

Effective navigation Clearly communicates  Where am I?  Where have I been?  Where can I go?

Navigation icons  Should not require explanation  Must represent the correct concept  Must be visually distinct  Are appropriately sized  Text (label) is often the best visual cue

Menus (1/2)  Types Static, pull down, fly-out, pop-up Recognition, not recall (memory)  Menu organization Alphabetical Chronological Categorical

Menus (2/2)  Provide real-estate savings But have invisible info  Pull-down, fly-out Horizontal or vertical  Pop up menus Appear at various places on the screen

Bridging Gulf of Execution  Hick’s Law : number of choices directly affects the size of the Gulf of Execution  Fitt's Law : time required to acquire a target is a function of the distance to, placement of, and size of the target.  How does this relate to navigation?

KISS  Remember each bit of info competes with other bits  Eliminate irrelevant information

From The Interface Hall of Shame What not to do!

The Humane Interface  “An interface is humane if it is responsive to human needs and considerate of human frailties.” Raskin, The Humane Interface (6)  Requires knowledge of how humans and machines operate

Object-Action Model of Interaction  Understand tasks Evaluate real-world objects and the actions applied to those objects  Create interface representations Objects and actions  Make interface actions visible to users

Task Hierarchies  Computer system designers must generate a hierarchy of objects and actions (the interaction) that successfully models user tasks:  Representations in pixels on a screen  Representations in physical devices  Representations in voice or other audio cue

Semantic Understanding  Understand how the process works, the meaning of an action A mouse click A submit button

Syntactic Understanding  Understand the specific rules of behavior that achieve an action In Windows, double-click on a file to launch (open) the application and load file On the Web, single-click an underlined word to go to a new Web page

When Syntax Vanishes (1/2)  We are forced to maintain a profusion of device-dependent details in our memory. Which action erases a character? Which abbreviations are permissible? Which of the numbered function keys produces the previous screen?

When Syntax Vanishes (2/2)  Learning, use and knowledge retention is hampered when details vary across systems unpredictably  Syntactic knowledge is learned through repeated usage  Syntactic knowledge is system dependent -- our visitors perceive “the Web” as a system, violate only after careful deliberation

Our Job  To minimize syntactic/memory burdens Familiar objects and actions represent their task objects and actions Standard (or de facto standard) widgets  Why the mailbox did not work as early icon - not cross-cultural

Five Tests of Effectiveness (1/2)  Time to learn How long does it take for typical members of the community to learn relevant task?  Speed of performance How long does it take to perform relevant benchmarks?  Rate of errors by users How many and what kinds of errors are commonly made during typical applications?

Five Tests of Effectiveness (2/2)  Retention over time Frequency of use and ease of learning help make for better user retention  Subjective satisfaction Allow for user feedback – interviews (focus groups), online surveys (both free-form comments and satisfaction scales).

Design for Diversity  Personality differences  Cultural and international diversity  Users with disabilities  Elderly users  Anything else?

Raskin’s Rules  The user should set the pace of the interaction  Error avoidance, facilitated with “undo/redo”  Accessible to the naïve, efficient for the expert

Errors are not mistakes!  Mistakes are the result of conscious deliberation  Slips result from automatic behavior Norman’s Types: capture, description, data-driven, associative activation, loss-of- activation and mode errors

Good Error Messages  Polite  Illuminating  Treat the user with respect

Design for Error  Minimize occurrence by understanding the causes of errors  Make detection and recovery easier  Change the attitude toward error from “stupid user” to “stupid design”

One small problem:  When you design an error-tolerant system, people come to rely on that system (it had best be reliable!) Anti-lock brakes (ABS) Blade guard on circular saw Anything else?

To increase errors, add a little:  Social pressure  Time pressure  Economic pressure In other words, real life!

Resultant design philosophy:  Put knowledge in the world (iow,make options visible)  Remember the three questions: Where am I, where can I go, where have I been?  Design for errors

The End!  Apologies for the background noises as I advanced the slides in outline view … one take only and I don’t have Jyotsna’s production skills. :)