Backward Compatible Wizard 97

Synopsis

This document summarizes changes in design for a new wizard user interface style. This specification is to be used for any wizard that will need to be backward compatible with Windows 95 and Windows NT 4.0 operating systems and, therefore, should be built with standard wizard common controls (those used for developing Windows 95 wizards.) Wizards that will function only on computers running Windows 2000 or later, including wizards in Internet Explorer 5, should refer to the regular Wizard97 for 1999 specification.

Microsoft Platform SDK, February 2001 Edition.
This content last built on Thursday, February 01, 2001.


Legal Information

This is a preliminary document and may be changed substantially prior to final commercial release. This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 1997 – 1999 Microsoft Corporation. All rights reserved.

Microsoft, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the USA and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.


Introduction: Goals

UI design within the Windows NT and BackOffice groups has largely kept pace with contemporary graphic design trends and has steadily improved user interface design in the last three years. However, though highly visible, wizard design has remained static in these areas. It is important, with the release of new versions and new products, to continually update and improve the wizard's graphic design ('look and feel') as well as the user interface design consistency.


Updating Graphic Design

The new design calls for a new graphics style and symbol style. In addition, by slightly enlarging the overall wizard size, layout of wizard text and controls can be improved. Also, some 'negative space' within this slightly larger wizard gives the design a more contemporary look.


Improving Wizard Design Consistency

In the past, our wizards have been inconsistent in their introductory and finish pages, interior page titles (or the lack of), and presentation of information. To deal with these problems, the new wizard design includes the following:

  • In the new wizard's Welcome page design, a general explanation of the wizard's task or purpose is stated.
  • A list or overview of the main or specific tasks can be included in the Welcome page.
  • On all interior pages, a header area contains a title naming the task particular to each page and a brief one-sentence subtitle statement clarifying the task.
  • The Completion page provides closure for the wizard and can contain either a general description or a specific list of what was accomplished in the wizard.
  • The Completion page can also point the user to related tasks to be accomplished following wizard completion.


Graphic Design for Wizard Art

Wizard art appears on the left side of wizard Welcome and Completion pages. The wizard art should be based on a symbol design that reflects the purpose or function of a particular wizard. For example, a wizard dealing with printers or printing might have a printer for the basis of its symbol design.

Also, wizard art should reinforce individual product branding through the use of color. Color appears in the watermark graphic on Welcome and Completion pages (see Figure 1a.)

3.1 Welcome and Completion Page Art

The wizard art relies on a symbol design to convey a specific message. This can be accomplished in two ways. In the first method, the primary symbol image is used twice: within the square bounding box and again in the watermark background behind the square (see Figure 1a). The second method employs two different symbol images to convey a specific message, and gives the user a better visual representation of purpose of the wizard. In Figure 1b, for example, the plus sign image in the square illustrates the action of 'add', and the watermark background image illustrates the main subject, a printer.

Figure 1a Wizard art for Welcome page or Completion page: employing a single symbol image

Figure 1b Wizard art for Welcome page and Completion page: employing two symbol images


General Layout for Wizard Pages

General page layout guidelines for wizard pages in dialog units are found in Figures 2 and 3.

Development Note The dialog units were calculated with MS Sans Serif 8 pt. as the system default with the computer set to display small fonts.


Font Sizes and Styles

For the Welcome and Completion pages, use Ariel, 12 point, bolded, for the text, "Welcome to the Sample Wizard" or "Completing the Sample Wizard" text. Use MS Shell Dialog font for all page descriptive text. For the interior pages, use MS Sans Bold for the title in the header section and MS Shell Dialog for the subtitle. For the text in the body of the page, use MS Shell Dialog. In general, do not bold text in the body of wizard pages.

Development Note In the Welcome and Completion pages, the title font name and size, Ariel, 12 point, bolded, should be loaded from the resource file thus allowing localizers the ability to change it. If the wizard being designed is a system component, development should specify the font name as "MS Shell Dlg." This will allow a system to re-map the font if necessary.


Welcome and Completion Page Layout

Use the dialog unit (dlu) measurements indicated by the outer dashed line (dlus: 317w x 179h) when building a wizard using the Wizard 95 common controls (see Figure 2). The controls automatically add 7 dlu on all four sides. Also shown in the figure are the X and Y coordinates for text box placement.

Figure 2 Welcome or Completion page in dialog units (dlus)


Interior Page Layout

Use the outer measurements indicated by the dashed line (dlus: 317w x 179h) when building a wizard using the Wizard 95 common controls (see Figure 3). The controls automatically add 7 dlu on all four sides.

Figure 3 Interior page layout in dialog units (dlus)


Margins and Indents

Margins in Welcome and Completion pages should follow the specifications given in Figure 2. In the interior wizard pages, the margins and indents can vary depending on the content of the page, as shown in Figures 4 and 5 that follow.


Wide Margins

Only use the outer margin when the page contains particularly wide content, such as side by side list boxes. For layout measurements see Figure 4.

Figure 4 Use of outer margin in wizard page body


Indenting for Clarity

