Page History

Goal

A multi-step process requires filling out several sub forms in sub steps in order to complete a complex task. The steps follow and actually depend on each other.

It should be clear at any time at which step of the process the user isI am. It should also be possible to return to a previous step and change data entered there, then continue forward again to complete the task.

Concept

We use a wizard-style sequence of forms to model a multi-step process. Such an implementation is well established. It is also clear, if each steps focuses on one particular, conceptually simply action.

Do not use such a form, if your form actually does not contain multiple, interdependent steps. Use a single-page complex form in such a case, or introduce tabs to break up your form into multiple parts. Tabs allow to change between any element more freely.

Multiple steps

A series of dots visualizes the total number of steps required to complete the process, with a highlighted dot showing the user, at which step in the process he currently is. Note that the steps of a multi-step process follow each other. This is not the same as breaking up a complex form into individual sub forms, as the steps usually linearily depend on each other.

Description of desired behavior

...

dots can't be clicked to directly jump to a particular step.

The "next" button allows to move on to the next step. It may be temporarily disabled, if the user is required to fill out values in the form of the current step first. Likewise, a "previous" button allows to go back in the process one step a time. In general, both buttons should simply be labelled "next" and "previous" to guarantee they are recognized easily. Only in the optional "review" step, the "previous" button should actually be labelled such that it is clear that the user returns into the process by clicking it.

Each step also may also provide a help button offering additional information about the values a step collects. Try to make it clear what you expect from the user by providing a good, initial description and clear labels in the form. If you'd like to provide an overall explanation of a step or some additional details on some or all of the fields, install an additional help page through the help button. This page simply takes over the space of the dialog box to provide its text.

Validation messages

Please refer to concept for showing validation messages in forms.

Optional steps

Optional steps extend a multi-step process. We do not define how to enter such a step as it makes sense to pick the best solution (a button, a link or even an icon) according to context. If the user chooses to enter an optional step:

• the series of dots is expanded by one or more dot representing the optional step(s)
• the buttons available in the optional step are inherited from the parent step, if it makes sense
• the optional step is then treated just as any other step in the process. It is not removed again, nor does it have to be entered again using the original button, link or icon. It has merely become part of the regular multi-step process. Thus, the next/previous buttons are adjusted to also work with this additional step.

Review step

If the data a user has to enter is complex, add a review step at the end of your process. It should clearly show all data the user has entered in every step and contain one button for confirmation as well as one well-labelled button to reenter the process again.

Growing and shrinking dialogs

As forms may have different heights, a dialog box has to adjust its height to accommodate them. It is undesirable to have scrollbars in a form - break up the form into different parts using tabs or a single-page complex form.

Dialogs shall immediately grow to fit the height of the form of the current step. In order to avoid too much jiggle in the user interface, however, a form only decreases in height, if the form it has to accommodate is smaller than two thirds its current height. If a dialog chooses to not reduce its height, the superfluous space is added between the last field of a form and any possibly showing notification message or else above the bottom edge of the form frame. E.g. in case of step 3 in the mockup above, this space would be added between the "[UX:change]" link and the edge of the form frame. Any shown UX:notification would be shown after the space, but still before the edge.

Aborting a process

If a multi-step process is shown using a dialog - either an overlay dialog or a dialog in a separate window -, the way to stop and exit the process is to click the "close window" button in the upper right corner. If a form offers a clear choice, however, to confirm the data entered so far, such as is the case in the UX:review step, an explicit "cancel" button next to the confirmation button must be present.

Additional notes

If presented in a dialog, the form is embedded in a colored frame, which contains all controls for navigation between steps. It also contains any buttons for submitting the form, cancel submission in a review step or closing a help screen. The form box should focus on content, the frame on control. If the form is presented on a page directly, leave out the frame, but still ensure that the form itself resides in a box and the controls are arranged around it using a layout much like in case of the dialog.