|Java TM Look and Feel Design Guidelines: Advanced Topics > Part II: Special Topics > 7: Wizards > 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.
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.
Create an autoplay screen for a standalone wizard.
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.
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.
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.
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 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 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.)
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:
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.
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.
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:
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.
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 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.
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:
Figure 86 shows an alert box for confirming a close-window operation.Figure 86 Alert Box for Closing or Canceling Wizard
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.