As a rule, indenting beyond the normal margins is not necessary. However, indenting can be used to visually separate similar groups of objects on a page, such as when there are more than two items on the page. Indenting is done in increments of 10 dlus.

Figure 5 Indenting for clarity


Paragraph Spacing

There should be 7 dialog units (dlus) between paragraphs.

To calculate the vertical distance between paragraphs

  1. Start with the vertical dialog unit coordinate of the top left corner of the first paragraph text box.
  2. To this number, add 8 dlus for each line of text in that paragraph.
  3. Next add 7 dlus for the space between paragraphs.
  4. This will give you the vertical location for the text box for the second paragraph.

Figure 6 Correct paragraph spacing


Spacing of Controls with Text

Figures 7a, 7b, and 7c show recommendations for the vertical layout and spacing of edit boxes, list boxes, and radio buttons in relation to lines of text. The measurements noted in these figures show either vertical or horizontal placement of text and controls as measured in dialog units.

Figure 7a Relation of stacked edit boxes and text

Figure 7b Relation of text, list boxes, and edit boxes

Figure 7c Relation of text and radio buttons


User Interface Design Guidelines

The main purpose of any wizard should be to enable a user to perform a specific task with as little difficulty as possible. The user interface design for each wizard page should support that purpose by presenting one step per page, with the instructions for carrying out that step as clear and concise as possible. For more comments on effective wizard design, see section 7 "Usability Recommendations" in this specification.

The following examples represent a variety of page designs frequently encountered in wizards.


Welcome Pages: Appropriate Usage

Figures 8a, 8b and 8c show Welcome page designs that introduce the user to the task of a wizard and supply the user with any other pertinent information necessary for completing the task.

The Welcome page design in Figure 8a illustrates that:

  1. The name of the wizard should always appear in the title bar.
  2. "Welcome to the Sample Wizard" should always appear as the title with the page.
  3. The task of the wizard may be stated.
  4. General pertinent information may be stated.
  5. "To continue, click Next." may be stated.

Figure 8a Welcome page design

The Welcome page design in Figure 8b illustrates that:

  1. The name of the wizard should always appear in the title bar.
  2. "Welcome to the Sample Wizard" should always appear as the title within the page.
  3. The task of the wizard may be presented as a detailed list. Bullet points can be used for clarification. (Small bullet points can be created using the letter 'h' in the Marlett font.)
  4. Important information for successful wizard completion may be stated. The yellow alert icon may be added for emphasis.
  5. "To continue, click Next." may be stated.

Figure 8b Welcome page design

The Welcome page design in Figure 8c illustrates that:

  1. The name of the wizard should always appear in the title bar.
  2. "Welcome to the Sample Wizard" should always appear as the title within the page.
  3. The task of the wizard may be stated.
  4. "To continue, click Next." may be stated.
  5. The option may be given to forego the presentation of the Welcome page in the future, if appropriate. This option can be implemented by the use of the check box and text shown in Figure 9c. However, only use such an option for wizards that users access for administrative-type tasks on a very frequent basis.

Figure 8c Welcome page design


Completion Pages: Appropriate Usage

The Completion page reinforces that the user has successfully completed all the steps of the wizard. It can also provide further closure of the wizard task by summarizing what was accomplished and, in certain cases, by stating what should be done next. Figures 9a, 9b, and 9d illustrate various Completion pages, and Figure 9c illustrates a related page.

The Completion page design in Figure 9a illustrates that:

  1. The name of the wizard should always appear in the title bar.
  2. "Completing the Sample Wizard" should always appear as the title with the page.
  3. That the wizard has been successfully completed may be stated.
  4. A brief list may be presented of either the tasks the user completed while in the wizard or the tasks the user will complete upon clicking Finish and closing the wizard. If a longer list is needed than what is shown in Figure 10a, place it in a scrolling list box. However, since the space available is limited, reserve the Completion page for a wizard closure that is as simple as possible. Crowding the Completion page, or any wizard page, with text allows no space for localization in certain foreign languages (see "Localization" section 8.) Therefore, when longer lists or list boxes are necessary for summation put them on a regular wizard page previous to the Completion page.
  5. "To close this wizard, click Finish" should be stated when tasks have been completed while in the wizard.

Figure 9a Completion page design

The Completion page design in Figure 90b illustrates that:

  1. The name of the wizard should always appear in the title bar.
  2. "Completing the Sample Wizard" should always appear as the title within the page.
  3. That the wizard has been successfully completed may be stated.
  4. When important, any necessary details of how any process started in the wizard might be completed may be given. The yellow alert icon may be added for emphasis. In this example, after a user clicks Finish and the wizard closes, a standard progress dialog with a progress bar can appear and remain on the screen until the process is completed. However, the user interface described in the following examples (see Figures 9c and 9d) is preferable for any process lasting for more than a few minutes.
  5. State that in addition to the wizard closing, another action will take place when a user clicks Finish.

Figure 9b Completion page design

