Guidance and Assistance

Guidance and Assistance

Preventing Errors

Errors can be classified as slips or mistakes. A slip is automatic behavior gone awry. Slips are usually, but not always, corrected fairly easily. Slips can be reduced through proper application of human factors in design

A mistake results from forming a wrong model or goal and then acting on it. A mistake may not be easily detected because the action may be proper for the perceived goal—it is the goal that is wrong.

Problem Management

Prevention:

o   Disable inapplicable choices.

o   Use selection instead of entry controls.

o   Use aided entry.

o   Accept common misspellings, whenever possible.

o   Before an action is performed:

§  Permit it to be reviewed.

§  Permit it to be changed or undone.

o   Provide a common action mechanism.

o   Force confirmation of destructive actions.

§  Let expert users disable this.

o   Provide an automatic and continuous Save function.

Detection:

For conversational dialogs, validate entries as close to point of entry as

possible.

o   At character level.

o   At control level.

o   When the transaction is completed or the window closed.

For high speed, head-down data entry.

o   When the transaction is completed or the window closed.

Leave window open.

Maintain the item in error on the screen.

Visually highlight the item in error.

Display an error message in a window.

o  Do not obscure item in error.

Handle errors as gracefully as possible.

The greater the error, the more dramatic should be the warning.

Use auditory signals conservatively.

Correction:

Preserve as much of the user’s work as possible.

At window-level validation, use a modeless dialog box to display an error list.

o  Highlight first error in the list.

o  Place cursor at first control with error.

o  Permit fixing one error and continuing to next error.

Always give a person something to do when an error occurs.

o  Something to enter/save/reverse.

o  A Help button.

o  Someone to call.

Provide a constructive correction message saying:

o  What problem was detected?

o  Which items are in error?

o  What corrective action is necessary?

Initiate a clarification dialog if necessary.

Providing Guidance and Assistance

Guidance in the form of the system’s hard-copy, online documentation, computer-based training, instructional or prompting messages, and system messages serves as a cognitive development tool to aid this process. So does assistance provided by another form of online documentation, the Help function.

Useful guidance and assistance answers the following questions:

oWhat is this?

oWhat does it do?

oHow do I make it do it?

oWhat is its role in the overall scheme of things?

Problems with Documentation

Poor products, however, suggest that being a native speaker of the language is not a sufficient qualification to ensure communicative success. Rather, four other factors contribute to bad design.

Organizational factors. First are organizational factors including management decisions concerning who does the writing: product developers or specialist technical authors. Another organizational factor is the frequency and nature of the contact between writers and developers.

Time scale. Second is the time scale allocated for the writing process. Successful writing also involves detailed early planning, drafting, testing, and considerable revising.

Theoretical rationale. Third, there is not yet a clear theoretical rationale about what content should be included in documentation and how this information should be presented.

Resources. Finally, Wright concludes, there are the resources. Adequate resources are needed to include people with different skills in the documentation development process.

Another problem with documentation is created by the need for translation in our shrinking world.

How Users Interact with Documentation

There are three broad stages through which a reader interacts with documentation:

Finding information is enhanced through use of contents pages and index lists.

Pictures and symbols can also be used to draw the reader’s attention to particular kinds of information.

Understanding can also be maximized through testing and revision of materials as necessary.

Instructions or Prompting

Instructional or prompting information is placed within the body of a screen. Prompting is provided to assist a person in providing what is necessary to complete a screen.

Inexperienced users find prompting a valuable aid in learning a system.

Since instructions or prompting can easily create screen noise, be cautious in placing it on a screen. Use it only if all screen usage will be casual or infrequent.

Help Facility

The most common form of online documentation is the Help system. The overall objective of a Help facility is to assist people in remembering what to do.

One potential danger of the Help facility, as one study found, is that a person’s recall of command operations is related to frequency of Help facility access; fewer Help requests were associated with better command recall.

The specific design characteristics that enhance an online Help are still being identified. Three broad areas of Help that must be addressed in creating Help are: its content, its presentation, and its access mechanisms.

The content (and structure) of an effective online Help can be specified using the GOMS (goals, operators, methods, selection rules) model

