If implemented correctly, wizards can really do some magic for your users and make them happier and satisfied. This recipe goes after desktop-based wizards. I will show you how to implement them using the WPF and provide you with some Microsoft Aero Wizard guidelines.
As was the case with the navigation pane pattern, a large number of different vendors are able to provide you with pre-built, fully capable desktop-based wizard frameworks implementing a number of rich functionalities.
I will show you how to build a simple wizard but you are encouraged to explore third-party options. However, the guidelines and suggestions I will be giving here are applicable to those third-party products, so do yourself and your users a favor and try to take the most out of these suggestions.
As I've already mentioned, we are going to build a desktop-based wizard in this recipe, and that's why I will be using WPF. Start your Expression Blend 4 and then select New project. From the dialog that appears select WPF and then WPF Application. Make sure that Language is set to C# and Version is 4.0. At the end hit OK.
There are several page types that can be used in wizards. They are:
Getting started page (optional)
Choice page
Commit page
Progress page (optional)
Follow-up page (optional)
Before you start building and implementing your wizard system, you should have a clear understanding of the task flow and user's actions. In this recipe, I will just mimic some typical wizard behavior but be sure to read the How to use and implement wizards section of this chapter.
OK, let's start with our building process in this recipe, I will build a typical choice page. After your new WPF project has been created you should notice that under the Objects and Timeline pane, Window and LayoutRoot grid controls are visible.
1. Click on the window and then under the Properties pane, set its Height to 429 and Width to 549 pixels. Set its Title to Add Printer. Also under the Common Properties section, locate the ResizeMode property and set it to NoResize.
2. From the Asset Library, draw a Border control on top of LayoutRoot. Click on Border control and set the following under the Properties pane:
Set the Width to Auto, Height to 40
Set all margin values to 0
Set HorizontalAlignment to Stretch
Set VerticalAlignment to Bottom
3. Under the Appearance section, set the BorderThickness value for Top to be 1.
4. Under the Brushes section set the following colors:
For Background: Solid color brush RGB (240,240,240) or HEX (#FFF0F0F0)
For BorderBrush: Solid color brush RGB (223,223,223) or HEX (#FFDFDFDF)
5. If you now hit F5 and start your application, you will notice that Border control is docked to bottom, looks gray with a bit darker top border. This is the area that we will refer to as to the command area.
6. In the command area, we put at least one Commit button to commit to the task or proceed to the next step. We will add two buttons now Next and Cancel. But as Border control can have only one child control, we need to add a Grid control and then draw our buttons on top of that Grid control.
7. With the Border control selected, from toolbox or Asset Library draw a grid control on top of Border controls itself. Under the Properties pane, set the grid's height and width to Auto, and all margin values to 0. That will stretch the grid and make it completely fill in the available space within Border control.
8. As grid is an extremely versatile and flexible control, we can now add our buttons on it. Select the grid and draw two buttons on it.
9. Call the first button btnNext and second one btnCancel. You can change their names by selecting them and then under the Properties pane (at the very top), you will find the Name property.
10. Select btnCancel, find the Content property, and set it to Cancel. Set Width to 65 and Height to 23. Choose Right as the HorizontalAlignment and Top for VerticalAlignment. For margin values, use 0 for Left and Bottom, 10 for Right, and 8 for Top; this should position our btnCancel nicely.
11. Now, let's change some properties for btnNext. Set the Content property to Next. Also, set the Width to 65 and Height to 23. Choose Right as HorizontalAlignment, and Top for VerticalAlignment. For margin values, use 0 for Left and Bottom, 85 for Right, and 8 for Top. And under the Common Properties section, locate the IsEnabled property and uncheck it.
12. Press F5 now and your wizard should look close to the one in the following screenshot:
 |
13. So far so good. It's good to point out at this stage that you will have to use code to manipulate when the Next and other buttons are enabled, which will depend on the current progress and the context of your wizard.
14. Now we need to add the main instructions. It's basically a text label that summarizes what to do in the current wizard page. We can use Label as a control for this. So, draw a label (you can get it from Asset Library or toolbox) on top of the LayoutRoot and set the following properties:
Set Name to lblMainInstruction
Set Foreground color to RGB (0, 51,153) or HEX (#00003399)
Set both Width and Height to Auto
Set HorizontalAlignment to Left, and VerticalAlignment to Top
For margin values, set Left to 32 and Top to 14
Finally, set Choose a local or network printer for the Content property
15. These settings will always be the same for the main instructions for each and every wizard step. Only exception is the Content property, which must change appropriately.
16. As you remember, the page that we are currently working on is called "choice page". We have a main instruction, a command area, and now we will design the content area that hosts other controls and objects.
17. We will use regular buttons for this part although for the wizard pattern you should use command links. I will be explaining how to design and implement action or command links in Chapter 2, so be sure to go through that recipe and use controls and designs defined there instead of the buttons that I am going to use here for the sake of the brevity.
18. We will use two buttons that will provide users with choices.
19. Draw two buttons; name the first button btnLocalPrinter and the second one btnNetworkPrinter.
20. Let's set the following properties for btnLocalPrinter:
Under Brushes section set Background to No brush
Set Height to 58
Set HorizontalAlignment to Stretch and VerticalAlignment to Top
For margin values, set 50 for Left, 10 for Right, and 55 for Top
Set HorizontalContentAlignment to Left and VerticalContentAlignment to Top (You might need to click on Show advanced properties to display these properties.)
Under Padding, set Left to 20, Right and Bottom to 1, and Top to 6.
Set Content to Add a local printer.
21. Now set the following properties for btnNetworkPrinter:
Under the Brushes section set Background to No brush
Set Height to 58
Set HorizontalAlignment to Stretch and VerticalAlignment to Top
For margin values, set 50 for Left, 10 for Right, and 145 for Top
Set HorizontalContentAlignment to Left and VerticalContentAlignment to Top (You might need to click on Show advanced properties to display these properties.)
Under Padding, set Left to 20, Right and Bottom to 1, and Top to 6.
Set Content to Add a network, wireless or Bluetooth printer
This basically sets the stage for your further improvements and customizations. The next steps are defining other page types and adding interaction logic between them. I will describe those page types and typical considerations that you need to take into account and address when designing and implementing your wizards.
It is of utmost importance for you to have a clear understanding of your wizards' purpose and flow. Don't go and start designing and implementing wizards before you have that. You need to come up with a logical flow, specific page designs, and then start designing. However, the page that you will be designing (in almost 100% of cases) will be a simple choice page. In the last recipe, I've outlined the basic idea of how to design a page and now we will dig a bit into some technical details.
First of all, we have set ResizeMode to NoResize in order to keep our windows' dimension fixed (429 by 549 pixels, in our example). As a consequence, we get only a Close button on our window. Guidelines do allow implementation of resizable windows for wizards but I am generally opposed to that approach and I will explain the reason for this under the There's more... section.
Okay, in the next step, we have used Border control for designing the command area of our choice page. As border, as a control, can have only a single child element, we have added grid as a child element of Border and then hosted Next and Cancel buttons within grid control (which can accept as many child elements as you need).
You must pay special attention when it comes to handling Next, Cancel, Apply, and other buttons or commands that will appear in this area; this includes taking care if they are enabled, disabled, visible at all times, and so on. I am outlining those guidelines later on, so be sure to check them out.
After we have designed the command area, we are ready for setting up the main instruction the text label that is used for summarization of what to do in the current wizard window. It is really important to make it as understandable as possible so that users can understand what is being done in this specific window just by reading the main instruction.
Next step was designing the content area the main area of your wizard page where you usually place commands and where the most attention of your users will be focused on. We have added two "command links". (I am putting them under quotes for a reason: they are not real action or command links, what I have done basically is just changed some of the properties of regular buttons. But you can find how to design and implement real action or command links under Chapter 2, Actions and Commands.)
As you've learned so far, wizards can be fairly complex and incorporate numerous page types given wizard's purpose. In this section, you will gain much more insights about those types and when and how to use and implement them. Again, this is WPF recipe but the general ideas, user experience considerations and design itself can be easily applied to Silverlight itself.
In this recipe, I've guided you through the process of designing the very simple, even incomplete, choice page as a part of the wizard. According to the general UI guidelines, all wizard pages have a title bar, main instruction label(s), a content area, and a command area. In the previous recipe, we have designed all parts of our choice page except for the title bar. The fact is that the title bar for the so-called "Aero Wizards" looks pretty different from the one we have defined it comes with an extended glass surface with the name of the wizard, the Back button in the upper-left corner, and a Close button with optional Minimize or Maximize buttons.
 |
In the last chapter of this book, I am explaining how to extend the glass surface into your WPF windows, so you can refer to that recipe and use it for creating more realistic Aero Wizards even without third-party controls (if that is something you'd like to do).
Anyway, let's go through the typical wizard page types.
There are several typical wizard page types:
Getting started page (optional)
Choice page
Commit page
Progress page and (optional)
Follow-up page (optional)
It is optional and its purpose is to outline the prerequisites or to explain the purpose of the wizard. But the general suggestion is not to use this page if all of the necessary information can be shown on the first choice page.
 |
Wizards usually have more than one choice page; they are used with the purpose of gathering information from users in order to complete a specific task. A general suggestion is to use wizards if you know that users will be presented with more than two choice pages. If, however, you are dealing with one or two choice pages, you should consider using the regular dialogs and not the wizard because it is a pretty heavy UI pattern.
 |
This type of page looks quite similar to the regular choice page but there is one significant difference: after a user commits an action, there is no going back; in other words, action cannot be undone. That also means that the commit page does not have a Next button; it has buttons that clearly state commands such as Connect or so.
There is no common agreement as to whether there should be only one or more commit pages in a single wizard. However, personally I am a strong supporter of the single commit page idea.
 |
If during the wizard there is going to be an operation that will take four or more seconds, you should use the "progress page" type. It is optional, in the sense that if your operations will be shorter than four seconds, you are fine to drop the progress page.
They are, in most cases, called after the Commit page and with a progress bar animation (or some other operation's progress indicator such as custom animation); they are good indicators of the operation's progress for the end users.
When an operation is done, the wizard should advance automatically to the next wizard page.
 |
This type of page is optional and is being used to provide users with final results or outcomes.
I am not a big fan of "Thank you" pages. Stick to the task and get to it; your users will appreciate that much more than Thank you for installing this device, especially if it has taken them longer and you are just prolonging that with a useless "Thank you" page.
 |
Although Microsoft says that usage of resizable wizards is fine under Aero Wizard specifications and guidelines, I would advise you to be careful when you decide to go for resizable wizards.
Let me make it clear that I am not completely against it but I would suggest and play safe and use ResizeMode = NoResize.
I guess that my strongest argument for this would be having buttons in the command area always positioned in the same location. Imagine the scenario where you can go through your wizard just by clicking on Next several times. It is much faster if the Next button is in that case positioned at the same location. Of course, in this case, I am pointing out the problem where you are changing your wizard's dimension on a page-by-page basis. However, having wizards resizable so that they can leverage extra space available might be good idea.
Again, I'd say play it safe; optimize them for minimum resolution supported under Windows Vista or Windows 7 (800 x 600), and don't go for some wild resizing behaviors.
I bet you all remember older wizards; you can find them if you are still using Windows XP or with some third-party applications that are just breaking all known UI or UX guidelines for wizard applications under Windows Vista or Windows 7. Older wizards were based on a standard called Wizard97 and that "97" is not there for no reason, so we should think about the year we are currently in.
Anyways, new wizard standards are in place and some of the changes include more flexible page layout and text formatting, and removal of the really unnecessary Welcome or Congratulations or Finish pages. (I bet those are not being missed by anyone.)
Some other pillars are the prominent main instructions with the great idea of unifying the earlier heading and subheading. Also, implementation of command links is a nice way of enabling users to have immediate and generally more expressive choices, thus eliminating the usage of several UI controls such as radio buttons followed with a Next button.
Navigation within wizards is more aligned with the one that is usually found on the Web and within Windows Explorer. In our recipe, we have not implemented that kind of navigation but you can read about it in the Journal navigation recipe of this chapter.
You might have noticed that the Back button is not present in the command area, rather it is now located in its new standard location upper-left corner. I've had several opportunities listening to people saying that in the beginning, this was a bit distracting to them but now they actually see the point; more focus is being given to commit choices.
Don't go for wizards like there is no tomorrow. Wizards are considered as heavy user interface elements and should be used sparingly. They are used for multi-step tasks, especially if they are not frequently performed. You might consider some other alternatives to wizards dialogs, task panes, and others.
The Next button is used only when advancing to the next page but without commitment, which means that the Back button is always available and presented after the Next button. According to Microsoft's guidelines, advancing to the next wizard page is considered a commitment when its effect cannot be undone by clicking on Back or Cancel buttons. Sounds quite logical, doesn't it?
Commit buttons are as specific as possible; for example, you should use captions such as Print or Connect instead of Finish or Done. Generic labels such as Next should not be used because they are suggesting the next step and not a
commitcommand. However, there are two exceptions: Finish can be used when there is a collection of settings to be applied and if specific responses (Get, Save, and so on) are generic. The Commit button should always start with a verb, never a noun.Command links are here for choices, not commitments. They are unifying the collection of radio buttons and the Next button. So when you are using command links, hide or disable the Next button but leave the Cancel button. This was exactly the case in our recipe where we have used two command links.
Wizard is a tricky term; never use "wizard" in wizard names. But it is fine to use "wizard" when referring to it as a specific UI element.
User choices must be preserved. This means that when users make a specific selection, then clicks Next, and after that Back, previous selections should be preserved.
Forget about "welcome", "get started", and similar types of pages. Make the first page fully functional whenever possible. There are some exceptions but resort to them sparingly. You can use "getting started" pages only in situations where there are some prerequisites that are necessary for successful completion of the wizard, when the purpose of the wizard may not be clearly understandable from the first choice page, and you don't have enough space on first choice page for additional explanation. In any of these exceptions, the main instruction text should be Before you begin: and never some version of welcome, let's get started, or anything like that.
Forget about "Thank you" or "Congratulations" pages, too. Wizard's final results should be clear and apparent enough for the users that you can just close the wizard after the final Commit button. You can resort to "follow-up" pages if you think that there are some usual follow-up tasks that users are likely to do as a follow-up. However, in that case, avoid using familiar, simple, everyday tasks. Follow-up pages are necessary after progress pages to indicate task completion. But again, if the task is long running (I'd say longer than five minutes) and can be performed in the background, then just close the wizard on the "commit" page and resort to notifications (such as balloons) to give a final feedback to the end users.
Commit pages are used to make it clear when users are committing to the task. As a general rule, the commit page is the last page of choices and it does not contain the Next button. Rather, the Next button is relabeled in a way that is described in the guideline about commit buttons (mentioned above). Sometimes, if the wizard was used for a really risky task or there is a significant doubt that the users have understood their selections, you might want to use a summary page and outline all of the selections and choices of the users, so that they can review them and act upon them.