Figure 9c is an example of a page that can directly precede the wizard Completion page. It gives the user enhanced feedback on the final task that will take place as a result of the wizard — without having to exit the wizard first. Once the process is completed, the regular wizard Completion page can follow to provide closure to the entire wizard task (see Figure 9d).

Figure 9c Summary page prior to Completion page

The Completion page design in Figure 9d illustrates that:

  1. The name of the wizard should always appear in the title bar.
  2. "Completing the Sample Wizard" should always appear as the title with the page.
  3. That the wizard has been successfully completed may be stated.
  4. "To close this wizard, click Finish" should be stated when tasks have been completed while in the wizard.

Figure 9d Completion page design


Interior Pages: Scenarios

The following figures (see Figures 10a, 10b and 11) illustrate some common user interface issues particular to wizard design. However, most interior page wizard designs follow common Win32 user interface design style guidelines.


Displaying Secondary Windows

Inexperienced users are often confused by the addition of secondary windows. They are confused when, as in Figure 10a, they have already clicked Next expecting to proceed to the following page and instead the first page remains with a secondary dialog on top. Therefore, it is recommended that the content of the secondary dialog be placed in a following wizard page, as in Figure 10b.

Figure 10a INCORRECT use of secondary dialog

Figure 10b Secondary dialog correctly incorporated as a wizard page (RECOMMENDED)


Using Alert Icons

In order to draw special attention to very important information, either the information bubble symbol or yellow warning symbol can be added before text.

Figure 11 illustrates that:

  1. The information bubble icon can emphasize important yet not crucial information.
  2. The yellow warning icon can emphasize information vital to either the success of the task or the consequences of the actions performed on the wizard page.

Figure 11 Alert icons


"More Information" and Context-Sensitive Help in Wizard97

More Information

Wizard pages should be designed so that they are easy to understand. Having a normal Help button that brings up an additional rich interface, the Help interface, may confuse users by taking them out of one relatively complex interface into another. Inexperienced users can lose their context. Therefore, where it is necessary to explain difficult concepts, place a single button with the title "More Information" on the left hand side in the BODY of a given wizard page, NOT in the control area at the bottom of the wizard (see Figure 12a). This button should bring up a simple dialog that displays the necessary information in a list box (see Figure 12b).

In the examples below, the More Information button in Figure 12a will provide additional information about the topic of the particular wizard page. That information is presented in a simple dialog (see Figure 12b).

Figure 12a More Information button

Figure 12b More Information dialog

Context-Sensitive Help

The What's This (?) button should only appear on the wizard in the title bar if the wizard supports context-sensitive Help for all of the controls. If context-sensitive Help only exists for the Back, Next, and Cancel buttons, the Help cursor should NOT appear.


Text

To promote usability, the new wizard style provides for statements of purpose and summation on the Welcome and Completion pages respectively, and for clearer, more consistent Interior page text in the form of a title and task description in the header section of each page.

It is very important to remember not to overcrowd any page with text. Usability results have shown that users are overwhelmed by a lot of text — tending either not to read it or not to comprehend it.


Welcome Page Text

Welcome page text begins with "Welcome to the Sample Wizard", and then gives a comprehensive explanation of the wizard's purpose. It can begin by stating, "This wizard helps you to…" (Example: "This wizard helps you to create a new user account on this computer."). When appropriate, a list of the tasks performed by the wizard can be included. For examples of Welcome page text, see Figures 8a-c.


Interior Pages Header Section Text

This text includes a short title for the page that defines the subject or task of that particular page followed by a subtitle giving a one-sentence description of the task to be performed by the page. Examples of titles and subtitles are given below.

Development Note The title font name and size should be loaded from the resource file thus allowing localizers the ability to change it. If the wizard being designed is a system component, development should specify the font name as "MS Shell Dlg". This will allow system to remap the font if necessary.

Figure 13 Title and subtitle in the header section of an interior wizard page

The subtitle can be written in several ways: as a question, as a description, or as a description in the second person singular (You).

Title and Subtitle Examples

  1. Subtitle as a question:

    Computer Operating System (title)

    Is the computer's operating system set up to operate with Small Business Server? (subtitle)

  2. Subtitle as a description of the purpose of the particular page:

    Computer Operating System Installation (title)

    Installation files will be copied to your hard drive. (subtitle)

  3. Subtitle as a description in the second person singular:

    Sounds (title)

    You can choose a sound scheme and then preview its different sound events. (subtitle)

Additional Title and Subtitle Examples

  • Signing Options (title)

    The type of signing will determine the options you can specify for the signing operation. (subtitle)

    (Then below in the body, it says, "Choose a signing type.")

  • Hash Algorithm (title)

    Hash algorithms are techniques that compute a condensed representation of a data file. (subtitle)

    (Then below in the body, it says, "Select an algorithm from the list.")

  • Data Timestamp (title)

    Time stamping guarantees to others that the data existed on a certain date. (subtitle)

    (Then below in the body, it says, "Set the timestamp below.")


Completion Page Text