Help Facility Guidelines

Kind:

Collect data to determine what types of Help are needed.

Training:

Inform users of availability and purpose of Help.

Availability:

Provide availability throughout the dialog.

If no Help is available for a specific situation, inform the user of this and provide directions to where relevant Help may exist.

Structure:

Make them as specific as possible.

Provide a hierarchical framework.

Brief operational definitions and input rules.

Summary explanations in text.

Typical task-oriented examples.

Interaction:

Provide easy accessibility.

Leave the Help displayed until:

The user exits.

The action eliminating the need for Help is performed.

Provide instructions for exiting.

Return to original position in dialog when Help is completed.

Location:

Minimize the obscuring of screen content.

If in a window, position priorities are: right, left, above, and below.

Content:

Minimize the Help’s length.

Develop modular dialogs that can be used to describe similar and dissimilar procedural elements of the interface.

Provide step-by-step interface procedures to assist the user with specific problems.

Provide procedural demonstrations of interface procedures to aid quick learning of simple operations.

Provide information to help users select between multiple interface methods.

Provide users with an understanding of representative tasks to increase their knowledge of when to apply specific skills.

Style:

Provide easy browsing and a distinctive format.

Contents screens and indexes.

Screen headings and subheadings.

Location indicators.

Descriptive words in the margin.

Visual differentiation of screen components.

Emphasized critical information.

Use concise, familiar, action-oriented wording.

Refer to other materials, when necessary.

Never use Help to compensate for poor interface design.

Consistency:

Provide a design philosophy consistent with other parts of the system.

Title:

Place the word “Help” in all Help screen titles.

Contextual Help

Contextual Help provides information within the context of a task being performed, or about a specific object being operated upon. Common kinds of contextual Help include Help command buttons, status bar messages, and ToolTips.

Help Command Button

Description:

A command button.

Purpose:

To provide an overview of, summary assistance for, or explanatory information about the purpose or contents of a window being displayed.

Design guidelines:

Present the Help in a secondary window or dialog box.

Status Bar Message

Description:

An abbreviated, context-sensitive message related to the screen item with the

focus.

Appears in window’s status bar when the primary mouse button is pressed over an item (or keyboard focus is achieved).

Purpose:

To provide explanatory information about the object with the focus.

Use to:

Describe the use of a control, menu item, button, or toolbar.

Provide the context of activity within a window.

Present a progress indicator or other forms of feedback when the view of

a window must not be obscured.

Do not use for information or access to functions essential to basic system operations unless another form of Help is provided elsewhere in the Help system.

If extended Help is available and must be presented, place “Press F1 for Help” in bar.

Writing guidelines:

Be constructive, not simply descriptive.

Be brief, but not cryptic.

Begin with a verb in the present tense.

If a command has multiple functions, summarize them.

If a command is disabled, explain why.

ToolTip

Description:

A small pop-up window that appears adjacent to control.

Presented when the pointer remains over a control a short period of time.

Purpose:

— Use to display the name of a control when the control has no text label.

Design guidelines:

Make application-specific ToolTips consistent with system-supplied ToolTips.

Use system color setting for ToolTips above to distinguish them.

What’s This? Command

Description:

A command located on the Help drop-down menu on a primary window.

A button on the title bar of a secondary window.

A command on a pop-up menu for a specific object.

A button on a toolbar.

Purpose:

Use to provide contextual information about any screen object.

Design guidelines:

Phrase to answer the question “What is this?”

Indicate the action associated with the item.

Begin the description with a verb.

Include “why,” if helpful.

Include “how to,” if task requires multiple steps.

For command buttons, use an imperative form: “Click this to.…”

Task-Oriented Help

Description:

A primary window typically accessed through the Help Topics browser.

Includes a set of command buttons at the top; at minimum:

A button to display the Help Topics browser dialog box.

A Back button to return to the previous topic.

Buttons that provide access to other functions such as Copy or Print.

Purpose:

To describe the procedural steps for carrying out a task.

Focuses on how to do something.

Design guidelines:

Provide one procedure to complete a task, the simplest and most common.

Provide an explanation of the task’s goals and organizational structure at the

start.

