Read the paragraphs that are colored - we assume that you have read them by the end of the course. The rest of the chapters are not required, although some of them contain good ideas. Don't read Part IV, it's waste of your time.
| Chapter | Relevancy % | Contents | Notes |
|---|---|---|---|
| Part I (p. 9-50) |
|||
| 1. | 100 | Users' goals. Don't make the user look stupid. Context. Features. Ease of learning. | |
| 2. | 80 | Most software isn't designed. | |
| 3. | 100 | Implementation model and the user's mental model. Users don't understand Boolean. Examples: WinFax, Calendar. | |
| 4. | 40 | Visual vs. textual representation, icons, visual pattern matching. The Canonical vocabulary. | Icon examples (p. 45-46) are unsuccessful, but the idea is great. Not required: Canonical vocabulary (p. 47-49). |
| Part II (p. 51-124) |
|||
| 5. | 100 | Metaphors and idioms, affordances. Examples: MagiCap, software telephone. | |
| 6. | 20 | History (Xerox, Apple), modes, overlapping and tiled windows, virtual desktop. | |
| 7. | 100 | A dialog box is another room, direct manipulation. Windows pollution. Example: CompuServe Navigator (email). | |
| 8. | 100 | The save problem and solutions. Main memory, disks and files. | |
| 9. | 70 | Storage and retrieval (find). A standard document format. | The idea: Files should easily be found according to their content and other properties; the file name is not enough. |
| 10. | 40 | Don't compromise software for (existing) hardware. Don't do simultaneous multiplatform development. | Read pages 113-118. Not required: Simultaneous multiplatform development (p. 119-124). |
| Part III (p. 125-192) |
|||
| 11. | 100 | Flow. Follow mental models. Direct manipulation idioms. Modeless feedback. Context. Possibilities (all the permutations) and probabilities. Show, don't tell. Edit in place. Examples: Do you want to save changes, Excel Clear, Visualizing disk usage, Print a document, Rename dialog box. | |
| 12. | 60 | Sovereign, transient, daemonic and parasitic posture. Window states, switching between applications, MDI. | Not required: Window states, MDI (p. 163-170). |
| 13. | 110 | Excise. Meta-questions and edit in place. Allow input wherever you output. Idiotic message boxes. Getting stupid. Examples: Adobe Illustrator (The artwork contains a character..., Artwork page format is different from the printer..., Print setup). | |
| 14. | 40 | Unnecessary questions. Buttcons. Remembering the previous setting, showing erroneous data. | Read pages 183-186 (Get a memory) and the two last paragraphs on page 189 (showing erroneous data). |
| Part IV (p. 193-268) |
|||
| 15. | 10 | Pen/mouse. Fine/gross motor control. Mouse buttons. Pointing, clicking and dragging. Cursor hinting. Meta-keys. | |
| 16. | 10 | Command-target, target-command. Selecting and replacing data. | |
| 17. | 10 | Manipulating gizmos. Drag & drop, cancelling drag. Repositioning, resizing, reshaping. Examples: Drawing programs. | |
| 18. | 40 | Drag & drop. Indicating drag and targets, bombardier, autoscroll, drag treshold. | |
| Part V (p. 269-368) |
|||
| 19. | 60 | History of menus: command-line, hierarchical menus. Visible hierarchical menus. Command vectors (pedagogic menus, shortcuts). Examples: Lotus 1-2-3. | |
| 20. | 80 | Excellent Cooper Attitude. Menus: File, Edit, Help. Standards. The correct menus. References to the Save problem. Cascading menus, flip-flop items. Icons in menus. System menu. | |
| 21. | 90 | Dialog boxes break flow. Modal and modeless dialog boxes. Command buttons of the dialog boxes. Toolbar. Property dialog boxes. Function dialog boxes (configuration). Bulletin dialog boxes (errors and confirmation), see part VII. Process dialog boxes. | |
| 22. | 90 | Dialog boxes (terminating commands etc.). Shortcuts. Tabs. Expanding dialogs. Cascading. Directed dialogs. A lot of examples of these. | |
| 23. | 70 | Toolbars. ToolTips and balloon help. | |
| 24. | 20 | The program's icon. About boxes. Easter eggs. | |
| Part VI (p. 367-420) |
|||
| 25. | 60 | Canned gizmos are easy to implement (usually leads to bad design), direct visual interaction is hard to implement. DLLs, VBX, OCX. Toolbar. Selection gizmos: checkboxes, buttcons, radio buttons, lists (ordering, scrolling), comboboxes. | |
| 26. | 90 | Entry gizmos, bounded input, validation. Display gizmos, scrolling problems. | |
| 27. | 100 | New gizmos. Direct manipulation: sun gizmo (drop shadow), calendar. Extraction: address, phone number. Visual: Word borders and shading, Windows Date/Time properties (time zones). Show, don't tell. | |
| Part VII (p. 421-480) |
|||
| 28. | 100 | With proper desing, all error message and confirmation boxes can be eliminated. Blocking box, sustaining box. Humans - even phlegmatic programmers - have emotions and feelings. No crisis inside a computer is worth humiliating a human. Make errors impossible. Positive feedback. Error messages are like GOTOs. An example of a good error message box. | |
| 29. | 90 | Alert boxes and confirmation boxes. Easy to create. Stops the proceedings to announce the obvious. Confirmations don't work. Do, don't ask. Make everything reversible. Data integrity. What is more important: your database or your business? Audible feedback (silence). Examples: Word Find, Confirm file delete, Word "do you want to delete style". | Not required: Audible feedback (p. 454-456). |
| 30. | 80 | Undo. Single and incremental undo (LIFO), redo. Category-specific undo. Deleted data buffer. Milestoning, freezing. | |
| Part VIII (p. 481-553) |
|||
| 31. | 50 | Beginners, perpetual intermediates, experts. Information in the head and in the world. Working set of commands. Users are very intelligent but busy. Keyboard and mouse. Standards (!). Online help. Wizards. Examples: The basic diamond in WordStar. | Most important: Standards (p. 499-501). |
| 32. | 60 | Installation, uninstallation and configuration. | |
| 33. | 90 | CPU capacity: the hurry up part is great, but the waiting has got to stop. Memory. Background activities. Starting design. Boolean algebra (natural language output). Visual richness. | |
| 34. | 100 | Scarcity thinking. Don't ask programmers to design while they code. Usability, user-centered, fish-centered. "Listen to your users, but ignore what they say." Usability testing: an indicator of problems, not a source of solutions. Programmers: (1) make guesses, (2) copy from existing programs. "What the consumer wants" is not the way to go. |
Päivitetty 27.08.2002 / Sari A. Laakso,
email: salaakso@cs.helsinki.fi
Sivun URL: http://www.cs.Helsinki.FI/~salaakso/kl-2002/nomenu/lukuohje.html
Näiden WWW-sivujen hallintajärjestelmän kehitti Tero Pekkanen