Completion page text begins with "Completing the Sample Wizard" and also "You have successfully …(done such and such)." In some wizards it might be appropriate to actually list the tasks the user completed or things the user should do after exiting the wizard. For examples of Completion page text, see Figures 9 a, 9b, and 9d.


Usability Recommendations

Microsoft Platform SDK, February 2001 Edition.
This content last built on Thursday, February 01, 2001.


Scope and Audience for a Wizard

Follow the published guidelines for creating a wizard. Users are better served by a common look and feel. Also, the standard elements have usability tested well and are there for a reason. Microsoft Internet Explorer 5.0 is shipping with a wizard common control, which should encourage future applications to settle on a common look and feel.

Avoid a wizard design that requires the user to leave the wizard to complete a task. Less-experienced users are often the primary users of a wizard. They need a lot of handholding and easily get lost. Asking them to leave the wizard temporarily or to keep it onscreen while doing something else (e.g., working with the content of a document) is usually too much to ask. Make sure that users can do everything from within the wizard.

Always provide step-by-step instructions. Wizards that don't provide step-by-step instructions aren't wizards. A major goal for a wizard is to shield users from a more-complicated UI. Adding Back and Next buttons to a full-scale UI does not constitute a wizard.

For complex tasks, focus on the most common scenarios, provide multiple paths, or create multiple wizards. Don't try to cram all the functionality into one wizard or path through the wizard. Carefully examine users' tasks to understand what things the wizard must support well. Consider implementing different paths through the wizard for different user experience levels. Also consider breaking a big wizard up into smaller, more focused wizards.

Consider advanced user needs when contemplating having a wizard as the only UI. Users with extensive domain knowledge and/or extensive GUI experience want their work to be efficient and they want access to all of the functionality. These goals can be at cross-purposes with a wizard. Having a wizard as the only UI for a feature works when the task itself is fairly simple or multiple paths are provided through the wizard.

Be careful to not automate too much of the process. Carefully study users' tasks when creating a wizard. Be sure that users will be comfortable with the amount of control they have over the process.


Finding, Choosing, and Starting a Wizard

Advertise wizards as much as possible. Wizards obviously don't help users if they don't know they exist. If a product has a startup screen with revolving hints, put a hint about wizards there. If the product has Intellisense help, turn on the light bulb when the user does a task the "old" way or the "hard" way the first time and advertise the appropriate wizard in the hint. If the product has a "What's New" section in Help or in the printed documentation, mention wizards there.

In some cases, it may be appropriate to replace the normal UI with a wizard the first time. This is done, for example, in Windows 95's Modems control panel. The first time the control panel is opened, it contains no modems, so the control panel launches the wizard that is normally seen when the "New..." button is clicked.

Use caution when providing multiple access points for a wizard. It may make sense to put a pointer to a wizard in more than one place. Choose places that users are most likely to look. Be aware, however, that users may not understand that you are providing multiple links to the exact same wizard.

Make sure startup dialogs are visually simple and easy to navigate. A common problem is providing too much functionality on a startup dialog. This dialog is designed primarily for novice users, so the number of choices needs to be small and the controls need to be clear and easy to use. Include only the most common tasks on the startup dialog.

When providing a list of wizards, make sure users can compare the options easily. Terse descriptions of each wizard are probably not sufficient, especially for users learning a new program. Whenever possible, show a graphical sample of the results of each wizard.

Avoid context-sensitive wizards. Instead, prompt the user to choose. Users may not understand the subtle differences in state or content for a wizard. If the same wizard can apply to different problems, ask the user what task s/he wants to accomplish.

Always include overview information and be sure that it is clear. Users often do not understand the purpose of a wizard clearly. Always include a description of the purpose of the wizard and make sure it is written in terms the user already understands. If there are prerequisites for using a wizard, tell users what they are in the overview. Perhaps direct them to a tutorial that covers the needed background information.

Put the overview information on the first screen, by itself. Avoid putting anything else on the overview screen. Giving the overview its own screen helps ensure that users will read it, at least the first time through. Also, some users may skip the overview so it's important that they don't skip other wizard content. (The Welcome page serves as the overview screen.)


Using a Wizard

Avoid tree controls to display hierarchies. Use a flat representation where possible. When using a flat representation, show all levels of the hierarchy, when possible, so users can see the links between the levels.

Limit each screen to one step. Following a "one step at a time" design reduces the complexity of each screen. It's better for users to go through a few more simple screens than for them to spend time trying to figure out a few complex screens.

Minimize the number of controls and required actions on each screen. When each screen has one step, this recommendation is pretty easy to follow. Keep each screen visually simple. Avoid users having to discover sequences of actions (e.g. drag this object there, then press that button).

Avoid advancing screens automatically. Users may not be able to read the information before the screen advances. In cases where a wizard screen is just providing status information, consider popping up a status dialog on top of the wizard instead, to indicate that the information is not critical.

Ensure the default state and behavior of all controls makes sense to users. Details like this make a good wizard great.

Make all information visible. When impossible, include instructions for using view port controls. Novice users often don't know how scroll bars work. When such controls are necessary, be sure to include usage instructions onscreen.

