Java TM Look and Feel Design Guidelines: Advanced Topics > Part II: Special Topics > 7: Wizards > Designing Wizard Behavior   Previous Next Contents/Index/Search


 

Designing Wizard Behavior

Just as important as a wizard's layout is its overall behavior: Is the wizard easy to start? Does it enable users to complete their entire task? Can it be moved and resized? Does it provide enough feedback? This section discusses each of these topics.

Delivering and Starting Wizards

Some wizards are embedded in applications; others can be started directly. But whether the wizard is embedded or standalone, users must be able to find it and start it.

Most embedded wizards can be easily found and started, because they are started from menus or other obvious places within an application. Standalone wizards can be much harder to find and start--for example, wizards that install software from a CD-ROM or other removable storage medium.

On a CD-ROM, an installation wizard should be in an easy-to-find location. To simplify starting an installation wizard, consider creating an autoplay screen, which opens automatically when a user inserts the CD-ROM containing the wizard.

An autoplay screen lists the tasks that users can choose from the CD-ROM. If the only task is to install your software, the autoplay screen starts the first page of your installation wizard. If your users can use the CD-ROM for two or more tasks--such as installing software or viewing a "Read Me" file--precede your wizard's first page with a screen from which a user can choose from among the available tasks.

 Place an installation wizard at the highest level of a CD-ROM. If the application that the wizard will install is on a hard disk, place the wizard in the top-level directory for the application.

 Create an autoplay screen for a standalone wizard.

Supporting a User's Entire Task

When users begin a task in a wizard, they expect to complete the entire task before leaving the wizard. Make sure that your wizard enables users to perform their entire task without exiting or otherwise leaving the wizard. If the task requires temporarily closing the wizard--for example, to restart a user's computer--your wizard should reopen automatically at the correct wizard page.

If supporting a user's entire task is not possible, your wizard should tell the user which actions need to be performed outside the wizard. For example, if the user must temporarily exit the wizard to complete steps off line, the wizard should enable the user to print a list of those steps--including restarting the wizard.

When the user restarts the wizard, it should:

  • Check that the user's computer system is in the required state
  • Help the user correct any errors made during the offline steps

If your wizard cannot support a user's entire task, conduct a usability study. In the study, verify that all the participants can complete the entire task by using a combination of the wizard and steps performed outside the wizard.

Your wizard should enable users to perform follow-up actions that relate to the main task. For example, users often want to save information about the parameter values used in the wizard. Consider providing a way for users to print your wizard's confirmation page or to save its contents to a file. Also consider creating log files in a permanent location, so that users can have a record of the wizard's actions.

 Provide wizard support for the user's entire task.

 If technical constraints prevent your wizard from supporting a user's entire task, conduct a usability study to demonstrate that all participants can complete the task successfully.

Positioning and Sizing Wizards

Among the characteristics that affect a wizard's usability and visual appeal are:

  • The screen position and size at which the wizard opens (and reopens)
  • The wizard's appearance after resizing

Wizards are windows, so general guidelines for positioning them are discussed in "Setting the State of Windows and Objects" on page 33. This section supplements that discussion with information specifically about wizards.

A wizard must set its page size when opening for the first time. Typically, a wizard should be 400 pixels tall and 660 pixels wide. However, a wizard's size is determined by the layout manager used by the wizard's executable code.

If a user resizes a wizard, the resulting change in layout depends mostly on the wizard's layout manager. You need to specify how resizing should affect the contents of the wizard's left pane. The guidelines for resizing the left pane vary depending on whether it currently displays a list of steps, help text, or a graphic. (For more information, see Designing the Left Pane.)

 Open standalone wizards in the center of the screen on a user's principal video monitor.

 Open embedded wizards over their parent window--the primary window from which users invoke the wizard. (Position the wizard according to the guidelines in "Positioning Secondary Windows" on page 33 .)

 If an embedded wizard's parent window contains information that must be visible while the wizard is displayed, ensure that the wizard leaves that information visible.

 When reopening a wizard after a user has closed it, display the wizard at the position it occupied when the user last closed it.

 If a wizard is resized horizontally, allocate any additional space to the left and right panes proportionally, unless the left pane contains a graphic. (For guidelines on resizing graphics in the left pane, see Left Pane With a Graphic.)

Checking Wizard Dependencies and User Input

A well-designed wizard does not start operations that it cannot finish. Before your wizard starts its task, it should verify that a user's computer system and software configuration meet all the wizard's requirements and dependencies. For example, the wizard should verify that the user's system has:

  • Adequate disk space
  • A compatible version of the operating system
  • All required software patches
  • All required Java technology classes, in the correct version

If possible, perform dependency checking at each wizard page, before the user moves to the next page. Some dependency checks can require information that the wizard collects across several pages. Perform such dependency checks as soon as possible and before the user moves to the wizard's confirmation page.

