CS 160: Lecture 21
Review: Information Design
- Give some typical information-seeking tasks.
- There were two sets of (object, action) pairs, what were they?
Design for Errors
- Some favorite error messages:
- 404 not found
- Fatal error 312: aborting
- Syntax error near line 1025
- Internal compiler error
- Segmentation fault: core dumped
-
- What do these messages communicate?
- What is the solution to each?
Naïve users
- Fatal error 312:
- User messed up and the program may kill someone
- Solution: log off and pretend nothing happened.
- 404 not found
- The computer misplaced something (the “404”?).
- Solution: Maybe it will find it if you try later…
- Segmentation Fault: core dumped
- Something bad happened
- Solution: someone will probably have to clean out the “core” stuff that was dumped inside the computer.
More sophisticated users
- Segmentation fault: core dumped
- This lazy programmer probably slept through all their programming classes and didn’t learn about array bounds checking, invariants or memory management.
- Solution: Move them to the user support hotline
More sophisticated users
- 404 + the other messages
- Computer programmers are unable to construct complete sentences.
- Computer programmers are unable to sustain normal relationships, and vent frustration on normal people through hostile error messages.
- Programmers are unable to accept their own faults, so blame them on someone else.
- Programmers think anyone cares that their silly program is crashing.
More sophisticated users
- Solution for programmers:
- Test out error messages in person on your boss.
- E.g. walk into office, say “segmentation fault: core dumped”, deposit printout of memory on their desk, and walk out.
-
- If it doesn’t work in person, don’t put it into a program
Human error recovery
- People make mistakes in communication all the time, and are adept at repairing them.
- Repair need not involve assignment of blame.
- E.g. “I’m sorry, I didn’t understand. Can you rephrase?”
- Tells the speaker you heard what they said, but were unable to interpret it. They should repeat, but express it differently.
- There is no assertion that what they said was ungrammatical or incorrect, and you accept some blame by default.
Humane error recovery
- In human communication, an error is the beginning of a process of repair. It is “normal” to make errors.
- In human-machine interaction, errors normally lead to the end of the current task. Errors are treated as “abnormal”.
- In other words, user interfaces usually try to escape from the repair process, leaving the user stranded.
Types of errors
- Mistakes
- User intended to do what they did, and it led to an error. User would probably do the same thing again.
- Slips
- User did not mean to do what they did. They can recover by doing it differently again.
- Slips are not just for beginners. Experts often make them because they devote less conscious attention to the task.
Minimizing Error
- System errors: Program defensively (assert, bounds check etc)
- User errors:
- Use Intuitive command names.
- Include short explanations as “tool tips”.
- Put longer explanations in help system.
- Recognition over recall
- Easier to select a file icon from a folder than to remember and type in the filename.
- Use appropriate representations
Typical Errors
- From Norman’s 1983 survey:
- Mode errors:
- User forgets what mode they’re in, and does the command appropriate for another mode.
- Digital watches, VCRs etc.
- Common where there arent enough command keys for all the operations
- You can still explain the mode by giving the user feedback on what keys do in the display.
Typical Errors
- Description error:
- The action is insufficiently specified by the user.
- User may not know all the command line switches, or all the installation options for a program.
- Solution: Warn the user that the command is ambiguous, or “unusual”. Provide help about options in several standard ways.
Typical Errors
- Capture error:
- Command sequences overlap, and one is more common.
- User reflexively does the common one when trying to do the unusual one.
-
- E.g. try typing “soliton” very fast.
Detecting Errors
- The earlier the better:
- Check for consistency whenever possible (“asserts” for user input).
- If there’s a high risk of error, check for unusual input, or for common slips (spelling correction).
-
- E.g. google’s “did you mean XX?” response
System Response
- Stop the user from continuing the way they were going (possibly compounding the error).
- Take “safe” recovery actions - e.g. auto-save the state with a unique name.
- Begin the recovery process.
System Response
Explanations
- The first part of the recovery process is to explain what appears to be wrong.
- Remember the user is only supposed to have a functional model of what’s going on. Try to give an explanation at that level.
- People understand basic resources like filespace, memory etc.
- “I’m afraid the program has an internal fault in the code that <<reads and writes files>>, which was called when trying to <<save your user preferences>>. We regret the inconvenience, and are trying to recover…”
Recovery
- The system should always give the user a reasonable amount of information about the problem.
- Better to err on the side of too much information.
- Some problems are amenable to automatic repair: retry, use redundant information, backup data etc…
- DWIM (Do What I mean) was an editor that attempted to correct common user errors. You need an “undo” key to use this approach.
Recovery
- Run a “diagnostic wizard” for common or unreliable subsystems (e.g. the network).
- These can interact with the user to get extra information needed to fix the problem.
Research Approaches
- Intentional interfaces: build models of user intention from their actions.
- Assumes that people have clear goals that the system can understand.
- Can get confused if people multi-task or do sub-optimal things.
Research Approaches
- Accountable systems: The system maintains a user-oriented model of internal behavior, somewhere between a structural and a functional model.
- If an error occurs, this “account” can give a sensible explanation, and often recovery suggestions.