Avoid sub-dialogs. Sub-dialogs introduce an undesirable level of complexity in a wizard. When it's absolutely necessary to add a sub-dialog, make sure that only rarely used options are located there. (Assume most people will never look at the sub-dialog.)

When a wizard is launched from a dialog, make sure the original dialog is completely obscured. Users can easily become confused by seeing two different user interfaces for the same task and may try to use them simultaneously.

State the sub-goal of each screen explicitly. The steps in a wizard are often not obvious to users. Explicitly (in a phrase or sentence) describe the purpose of each screen in the header area at the top of the content area.

When the purpose for two successive screens is similar, contrast them. Help users distinguish between two similar screens by stating, on the second screen, how it is different from the first screen.

Make sure navigation controls are in the standard location and are set off from surrounding information.

Include navigation hints for novices. Don't assume that all users intuitively understand that a wizard is a step-by-step procedure.

Avoid using "<<" and ">>" controls for Rewind and Fast Forward. Instead, use them in field pickers for Remove All and Add All. Users generally don't need to go all the way back; leave this function out. Use Finish instead of ">>" for fast forwarding.

Prevent errors where possible; otherwise, make sure users are aware of the error. Testing a wizard with users is a great way to find the top five errors. To ensure that users will notice an error condition, pop up a message that makes them stop what they're doing.

When showing UI elements in static artwork, make it visually clear that the items are not active. There are many ways to do this, such as making the elements smaller or larger than normal, overlaying them on an abstract background, etc.

Define all technical, unfamiliar, and ambiguous terms in language users understand. Test terms and definitions with users to ensure that they make sense.

Test textual descriptions with users to make sure they aren't too short or too long.

Whenever possible, include help text in the main body of the wizard rather than on a separate sub-screen. Users are more likely to notice the help and use it if it's on the main screen. The information will also be easier for them to use if they don't have to recall it from memory when working on the main screen.


Finishing a Wizard and Task Support after Completion

Disable the Finish button until output will be meaningful. Users often don't realize how best to use the Finish button. Help users by disabling the Finish button until they have created useful results.

If the Finish button is not used, be sure to explain alternate completion options clearly. Users, especially the first time through a wizard, need help choosing which way to complete the wizard.

Always put completion options on last screen. Avoid adding screens after the completion screen — make the end "the end".

Be careful when using nested wizards. If possible, adjust the text on the final screen of a chained wizard to indicate that the end of the overall process has not been reached.

Support using a wizard for iterative editing of an object whenever possible. Users are more productive when they can experiment quickly with different formatting and organization options.

Don't reload previous data for a wizard if the user intends to create a new object. Users don't want to spend time erasing old information.

Provide as much post-wizard task support as possible. Users will be much more productive if they can continue learning a new product with some sort of assistance. In fact, don't assume that users can use a wizard to learn the regular UI. They will need other tools to help them do this (advisors, Help, etc.).

Watch for indications of users never growing beyond a wizard. This behavior may be an indication that the regular UI is too complicated. Consider advertising the regular UI so that users can learn about more advanced features and more efficient ways of working.


Localization Issues for Design and Development

When designing the user interface for a wizard and when actually implementing the design in the layout and code, there are important issues to consider in order for the wizard pages to be localizable. The following list details some of the more important localization considerations.

  1. Add at least 30% more space in the wizard pages and any secondary dialogs for text expansion.
  2. Add at least one extra line to text boxes when a variable is used within a sentence.
  3. Try to avoid using UI controls within a sentence.
  4. Don't use slang and technical jargon.
  5. Create generic icons and images that don't have to be localized.
  6. Don't use custom UI controls.
  7. Make sure all localizable strings are not hard-coded.
  8. Put font information into the dialog (especially for wizards, the font size at run time is much larger.) Any font information should be in resource (facename, size, charset, codepage langID etc.) when setting font in code.
  9. Make sure text can be wrapped, especially text after check boxes and radio buttons. This can be accomplished by always setting the text for multi-line and top alignment.
  10. If possible, don't put the text for buttons etc. in the string table but in the dialogs themselves — not only buttons, but any dialog items and menu items as well.
  11. Don't combine strings at run time to form new strings.
  12. Don't separate a sentence string into several strings.
  13. Get rid of old UI text and controls that are not used anymore.
  14. Don't use more than one placeholder per message if they are of different types (for example, string and int).
  15. Enumerate placeholders if more than one is used.
  16. Don't assume the English structure when the sentence contains placeholders.
  17. Avoid using placeholders like %s. (If placeholders are used, document what is going to be pasted it).
  18. Avoid using multiple variables, or use %1, %2, %3… instead of multiple %s.
  19. Use consistent terminology. Use of period (.), colon (, ; :), and Caps should also be consistent.
  20. Check spelling (typos in English expressions reduce the chances to use features like auto translate).
  21. Never place text that must be localized into bitmaps where it cannot be accessed by localization tools.


Accessibility Issues

Below are two accessibility documents containing important guidelines for user interface design:

The Designed for Microsoft Windows NT and Windows 95 Logo Program

