error recovery ratner ch. 9 – improved error messages for web browsers undo – design issues help...
TRANSCRIPT
Error RecoveryRatner Ch. 9 – Improved Error Messages for Web Browsers
Undo – Design Issues
Help and DocumentationRatner Ch. 15 – Live Help Systems
IS U570 HCI Class notes – March 31, 2004
Error Recovery
What is an error:An event that stops the program and requires repair action
• The program rejects some data or commands entered by the user, or• The program reports its inability to carry out the user’s commands, or• The program reports some internal error state, or•?
System response to error: • direct manipulation feedback (audio tone, visual cue)• “error message” explaining the situation
Error Recovery
System response to error: • direct manipulation feedback (audio tone, visual cue)• “error message” explaining the situation
Some errors (such as typing errors or missing the intendedtarget of a click or drag action) are a normal part of human life and need to be accommodated.
Error messages only apply to errors the system can detect (most task level errors do not generate an error message)
Error messages
Error messages occur when the user’s mental model does notmatch the “manifest model” of the software exposed by theinterface. This is usually the designer’s fault, not the user’s!
Error messages are important because:Errors are traumatic events for usersBad messages make things worsePeople have a tendency to remember what happens when things go wrong
Conclusion: a bad experience with error recovery can leave a lasting negative impression, in spite of many positive aspects of an interaction.
Error messages – desired attributes
Error messages should be:Specific and constructive (information level)Polite and positive in tone (information level)
•user-centered phrasingUnderstandable and readable
•consistent and convenient placement (visual level)•consistent appearance (visual level)•consistent wording/grammatical style (visual level)
Error message should be subjected to empirical testing for effectiveness and user satisfaction.
Error Message Examples
Disk full.Command failed.
Error in DRESS SIZE field
Illegal input!!
Fatal, Invalid, Killed, Aborted, Terminated, Abandoned
Disk full. Use “Save As” command to save to another disk.
DRESS SIZE is out of range:enter 4 to 16 (no leading 0’s).
Unrecognized command
Program has halted.
Designing UNDO functionality
Review definition of DM interface:•Continuous representation of objects and actions using visual metaphors idioms•Physical actions instead of typed commands•Rapid, incremental, reversible operations whose effect is visible immediately
DM Promotes:•feeling of mastery – user in control•easy of learning and remembering•desire to explore more powerful features
Designing UNDO functionality (cont.)
Purpose of UNDO:•Supports recovery from “normal” errors•Supports error recovery at task level•Supports experimentation by trying a feature to see what happens
UNDO is ignored in software engineering/CS•It does not add functionality•It is a pain to implement, and involves putting inelegant code into virtually every part of a system
Designing UNDO functionality (cont.)
UNDO involves: a procedure + optional data Dataless actions: change font, move paragraph Dataful actions: cut, paste, draw, type
Single UNDO: reverses the effects of one (most recent) action it’s clear, simple, easy to remember
Multiple UNDO is repeatable – it can reverse more than one previous action in reverse temporal order
Most UNDO facilities today are multiple
Designing UNDO functionality (cont.)
Some UNDO facilities explain what will be reversed, most do not. (Blind UNDO)
Ex: UNDOUNDO typingUNDO typing “design”
Designing UNDO functionality (cont.)
Problems in designing multiple UNDO:•granularity of defining an action (character v. word)•Strict LIFO model (what if interlaced functions are not all bad?)
•Ex: delete some text (A), edit some other text (B)– user wants to restore A but not undo the editing of B.
•REDO – in single undo system, UNDO acts like a toggle – in multiple undo system, can usually redo the most recent “undone” action
Would we want a pointer-based UNDO? (Ex: cursor/backspace) A category-specific UNDO?
Documentation and Help
Traditional paper documents:Getting started (installation plus a test example)TutorialAdvanced Tutorial/User’s GuideReference ManualQuick Reference Card
Documentation and Help
New approachesindexed on-line helpLive Guided tours and TutorialsFAQ files – Frequently Asked QuestionsContext-sensitive help
promptsqueries
Wizards (setup wizards for installation)Plus: on-line copies of paper documents
Design choice: user-activated or system-activated help
On-line Help
Pro’s:•It’s there whenever you need it.•Can be updated at low cost•Enhanced by string search, indexes, TOC, bookmarks,
hypertext links•Use of color, sound, animation
Con’s:•Readability may be less than printed manuals•Presents another user interface to master•Blocks user’s view of workspace
Creating Good Documentation - Appearance & Style
• Develop documentation guidelines for consistent organization, style, and appearance
• Use simple writing style, even if users are well-educated (users are engaged in many tasks at once)
• Use white space and text-organizing conventions to avoid large text blocks. (headings/subheadings; bullet lists, short paragraphs
Creating Good Documentation - Organization
Organizing the material:• State the educational objectives of each section• Introduce concepts in a logical order
•of increasing difficulty• After each “chunk” of material (7 + or - 2 concepts):
•Provide a “walkthrough” example showing how the concepts are used.
• Avoid forward references
Creating Good Documentation - Summary
Good:•Progressive approach•Task-oriented examples•Readable explanations
Bad:•Complete specification presented in one block•Abstract formal notations•Terse technical prose
Tutorial Material
• Should describe capabilities in a task-oriented way.
• Should describe capabilities in an action-oriented way.
•Use OAI model to structure explanations•Start by explaining the task model objects, from the highest level down to “atomic” elements.•Then explain the task model actions, from user’s goals down to specific action steps.•Once user understands the task concepts and vocabulary, then show the interface mechanisms/ syntax needed to accomplish tasks•Finally, describe shortcuts
Reading from Paper v. Displays
Studies through 1980’s showed performance disadvantages in reading from display screens -- about 30% slower task times, slightly lower accuracy.
Readability issues:•screen size (frequent paging)•placement (looking down is better, rigid posture)•contrast, flicker, resolution, curved display surface fonts, layout, formatting
Other issues: health concerns, fatigue, and stress
But: Later studies showed no difference with better quality display.
Context-sensitive on-line Help
•For part of program that is active•For a selected object:
•using function key (F1)•Balloon help
•Prompts for fill-in fields
FAQsNetworked human help available
Help deskUser discussion groups/Newsgroups
New approaches for on-line help
Live Help System
Elements:•Knowledge base of FAQ items
•Continuously updated•Chat interface to interact with human assistants
•Feedback on availability•Feedback on assistant “state”•Dialog history•Text entry area
•User profile
Usability Testing of Live Help System
Methodology: field study using ElfwoodStudy questions:
•Impact on user attitudes, especially trust•Quality of support•Quality of assistant work situation
Assistants and users volunteeredEvaluation by questionnaires (2 for users, 1 for assistants)
Design implications of the study for Live Help System
1. Emphasize the availability of live help, since users don’t expect it.
2. Make initiation process very easy3. Do not use platform-dependent software (Java applet)4. Make availability hours clear for getting human help 5. Provide queuing status6. Provide call-back option7. Use visual and audio alert when help becomes available8. Consider email or voice options