Martin Frank, Jan. 30, 1997 Copyright Notice: For your use in class only. All rights reserved. These notes may not make any sense to you if you were not in class. Don Norman's book - Design of Everyday Things Chapter 1: The Psychopathology of Everyday Things (Unfailing indicator for design flaws: signs.) Affordances: the scissors, the hammer, doors that afford pushing rather than pulling, my story about mirrored bathroom cabinet Example: in 1987 a college student first exposed to a mouse lifts it up, clicks several times on its (single) button, and says "nothing's happening" Natural mappings: slide projector story, stovetop, Norman's refridgerator Feedback: you expect something immediate to happen when you act on a device (In return, unrelated device feedback can cause you to presume a causal connection where there is none.) Driving a car versus using a telephone (including advanced features, such as dailing *69/*70 to turn call waiting on and off). --> visibility of controls, mappings between controls and functions, overloading of controls Chapter 2: The Psychology of Everyday Actions Falsely blaming yourself. Read the RETURN-ENTER story, page 2 of chapter 2 Mental models: Tell the themostat story (percentage-on theory, valve theory). Reinforce the point that everyone forms models. Example: my father started using email only about two months ago, he uses an offline system where you write email offline and then make a "net call" to send and retrieve your email --> mail is silently gotten whenever you send mail --> he never realized he has to make a "net call" to *retrieve* email, his mental model was that incoming mail mysteriously appears on his computer Draw Diagram 2.2 on board (page 13, chapter 2) Gulf of execution: Does the system provide actions matching my intention? Gulf of evaluation: What state is the system in? (State information must be easy to get, easy to interpret, and match the person's mental model of the system.) Abbreviated version of Norman's seven stages: (1) Goal: What does the device do? (2a) Execution: What actions are possible? (2c) Execution: How easy is it to perform the action? (3a) Evaluation: What is the state of the system? (3c) Evaluation: Is the system in the desired state? (examples) Chapter 3: Knowledge "in the world" (rather than in your head) What is the key to the left of 'v' on your keyboard? (Point: it doesn't matter - knowledge is the physical world, and unconsciously in your brain) Human: Short-term memory versus long-term memory Memory for arbitrary things "type ESC then Control-Shift U" -> hard to learn -> hard to retain -> doesn't tell you what to do if somethnig goes wrong Memory for meaningful relationships turn lights on a motorcycle, Memory through explanation Chapter 4: Knowing what to do (just discuss the examples) Chapter 5: To Err Is Human Errors: Slips (automatic behavior) and Mistakes (conscious deliberation) Slips: form a correct goal, but mess up the action typically result of lack of attention Mistake: form the wrong goal Slips Capture Errors More frequently done activity suddenly takes charge. (often appears when two action sequences have steps in common) Description Errors The right and wrong object of an action are confused. Data driven Errors Dialing a room number rather than the phone number of the person the room number should be given to. Associative activation errors Phone rings -> you pick up and say 'come in' Loss of activation errors You go somewhere, then forget why you did. Mode errors Wrogn mode... explain good modes vs. bad (hidden) modes Slips - Design Lessons: point to confirmation story Designing for Errors (discuss four steps of page 24) -> locking keys in car problem: have to hold handle (personal note: never do, alway use key to lock) Warning signals: often not the answer -> people ignore or bypass them (personal: disconnecting car buzzer) warnings of a compiler alarm signals (everybody focuses on turning off the alarm, not the threat) Forcing functions: can't remove key unless you are in park (but not that there is no indication WHY the key is being removed) Car seats that force you to wear the seatbelts. Cash machine: you have to take the cash before the card comes out Things that should have a forcing function, but shouldn't: copiers (can't leave original), nintendo example, different plugs for different ports, can't insert a disk into a slot which has no drive behind it Chapter 7: User Centered Design Design Lessons: discuss chapter 7, page 2 1. Use both the knowledge in the world and the knowledge in the head metaphors such as the trash can use knowledge in the head placing a list of files on the desktop is knowledge in the world (the users do not have to remember the names of their files) knowlege in the world is not always superior to knowledge in the head (graphical user interface command vs. command-line commands) 2. Simplify the structure of tasks - make visible what would otherwise be invisible (aircraft cockpit instrumentation) - automate, but keep the task the same (aircraft auto-pilot) (but keep user in control - discuss "agents") - change the nature of the task 3. Make things visible: Bridge the gulfs of execution and evaluation (ex: what is possible, how should actions be done) (ev: what is the state? what was the effect of my action?) 4. Get the mappings right e.g. positioning of controls next to the things they operate on, or in the same spatial relationship 5. exploit the power of constraints - it seems like there is only one thing to do, which is the right thing (trashcan example) 6. design for error assume every possible error will be made think of errors as constructive steps towards the solution make it easy to reverse operations, make it hard to do irreversible operations design explorable systems (mention menus) exploit forcing functions 7. when all else fails, standardize brake is on the left of accelerator analog clocks turning a know clockwise closes it, same for screws Class exercise: In the context of registering for classes at USC, do an informal requirements collection. Hierarchical Task Description Data Flow Diagram