The Microsoft Windows Guidelines for Accessible Software Design


Wizard 97

Synopsis

This document summarizes changes in design for a new wizard user interface style. This specification is to be used for any wizard that will need to function on computers running Windows 2000 or later, including wizards in Internet Explorer 5. Any wizard that needs to be backward compatible with Windows 95 and Windows NT 4.0 operating systems should be built with standard wizard common controls (those used for developing Windows 95 wizards) using the guidelines in the Backward Compatible Wizard 97 for 1999 specification.

Development Note This spec pertains to: comctl32.dll, file version 5.00, product version 5.0.1011.2000, that comes with IE 5 or NT 2000.


Introduction -- Goals

Platform SDK: Wizard97

Introduction — Goals

UI design within the Windows NT and BackOffice groups has largely kept pace with contemporary graphic design trends and has steadily improved user interface design in the last three years. However, though highly visible, wizard design has remained static in these areas. It is important, with the release of new versions and new products, to continually update and improve the wizard's graphic design ('look and feel') as well as the user interface design consistency.


Graphic Design for Wizard Art

Wizard art appears on the left side of wizard Welcome and Completion pages and in the header sections of the interior pages. The wizard art should be based on a symbol design that reflects the purpose or function of a particular wizard. For example, a wizard dealing with printers or printing might have a printer for the basis of its symbol design.

Also, wizard art should reinforce individual product branding through the use of color. Color appears in the watermark graphic on Welcome and Completion pages (see Figure 1a), and as the background color in the header graphic on Interior pages (see Figure 2).

Development Note The new Wizard 97 common control code automatically places a white fill (mapped to windows color) covering both the Welcome and Completion pages and the header sections in the Interior pages. The wizard bitmap art described in this section is placed on top of these fills.


Welcome and Completion Page Art

The wizard art relies on a symbol design to convey a specific message. This can be accomplished in two ways. In the first method, the primary symbol image is used twice: within the square bounding box and again in the watermark background behind the square (see Figure 1a). The second method employs two different symbol images to convey a specific message, and gives the user a better visual representation of purpose of the wizard. In Figure 1b, for example, the plus sign image in the square illustrates the action of 'add', and the watermark background image illustrates the main subject, a printer. The specified measurements for the overall wizard art area are larger than the area depicted in Figure 1b to allow for optimum display when the wizard is viewed in large fonts mode.

Figure 1a Wizard art for Welcome page or Completion page: employing a single symbol image

Figure 1b Wizard art for Welcome page and Completion page: employing two symbol images


Interior Page Art

The same interior page header graphic should appear on all interior wizard header sections in the right-hand corner.

Figure 2 Interior page design


General Layout for Wizard Pages

General page layout guidelines for wizard pages in dialog units are found in Figures 3 and 4.

Development Note The dialog units were calculated with MS Sans Serif 8 pt. as the system default with the computer set to display small fonts.


Font Sizes and Styles

For the Welcome and Completion pages, use Verdana Bold 12 point for the "Welcome to the Sample Wizard" or "Completing the Sample Wizard" text. Use MS Shell Dialog font for all page descriptive text. For the interior pages, use MS Sans Bold for the title in the header section and MS Shell Dialog for the subtitle. For the text in the body of the page, use MS Shell Dialog. In general, do not bold text in the body of wizard pages.

Development Note In the Welcome and Completion pages, the title font name and size, Verdana Bold 12 point, should be loaded from the resource file thus allowing localizers the ability to change it. If the wizard being designed is a system component, development should specify the font name as "MS Shell Dlg." This will allow a system to re-map the font if necessary.


Welcome and Completion Page Layout

Use the dialog unit (dlu) measurements indicated by the outer dashed line (dlus: 317w x 193h) when building a wizard using the Wizard 97 common controls (see Figure 3). The controls automatically add 14 dlus to the right-hand side. Shown in the figure are the measurements for text box X and Y coordinates.

Figure 3 Welcome or Completion page in dialog units (dlus)


Interior Page Layout

Use the outer measurements indicated by the dashed line (dlus: 317w x 143h) when building a wizard using the Wizard 97 common controls (see Figure 4). The controls automatically add 7 dlus on all four sides.

Development Note The common controls for Wizard97 automatically create the header sections of the interior wizard pages. Please refer to comctl32.dll, file version 5.00, product version 5.0.1011.2000, that comes with IE 5 or NT 5.

Figure 4 Interior page layout in dialog units (dlus)


Margins and Indents

Margins in Welcome and Completion pages should follow the specifications given in Figure 3. In the interior wizard pages, the margins and indents can vary depending on the content of the page, as shown in Figures 5 and 6 that follow.


Wide Margins

Only use the outer margin when the page contains particularly wide content, such as side by side list boxes. For layout measurements see Figure 4.

Figure 5 Use of outer margin in wizard page body


Indenting for Clarity

As a rule, indenting beyond the normal margins is not necessary. However, indenting can be used to visually separate similar groups of objects on a page, such as when there are more than two items on the page. Indenting is done in increments of 10 dlus.

