Wizard

Problem Summary: Specify a large amount of information
Pattern Key: WIZARD
Example:

Use When:
  1. The information the customer must provide is too intimidating or complicated to request all of it from a single page.
    • The Wizard is an especially good choice if we want to entice the customer to do or try something.
  2. Different information is needed according to early choices the customer makes.  The early choices can determine which wizard pages are shown later.
    • Also consider using a single page and having one choice at the top of the page determine what is displayed at the bottom.
  3. The requested information can be broken up into pages that are suitable to be worked with one at a time, so the customer rarely needs to go back to a previous page.
  4. The customer is not in a blazing hurry, and it's unlikely that the same customer will have to do it over and over.
    • Note:  Wizards are friendly, allowing the customer to focus on one part of the task at a time, but they also require more interactions and server trips.  Some sites are moving to a smaller number of larger pages, or even a single page, for placing orders.

Normally, wizards are used for initial creation of objects, and revisions made later are done another way, such as tabbed panels or a large page.  However, this is not required, and wizards may be used for revisions as well, especially if there are not too many steps or changes are rare.

Solution: Use a wizard, as shown above.
  1. All four buttons are always present, but the ones that are not applicable are disabled.
    Exception:  The Cancel button is not required, but it can be useful if there are a lot of steps.
  2. The Cancel button cancels the wizard and returns to the page that invoked the wizard, the one from which the first step was invoked.  If significant information will be lost, confirmation is required.
    Example:  "Are you sure you want to cancel this registration and discard your work?"
    Note:  Normally, leaving the wizard causes all entered data to be lost, but this is not required.
    See also:  Confirmation of Cancel by Navigating Away
  3. The progress bar at the top is not required, but is often very useful.  In cases where the number of steps in wizard changes according to the customer's choices, progress information may not be useful.
  4. Clicking an item on the progress bar takes the customer to that page, when practical.  Many wizards will let you jump back, but not always jump forward.
  5. Clicking Previous and Next does not cause information to be lost.  Whenever you return to a page, the content of that page is as you left it, provided you have not left the wizard.

Note:  Be careful about using a Wizard with Tabbed Panels inside of it.  Customers may think that the Previous and Next buttons apply to the tabs instead of the Wizard steps.  Consider making each tab a step in the wizard, or using a Collapsible Panel inside the wizard, instead of a Tabbed Panel.

Rationale: NA
Accessibility: See Accessibility
Internationalization: See Internationalization
Supporting Examples: None
Where Used: NA
Coding: NA

Items of Note: None

Put to Use

Status: Review

Used in Conjunction with: None

Related Patterns: Sequence Navigation

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

About the cancel button

If the window that the wizard (or really any screen) appears in is not a pop-up, the cancel button should only be present if it actually does something, IMO. I don't think the fucntion of taking someone back to where they started warrants a cancel button. In general I think we want as few buttons as possible.

In the case of a wizard, however, the cancel button might have real functionality depending on what is happening. For example in the registration wizard shown here, the cancel button should cancel the registration - i.e., remove any entries made on prior wizard pages and even on the first page it should give the user the feeling that they have removed any data associated with registering for this event. To that end, it probably needs a confirmation message like "Are you sure you want to cancel this registration and lose all of your work? If so, click yes. If not, you may leave this page without clicking cancel and this information will be here when you come back."

This latter bit may be getting too detailed for a Wizard navigation pattern, but it is meant to illustrate the point.

Really?

About the message "Are you sure you want to cancel this registration and lose all of your work? If so, click yes. If not, you may leave this page without clicking cancel and this information will be here when you come back."

Will it always be there when they come back? Doesn't it depend on what they do? For example, what if they close the browser or perform another registration?

Obviously you'd only show this if that was the case

Typically in a multi-page thing though, you save each page as you go on to the next. So, in a 5 step registry wizard, we'd normally save steps 1-3 by the time you got to 4. And, if you abandoned, it would pick up where you left off. Kind of like saving your cart in the store.

It may not always be the case, but it is pretty common

Missing patterns

Following along the lines of the wizard pattern, as we discussed, we need patterns for:

- Top tabs
- The replacement for side tabs

And maybe misplaced in a discussion on navigation:
- Using tabs to filter - E.g., if you have a list of of events, maybe you make a tab for each type to quickly filter the list by type.

Top tabs are here

Not related to this pattern, but while I am thinking about it

I hate to see a form like the one above where all fields are the same length. I think it is difficult to distinguish the fields from one another and it is just plain wrong in this case (i.e., they should not be the same length for this data). It also looks like no effort was put into making the form.

First Name, Last Name, and Address should be a good bit longer than phone number. City should be longer than phone but shorter than Address. Zip code should say Zip/Postal Code and should be shorter than all of the above.

I bring this up for two reasons:

  1. We probably need a pattern to really highlight this. It is prevelent in iMIS 15 today and drives me crazy.
  2. The pattern examples have to look right because the picture is what people remember. Every example has to properly implement all of the patterns that it uses or people may visually remember the bad one.

Good point

Will fix.