Divide procedural instructions into small steps.

Present each step in the order to be executed.

Label each step.

Explicitly state information necessary to complete each step.

Provide visuals that accurately depict the procedural steps.

Accompany visuals with some form of written or spoken instructions.

Begin any spoken instructions simultaneously with or slightly after a visual is presented.

Segment any animation to focus attention on specific parts.

Segment instructions.

Delay the opportunity to perform the procedure until all the procedure’s steps have been illustrated.

Presentation guidelines:

The window should consume a minimum amount of screen space, but be large enough to present the information without scrolling.

Normally, do not exceed four steps per window.

Use a different window color to distinguish task-oriented Help windows from other windows.

Writing guidelines:

Write simply and clearly, following all previously presented guidelines.

Focus on how information, rather than what or why.

Do not include introductory, conceptual, or reference material.

Limit steps to four or fewer to avoid scrolling or multiple windows.

If a control is referred to by its label, bold the label to set it off.

Include the topic title as part of the body.

Reference Help

Description:

An online reference book.

Typically accessed through a:

Command in a Help drop-down menu.

Toolbar button.

Purpose:

To present reference Help information, either:

Reference oriented.

User guide oriented.

Design guidelines:

Provide a consistent presentation style, following all previously presented guidelines.

Include a combination of contextual Help, and task-oriented Help, as necessary.

Include text, graphics, animation, video, and audio effects, as necessary.

Make displayed toolbar buttons contextual to the topic being viewed.

Provide jumps, a button or interactive area that triggers an event when it is

selected, such as:

Moving from one topic to another.

Displaying a pop-up window.

Carrying out a command.

Visually distinguish a jump by:

Displaying it as a button.

Using a distinguishing color or font to identify it.

Changing the pointer image when it is over it.

Presentation guidelines:

Provide a nonscrolling region for long topics to keep the topic title and other key information visible.

Writing guidelines:

Write simply and clearly, following all previously presented guidelines.

Provide meaningful topic titles.

Wizards

Description:

A series of presentation pages displayed in a secondary window.

Include:

Controls to collect input.

Navigation command buttons.

Typically accessed through:

Toolbar buttons.

Icons.

Purpose:

To perform a complex series of steps.

To perform a task that requires making several critical decisions.

To enter critical data and for use when the cost of errors is high.

To perform an infrequently accomplished task.

The necessary knowledge or experience to perform a task is lacking.

Not suited to teaching how to do something.

Design guidelines:

Provide a greater number of simple screens with fewer choices, rather than a smaller number of more complex screens with too many options or too much text.

Provide screens of the exact same size.

Include on the first page:

A graphic on the left side to establish a reference point or theme.

A welcoming paragraph on the right side to explain what the wizard

does.

Include on subsequent pages:

A graphic for consistency.

Instructional text.

Controls for user input.

Maintain consistent the locations for all elements.

Make it visually clear that the graphic is not interactive.

Vary from normal size or render it as an abstract representation.

Include default values or settings for all controls when possible.

For frequently used wizards, place a check box with the text “Do not show this Welcome page again” at the bottom of the Welcome page.

Include a Finish button at the point where the task can be completed.

Do not require the user to leave a wizard to complete a task.

Make sure the design alternatives offered yield positive results.

Make certain it is obvious how to proceed when the wizard has completed its process.

Presentation guidelines:

Display the wizard window so it is immediately recognized as the primary point of input.

Present a single window at one time.

Do not advance pages automatically.

Writing guidelines:

Clearly identify the wizard’s purpose in title bar.

At the top right of the wizard window, title the Welcome page “Welcome to the Wizard Name Wizard.”

Use mixed case in headline style and no ending punctuation.

Write simply, concisely, and clearly, following all previously presented guidelines.

Use a conversational rather than instructional style.

Use words like “you” and “your.”

Start most questions with phrases like “Which option do you want . . .” or “Would you like . .

Hints or Tips

Description:

A command button labeled Hints or Tips.

Purpose:

To provide a few important contextual, but specific, items of information related to a displayed screen.

Design guidelines:

Provide guidance on only two or three important points.

Locate the button near where its guidance applies.

Write concisely and to the point.