Figure 6 Indenting for clarity


Paragraph Spacing

There should be 7 dialog units (dlus) between paragraphs.

To calculate the vertical distance between paragraphs:

  1. Start with the vertical dialog unit coordinate of the top left corner of the first paragraph text box.
  2. To this number, add 8 dlus for each line of text in that paragraph.
  3. Next add 7 dlus for the space between paragraphs.
  4. This will give you the vertical location for the text box for the second paragraph.

Figure 7 Correct paragraph spacing


Spacing of Controls with Text

Figures 8a, 8b, and 8c show recommendations for the vertical layout and spacing of edit boxes, list boxes, and radio buttons in relation to lines of text. The measurements noted in these figures show either vertical or horizontal placement of text and controls, as measured in dialog units.

Figure 8a Relation of stacked edit boxes and text

Figure 8b Relation of text, list boxes, and edit boxes

Figure 8c Relation of text and radio buttons


Welcome Pages: Appropriate Usage

Figures 9a, 9b and 9c show Welcome page designs that introduce the user to the task of a wizard and supply the user with any other pertinent information necessary for completing the task.

The Welcome page design in Figure 9a illustrates that:

  1. The name of the wizard should always appear in the title bar.
  2. "Welcome to the Sample Wizard" should always appear as the title with the page.
  3. The task of the wizard may be stated.
  4. General pertinent information may be stated.
  5. "To continue, click Next." may be stated.

Figure 9a Welcome page design

The Welcome page design in Figure 9b illustrates that:

  1. The name of the wizard should always appear in the title bar.
  2. "Welcome to the Sample Wizard" should always appear as the title within the page.
  3. The task of the wizard may be presented as a detailed list. Bullet points can be used for clarification. (Small bullet points can be created using the letter 'h' in the Marlett font.)
  4. Important information for successful wizard completion may be stated. The yellow alert icon may be added for emphasis.
  5. "To continue, click Next." may be stated.

Figure 9b Welcome page design

The Welcome page design in Figure 9c illustrates that:

  1. The name of the wizard should always appear in the title bar.
  2. "Welcome to the Sample Wizard" should always appear as the title within the page.
  3. The task of the wizard may be stated.
  4. "To continue, click Next." may be stated.
  5. The option may be given to forego the presentation of the Welcome page in the future, if appropriate. This option can be implemented by the use of the check box and text shown in Figure 9c. However, only use such an option for wizards that users access for administrative-type tasks on a very frequent basis.

Figure 9c Welcome page design


Completion Pages: Appropriate Usage

The Completion page reinforces that the user has successfully completed all the steps of the wizard. It can also provide further closure of the wizard task by summarizing what was accomplished and, in certain cases, by stating what should be done next. Figures 10a, 10b, and 10d illustrate various Completion pages, and Figure 10c illustrates a related page.

The Completion page design in Figure 10a illustrates that:

  1. The name of the wizard should always appear in the title bar.
  2. "Completing the Sample Wizard" should always appear as the title with the page.
  3. That the wizard has been successfully completed may be stated.
  4. A brief list may be presented of either the tasks the user completed while in the wizard or the tasks the user will complete upon clicking Finish and closing the wizard. If a longer list is needed than what is shown in Figure 10a, place it in a scrolling list box. However, since the space available is limited, reserve the Completion page for a wizard closure that is as simple as possible. Crowding the Completion page, or any wizard page, with text allows no space for localization in certain foreign languages (see "Localization" section 8.) Therefore, when longer lists or list boxes are necessary for summation put them on a regular wizard page previous to the Completion page.
  5. "To close this wizard, click Finish" should be stated when tasks have been completed while in the wizard.

Figure 10a Completion page design

The Completion page design in Figure 10b illustrates that:

  1. The name of the wizard should always appear in the title bar.
  2. "Completing the Sample Wizard" should always appear as the title within the page.
  3. That the wizard has been successfully completed may be stated.
  4. When important, any necessary details of how any process started in the wizard might be completed may be given. The yellow alert icon may be added for emphasis. In this example, after a user clicks Finish and the wizard closes, a standard progress dialog with a progress bar can appear and remain on the screen until the process is completed. However, the user interface described in the following examples (see Figures 10c and 10d) is preferable for any process lasting for more than a few minutes.
  5. State that in addition to the wizard closing, another action will take place when a user clicks Finish.

Figure 10b Completion page design

Figure 10c is an example of a page that can directly precede the wizard Completion page. It gives the user enhanced feedback on the final task that will take place as a result of the wizard — without having to exit the wizard first. Once the process is completed, the regular wizard Completion page can follow to provide closure to the entire wizard task (see Figure 10d).

Figure 10c Summary page prior to Completion page

The Completion page design in Figure 10d illustrates that:

  1. The name of the wizard should always appear in the title bar.
  2. "Completing the Sample Wizard" should always appear as the title with the page.
  3. That the wizard has been successfully completed may be stated.
  4. "To close this wizard, click Finish" should be stated when tasks have been completed while in the wizard.

