Every day we see Wizards for performing all sorts of tasks. To reduce confusion (and tech support questions) the interface presented to the user is necessarily kept simple. It is this simplicity that puts us at ease with using Wizards. While there are many visual designs for them, there is a common set of elements and behaviors that are almost always present:

• HeaderA horizontal banner usually found across the top that remains constant, holding branding elements as well as wording that indicates the Wizard's purpose.
• NavA horizontal bar usually found at the bottom of the Wizard, containing Previous, Next, Finish, Cancel, and Help buttons. At different times any of these buttons may be displayed or disabled, but their spatial layout is simple and helps the user move quickly though the process.
• StepsA vertical Overview bar containing buttons or labels showing the steps of the process and the user's progress so far. The buttons allow the user to return directly to a previously completed step as well as letting them see the steps yet to be completed.
• Pages A Content area usually displayed to the right of the Steps Overview, above the Navigation Bar and below the Header Area, displays the Pages for each step of the process. Pages  may be informational only or they may collect data from the user.

There may be alternate and mutually-exclusive 'States' to a Wizard. Most of the user interface elements are present when the Wizard is in what we might term the 'Form' state, where it is presenting or collecting information. Common 'States' found in most Wizards are:

• FormUsed for presenting or collecting information, usually the Navigation, Steps Overview, and Content areas are present.


• WaitDisplayed while the Wizard is communicating with a database, or remote service, working at length with the filesystem, or is compute-bound for more than a few seconds. The navigational elements, not relevant during this time, are typically replaced by an image, a  message, a progress bar, and a Cancel button.


• ErrorUsed to communicate an Error to the user, and their options at this juncture. Replacing the navigatonal controls, at minimum we usually see a message and a Cancel button if the user is allowed to return to the Form state and try again.


• DoneDisplayed when the function of the Wizard is complete. Generally displays a message about the success of the submission, and perhaps one or more links to logical next destinations.

In creating Pinball, several assumptions about the nature of and scope of Wizards had to be made in order to arrive at something that would be recognizable and familiar to users while supporting a large number of the tasks businesses often want a Wizard to perform.

The framework does all the 'heavy lifting' of controlling the users navigation through the pages, submitting the data, handling service success or fault. To create a Pinball Wizard, you need to supply:

• DesignA CSS stylesheet controls the look of nearly aspect of the Wizard's appearance. Also, you add any images to be used throughout the Wizard.


• ConfigCreate an instance of a framework configuration class and populate it with the values that will control more aspects of the Wizard's look and feel.


• PagesCreate subclasses of a framework class that represent each step of your Wizard process.


• ModelA single class that is used to collect the data for the Wizard. It is shared by all the pages, which typically populate it with the information they gather.


• ServiceA  web based Wizard typically has the goal of collecting information to be submitted to a remote service.