UtterAccess HomeUtterAccess Wiki

Welcome Guest ( Log In | Register )

Custom Search
Edit Discussion
> Wizard Design    
Wizard Design

Designing a Wizard interface may be a helpful way to manage a complex set of input requirements and tasks into a simplified, multi-page form that can take the user through step-by-step, validating data as the user navigates through each page.

Contents

Basic Consideration in Wizard Design

  • UI is made of simple, uncluttered forms/pages
  • Each page should have a description of what is required by the user before continuing
  • Each page should have only a task or two to be completed before proceeding
  • The bottom of the page should have a Cancel, Back, Next and Finish buttons, enabled as pertinent to the page
  • When navigating back or forward, the wizard should remember any previuosly entered data


Design Options



Tabbed Form Design

A wizard can be created using a tabbed form. In this case, the form is created, with applicable nav buttons at the bottom, and a tab control that covers the rest of the page. The TabStyle property of the tabl control is generally set to none (to hide the tabs themselves from the user), and each "page" of the wizard is put onto each tab. The nav buttons then programmatically select which tab page is viewable.

Pros:

  • Only one form for the whole wizard (not much overhead management required by the developer)
  • All data is on a single form, very easy to manage


Cons:

  • No control of color of tab area
  • developement is difficult with TabStyle set to None because there's no way to select certain tab pages in form design

(UPDATE: For versions of Access prior to 2010, if using a tab control and the TabStyle is set to None, you can navigate to the pages in the tab control by using the droplist provided on the Formatting (Forms/Reports) toolbar.)

Multi-Form Design

A wizard may also be created using a multi-form design. This is where each page of the wizard is a seperate form itself. Actual form design in this case is quite easy for the developer, because each "page" is very easily editable, however the grouping and data management become quite difficult as a system is required to handle data throughout all stages of the wizard.

Pros:

  • Easy page design


Cons:

  • Difficult to track data across pages
  • difficult to keep pages grouped as required
  • multiple forms required for a single wizard (high overhead when employing the use of many wizards)
  • redundant use of nav buttons across each page
  • ensuring each page is placed correctly and reducing/eliminating flicker from loading forms is troublesome

Subform Design

The wizard designed using subforms are similar to a multi-form design, except the "pages" are displayed as subforms in the main form. Here we have a single form with buttons at the bottom, and a number of subforms stacked on top of each other for each page. As the pages are navigated, all but the current page's subform is hidden. With the BorderStyle property set to Transparent and the Special Effect set to Flat, the subform control will be invisible on the main form, making it seem as though the controls of the subform are part of the main for itself (the user won't know there's more than one form being used)

Pros:

  • All data is accessible from the main form
  • Individual page design is easy through editing subforms
  • Formatting and aesthetics are much more versitile than tabs


Cons:

  • Requires a new form object for each page of the wizard
  • Initial setup of subform controls is troublesome in design mode because they are stacked on top of each other




Examples/Templates

Edit Discussion
Custom Search
Thank you for your support!
This page has been accessed 4,762 times.  This page was last modified 11:36, 14 February 2012 by Jack Leach. Contributions by Ron Bianco  Disclaimers