Figure 10d Completion page design


Interior Pages: Scenarios

The following figures (see Figures 11a, 11b and 12) illustrate some common user interface issues particular to wizard design. However, most interior page wizard designs follow common Win32 user interface design style guidelines.


Displaying Secondary Windows

Inexperienced users are often confused by the addition of secondary windows. They are confused when, as in Figure 11a, they have already clicked Next expecting to proceed to the following page and instead the first page remains with a secondary dialog on top. Therefore, it is recommended that the content of the secondary dialog be placed in a following wizard page, as in Figure 11b.

Figure 11a INCORRECT use of secondary dialog

Figure 11b Secondary dialog correctly incorporated as a wizard page (RECOMMENDED)


Using Alert Icons

In order to draw special attention to very important information, either the information bubble symbol or yellow warning symbol can be added before text.

Figure 12 illustrates that:

  1. The information bubble icon can emphasize important yet not crucial information.
  2. The yellow warning icon can emphasize information vital to either the success of the task or the consequences of the actions performed on the wizard page.

Figure 12 Alert icons


"More Information" and Context-Sensitive Help in Wizard97

More Information

Wizard pages should be designed so that they are easy to understand. Having a normal Help button that brings up an additional rich interface, the Help interface, may confuse users by taking them out of one relatively complex interface into another. Inexperienced users can lose their context. Therefore, where it is necessary to explain difficult concepts, place a single button with the title "More Information" on the left hand side in the BODY of a given wizard page, NOT in the control area at the bottom of the wizard (see Figure 13a). This button should bring up a simple dialog that displays the necessary information in a list box (see Figure 13b).

In the examples below, the More Information button in Figure 13a will provide additional information about the topic of the particular wizard page. That information is presented in a simple dialog (see Figure 13b).

Figure 13a More Information button

Figure 13b More Information dialog

Context-Sensitive Help

The What's this (?) button should only appear on the wizard in the title bar if the wizard supports context-sensitive Help for all of the controls. If context-sensitive Help only exists for the Back, Next, and Cancel buttons, the Help cursor should NOT appear.


Welcome Page Text

Welcome page text begins with "Welcome to the Sample Wizard", and then gives a comprehensive explanation of the wizard's purpose. It can begin by stating, "This wizard helps you to…" (Example: "This wizard helps you to create a new user account on this computer."). When appropriate, a list of the tasks performed by the wizard can be included. For examples of Welcome page text, see Figures 9a-c.


Interior Pages Header Section Text

This text includes a short title for the page that defines the subject or task of that particular page followed by a subtitle giving a one-sentence description of the task to be performed by the page. Examples of titles and subtitles are given below.

Development Note The title font name and size should be loaded from the resource file thus allowing localizers the ability to change it. If the wizard being designed is a system component, development should specify the font name as "MS Shell Dlg". This will allow system to remap the font if necessary.

Figure 14 Title and subtitle in the header section of an interior wizard page

The subtitle can be written in several ways: as a question, as a description, or as a description in the second person singular (You).

Title and Subtitle Examples

  1. Subtitle as a question:

    Computer Operating System (title)

    Is the computer's operating system set up to operate with Small Business Server? (subtitle)

  2. Subtitle as a description of the purpose of the particular page:

    Computer Operating System Installation (title)

    Installation files will be copied to your hard drive. (subtitle)

  3. Subtitle as a description in the second person singular:

    Sounds (title)

    You can choose a sound scheme and then preview its different sound events. (subtitle)

Additional Title and Subtitle Examples

  • Signing Options (title)

    The type of signing will determine the options you can specify for the signing operation. (subtitle)

    (Then below in the body, it says, "Choose a signing type.")

  • Hash Algorithm (title)

    Hash algorithms are techniques that compute a condensed representation of a data file. (subtitle)

    (Then below in the body, it says, "Select an algorithm from the list.")

  • Data Timestamp (title)

    Time stamping guarantees to others that the data existed on a certain date. (subtitle)

    (Then below in the body, it says, "Set the timestamp below.")


Completion Page Text

Completion page text begins with "Completing the Sample Wizard" and also "You have successfully …(done such and such)." In some wizards it might be appropriate to actually list the tasks the user completed or things the user should do after exiting the wizard. For examples of Completion page text, see Figures 10 a, 10b, and 10d.


Accessibility Issues

Listed below are two important accessibility documents containing guidelines for user interface design:

  • The Designed for Microsoft Windows NT and Windows 95 Logo Program
  • The Microsoft Windows Guidelines for Accessible Software Design


Topic Not Found

No matching topic was found. Some possible reasons and remedies are as follows:

  • The file (.chm) that contains the destination topic is not in the expected location.

    Remedy: Rerun the MSDN Library Setup.

  • The file (.chm) that contains the current topic or destination topic is out-of-date and the link is no longer valid.

    Remedy: Install the latest version of the MSDN Library.

  • The MSDN Library CD is not in the CD-ROM drive.

    Remedy: Insert the MSDN Library CD into the CD-ROM drive.