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