Sequencing Wizard Pages in a Suite Project

The new Suite wizard interface editor changes the way that authoring pages and dialogs is approached. For example, in a Basic MSI project, you have to manually author the order in which a dialog should appear or else it won't show up anywhere. Further, there's no implicit ordering of the pages that would indicate a good place to start when reviewing the dialog sequence. The Suite wizard interface editor provides the flexibility to pick a specific wizard page to show up at the right times, the ability to show a modal secondary window to alert the user of a specific situation to which they need to pay attention, as well as support for building a simple flow for your pages implicitly without extra effort on your part. I wanted to discuss some things we discovered as we moved through the design process when improving the wizard interface editing experience.

One change you'll notice is that the Wizard Pages node in the Wizard Interface view now has a series of pages listed similar to the ones listed below:

At run time, the installation starts with the first page in the list and evaluates the visibility condition for each page, displaying the first page whose condition evaluates to true. This allows you to have a simple, common entry point if you desire or, as appears in the default list of pages included in a Suite project, several entry points dependent on the installation's mode. Similarly, any time you press the "Next" or "Install" buttons you'll see that the flow moves to the next page with a valid Visible condition. The last major thing to note is that the last page in the list is reserved for the "End of Installation" page. This page is unique in that it's displayed regardless of the installation's outcome.

Building a sequence that is both easy to understand and easy to maintain is predicated around using good names for wizard pages and secondary windows (e.g. InstallationWelcome, InstallationRemoval) as well as having simple conditions on each page that are easy to understand. As you move down the list, you should have your pages that will drive installation flow after you have moved past pages that all users would see. For example, you would generally want your CustomerInformation wizard page to appear higher in the list than the SetupType wizard page during a first-time installation.

The primary maintenance concern, in terms of this design, is to understand when a page might point to a secondary window or, alternatively, break the natural flow. For example, it's not altogether clear, just by looking at the list of pages, that the Install button on the InstallationRemoval page will send you straight to the InstallationProgress page after performing some other operations. In these specific cases, it's useful to have them appear as high in the list as is possible since it's likely that a developer will touch the first few pages rather than a page halfway through the sequence. Alternatively, since page names are not visible to the user, you could use a notation to indicate the buttons and any mode conditions that are used on a specific page. For example, you could indicate mode conditions on a page using something like Setup for no mode, Install for install mode, Maint for maintenance mode, Stage for staging mode, and Remove for remove mode. Then you could prefix each page with the appropriate combination of b (Back), n (Next), c (Cancel), i (install), and f (Finish) to indicate which buttons are available. Finally, you could have each mode's entry point be indicated by using the name Welcome. This produces a sequence that looks similar to the following:

The advantage of doing something similar to the above would be that you get a clear picture of what each page is designed to do. In many environments, several individuals make changes to the Suite installer's UI as they add and remove packages. Regardless of which technique you pick, having a constant convention helps to understand the expected behavior for pages you didn't author or don't often review.

To mitigate confusion and eliminate the possibility that you could accidentally introduce a conflict in your conditions, pages should not have complex property conditions that require a maintainer to look through every page to figure out which pages could set a particular property (or even if any pages set the property at all). Instead, it's more useful to have the complex conditions on a button's Action field with simple conditions used in the page's Visible condition.

Lastly, it's important to present a consistent style to the user. Because you're displaying options for a series of installations, it's easy to have a lot of options that could be confusing or unclear to the user. A good way to reduce confusion is to use something like a CommandLink button to indicate to the user when an important decision needs to be made. CommandLink buttons break up the installation experience and bring the user's eyes near potentially important text. When you look at the default list of wizard pages, you'll see that this technique is used where possible. The exception to that style is the InstallationRemoval page. This page provides the normal user experience of clicking Remove to start the uninstallation, since that experience is more expected when coming from Programs and Features.

The Suite wizard interface editor opens up a lot of possibility in terms of organization compared to other project types. Feel free to experiment and share your thoughts on the best way to structure a good sequence of pages.

To download technical white papers on upgrades, patches, validation, and more, visit the InstallShield section in the Flexera White Papers Library.