Before moving ahead from a page, your wizard should verify the user's input and alert the user to an any invalid values. To alert the user, your wizard should display an alert box. When the user closes the alert box, place keyboard focus on the first invalid item, and select that item automatically, if possible. Do not delete the user's input.

A validity check can take a long time. To let the user continue working, your wizard can delay displaying the results of the validity check until the check is complete. However, if the check finds invalid values, your wizard will have to recover from any errors caused by the user's invalid input.

 Provide dependency checking in your wizard to ensure that the wizard does not fail because of unsatisfied dependencies.

 In wizards, perform each dependency check as soon as possible after a user enters the relevant data. If a dependency does not involve user input, check it when the wizard first opens.

 Check all user input for errors before moving to a wizard's next page, unless checking would take an unreasonably long time. In that case, check for errors just before a user reaches the wizard's confirmation page.

Providing Operational Feedback in Wizards

Users interact more easily with a wizard if it keeps them informed about its state. Your wizard should display a progress page when performing a time-consuming operation. Figure 84 shows a typical progress page. (For a description of progress pages, see Progress Pages. For general information about appropriate response times, see Chapter 6 .)

Figure 84   Progress Page With a Progress Bar

 

In a progress page, the right pane displays a underlined subtitle, formatted as on all other pages. Below the subtitle is a progress animation, which can be a progress bar (as in Figure 84) or a progress checklist (as in Figure 85).

Figure 85   Progress Page With a Progress Checklist

 

You can display a long progress checklist in a scrolling pane. A progress bar or progress checklist is displayed in the right pane, not in a separate window. (For general information about using progress bars and progress checklists, see "Providing Operational Feedback" on page 105.)

Applications should let users terminate an operation in progress. To let users terminate such an operation in your wizard, provide a Stop button on the progress page. Figure 84 and Figure 85 show a Stop button used with a progress bar and with a checklist. In both figures:

  • The Stop button is right justified.
  • The mnemonic for the Stop button is "S."
  • The navigation buttons are dimmed (because the user has not clicked the Stop button).

Not all progress pages should have a Stop button. Before adding a Stop button to a progress page, consider whether terminating the operation could leave a user's computer system in an inconsistent state. If it could, decide whether your wizard can undo the completed portion of the operation.

Provide a Stop button only if your wizard can either:

  • Undo the completed portion of operation
  • Leave the user's computer system in a state less problematic than the one that would result from completing an incorrect action

Before stopping an operation, display an alert box explaining how stopping the operation will affect the task or the system--unless the system will be returned to its pre-wizard state. In the alert box, allow the user to continue the task or cancel the wizard.

 If a wizard performs an operation that might last longer than 10 seconds, show progress feedback in the right pane of the wizard.

 If users can safely stop an operation in a wizard, provide a Stop button. Follow these rules:

  • Place the Stop button directly below the progress bar or checklist on the progress page for the operation. Alternatively, place the Stop button directly to the right of the progress bar or checklist.
  • Align the Stop button with the right edge of the page's content.
  • Use "S" as the Stop button's mnemonic.

 If a user stops an operation, return the system to the state it was in when the operation started, or display an alert box that explains the state of the system when the operation stopped. The alert box must let the user choose to stop or continue the operation.

 On a progress page, make the navigation buttons of the bottom pane unavailable when an action is in progress. Unless the progress page is the wizard's final page, make the Next button available when the action is complete. Ensure that, after the action is complete, the Cancel button remains unavailable.

Alerting Users in Wizards

Ideally, a wizard's panes display all the text needed for using the wizard. You might need to alert users by displaying an additional text message--typically, about a potential or actual problem. You can alert users by displaying an alert box.

Display alert boxes only for errors that you cannot prevent. You can sometimes prevent errors by providing better instructions in the preceding wizard pages. Displaying alert box is required in the following situations:

  • After the wizard detects an input error
  • When a user is about to lose input data by canceling the wizard
    with either:
  • The window's close control
  • The wizard's Cancel button

Figure 86 shows an alert box for confirming a close-window operation.

Figure 86    Alert Box for Closing or Canceling Wizard

 

 Display a wizard's status information within the wizard's right pane. Display status information in an alert box only if you cannot display the information in the right pane.

 In wizards, display an alert box if a user provides input values but then tries to cancel the wizard by clicking its Cancel button or the close control in the wizard's title bar. In the alert box, display the message shown in Figure 86. If the user clicked the Cancel button, use the word "Cancel" instead of "Window Close" in the window title and message title.

 Ensure that a wizard warns users before it starts any operation that a user cannot stop. Typically, the warning is part of the additional instructions on the wizard page from which the user could request the operation.


Java Look and Feel Design Guidelines: Advanced Topics.
Copyright 2001. Sun Microsystems, Inc. All Rights Reserved.
Previous Next Contents/Index/Search
Left Curve
Java SDKs and Tools
Right Curve
Left Curve
Java Resources
Right Curve
JavaOne Banner
Java 8 banner (182)