Re: Any suggestion about Wizard's making?

[bcsmit - Bill Smith <bcsmit -at- ACXIOM -dot- COM>]

Alessandra Bottoni asked:
>Does anybody have any experience about creating Wizards?

Last November, I posted a request to the list for help with guidelines
for creating wizards. Several subscribers replied. (Repeated thanks to
you.)However, how-to information offered was limited. Following that
post, I researched several books/publications and collected the
following guidelines for developing wizards. These are general and don't
deal with authoring tools.

Hope they are useful.

Bill Smith
Acxiom Corporation
Conway, AR  

**************************************
Much of the information in the following guidelines is quoted or
paraphrased from The Windows Interface Guidelines for Software Design,
copyright 1995, published by Microsoft Press.

Creating Wizards
What is a wizard?

A wizard is a special form of assistance that automates a difficult task
via a dialog with the user. Wizards help users complete complex or
infrequent tasks that don't promote learning retention. Simply put, a
wizard asks a series of task-specific questions and then completes the
task for the user.

Generally, because they are goal-oriented, not instructive, and they
operate on real data, wizards should not be used to teach someone how to
perform a task. Instead, use tutorials to teach tasks and procedures.
Effective wizards are designed to hide many of the steps and complexity
of the given task.

Designing Wizards

A wizard is a series of pages, displayed in a secondary window, that
help the user to complete a task. The pages include custom controls to
gather task input from the user. As an option, you can also design
wizards as a series of secondary windows through which the user
navigates. However, secondary windows are not recommended because they
can result in increased modality and screen clutter.

Include the following navigation/command buttons at the bottom of the
wizard window.

Command Action	
< Back  Returns to the previous page. (Remove or d      isable the button on
the first page.)	
Next >  Moves to the next page in the sequence,         maintaining whatever
settings the user provides      n the previous page.	
Finish  Applies user-supplied or default settings from all      pages and
completes the task.	
Cancel  Discards any user-supplied settings, terminates         the process, and
closes the wizard window.	

Use the title bar of the wizard window to clearly identify the purpose
of the wizard. Because wizards are secondary windows, do not show them
in the task bar. You can include a What's This? Help button in the
wizard title bar, if needed.

On the first page of the wizard, include a graphic in the left-side
panel. The purpose of the graphic is to establish a reference point or
subject theme for the wizard.

In the upper-right portion of the wizard window, provide a short
paragraph that welcomes the user to the wizard and explains (briefly)
what it does. You can also include controls for entering or editing user
input, if space is sufficient. Avoid offering too many choices that can
be difficult to understand without context.

Include default values or settings for all controls, where possible.

On subsequent pages, continue the graphic for continuity. If the space
is needed, you can use the full width of the window for instructions or
controls for user input. If using graphics, choose images that help
illustrate the process or support the task flow.

You can include the Finish button at any point that the wizard can
complete the task. For example, with reasonable defaults, you could
include the Finish button on the first page.

Place the Finish button to the right of and adjacent to the Next button.
This enables the user to step through the entire wizard or only the
page/s on which they want to provide input. If you will require the user
to step through every page of the wizard, replace the Next button with
the Finish button only on the last page. Also, on the last page, tell
the user that the wizard is ready to complete the task and instruct them
to click Finish.

Design wizard pages to be easy to understand. Ideally, wizard components
(pages and instructions) should only require cursory reading for users
to understand items that they must answer.

When designing a wizard, it is better to have more simple pages with
fewer options, than to have a smaller number of complex pages with many
(complicated) options.

General Guidelines

*       Minimize the number of pages that require display of a secondary
window. Novice users can be confused by the complexity of secondary
windows.
*       Avoid a design that requires users to leave the wizard to complete a
task. Design so that users can complete all task details from within the
wizard.
*       Make it clear, visually, that thematic (decorative) graphical elements
in the interface are not interactive. One way to do this is through use
of an abstract graphical image.
*       Avoid advancing pages automatically. Users should control the time
needed to read and answer page options before pages advance. Wherever
possible, enable users to control the process interaction.
*       Make the wizard window clearly recognizable as the primary point of
input. For example, if you access a wizard from a control in a secondary
window, position the wizard window so that it partially obscures the
secondary interface window.
*       Provide clues as to how the user will proceed when the automated task
is completed. One way to do this is by adding such information to the
last page of the wizard.

Writing Wizard Text and Instructions

When writing text for a wizard, use a conversational style and speak
directly to the user.

*       Use words like "you" and "your" to make the dialog direct.
*       Phrase questions to imply user choices, such as "Which option do you
want?" or "Would you like?" Users respond more favorably when they are
coached on a process versus directed. For example, "Which layout do you
want?" works better than "Choose a layout."
*       Use contractions and short, common words. Avoid narrowly used jargon.
*       Avoid technical terminology that won't be understood by novice users.
*       Use short sentences and instructions as much as possible. For example,
the question "Which style do you want for the newsletter?" can be
written simply as "Which style do you want?"
*       Write clearly and simply but avoid sounding condescending.

Other Wizard Design Considerations

Don't use wizards to compensate for an ineffective product design. An
effectively-designed user interface should not need heavy support from
task wizards. 

Consider and design for how the wizard will be selected.

*       From the Tools menu?
*       From the Help menu?
*       From a button in a dialog or window?
*       From a toolbar button?
*       From an icon?

Time-Consuming Tasks

When automating a task that requires a perceptible length of time to run
after the user finishes the wizard, the application should follow the
wizard with a process dialog box to inform the user that it will be
busy. The process dialog box that follows this wizard should satisfy
these actions:
*       Make it clear that a time-consuming process is happening.
*       Make it clear that things are completely normal.
*       Make it clear how much time is needed to finish the task (progress).
*       Provide a way for the user to cancel the operation.
**************************************