Microsoft Windows User Experience (Microsoft Professional Edition)

Microsoft Windows User Experience (Microsoft Professional Edition)

by Microsoft Corporation, Microsoft Corporation Staff

Targeted for professional developers, this book delivers a print version of official Microsoft guidelines for creating well-designed, visually and functionally consistent Windows user interfaces. Includes a new section that addresses common development missteps and offers ready solutions.


Targeted for professional developers, this book delivers a print version of official Microsoft guidelines for creating well-designed, visually and functionally consistent Windows user interfaces. Includes a new section that addresses common development missteps and offers ready solutions.

Editorial Reviews

This revised edition of presents the official Microsoft guidelines for designing visually and functionally consistent user interfaces for applications that run on the Windows family of operating systems, including Windows 2000. Annotation c. Book News, Inc., Portland, OR (

Product Details

Microsoft Press
Publication date:
Microsoft Professional Editions Series
Product dimensions:
7.35(w) x 9.00(h) x 1.59(d)

Related Subjects

Read an Excerpt

Chapter 1.
Getting Started

  • Chapter 1: Getting Started
      • What’s New
      • The Importance of a Well-Designed Interface
      • The Need for Improved Simplicity
      • Key Areas for Improvement
      • Checklist for a Good Interface

Chapter 1: Getting Started

This chapter includes an overview of the new features and controls provided by Microsoft Windows. It also includes a summary of the key design issues for applications written for the Windows interface.

What’s New

This book includes information about designing user interfaces for applications that run on Microsoft Windows 98 and Microsoft Windows 2000. It also describes the new interfaces and conventions used in these operating systems. These features include the following:

  • New input conventions
    Automatic (hover) selection, wheel mouse button actions — See Chapter 5, "Input Basics," and Chapter 6, "General Interaction Techniques."
  • New controls
    Date picker, HTML control, toolbar frames —
    See Chapter 8, "Menus, Controls, and Toolbars."
  • New file common dialog boxes
    File Open, File Save As, File Print, and Browse for File — See Chapter 9, "Secondary Windows."
  • New Help support
    HTML Help, balloon tips, InfoTips, simple wizards —
    See Chapter 13, "User Assistance."
  • New folder conventions
    My Documents, My Pictures, thumbnails, Web views, Active Desktop — See Chapter 11, "Integrating with the System."
  • New system integration support and utilities
    Multiple file association support, NoOpen file registration, operating system-protected files, Quick Launch toolbar, multiple monitor support, Disk Cleanup, Windows Installer — See Chapter 11, "Integrating with the System."

If you are designing an application to run on a previous version of Windows, a Windows Service Pack may be available. The Service Pack enables you to upgrade the system code to include some of these new features.

This book also includes information about the evolution of application design and the impact of the Internet on conventional application design. While this book does not explicitly include Web page design guidelines, it does include recommendations about Web-style applications.

The Importance of a Well-Designed Interface

The usability of your application’s design is not just a philosophical nicety for your consideration; it is essential to the success of your application. The investment you make in the design of your application contributes not only to supporting and keeping your existing customers, but also to expanding your customer base. Therefore, your investment in the design of your application directly affects your current and future bottom line.

If you design or develop software for the Windows platform, you are part of an industry that is creating some of the most exciting and innovative applications available. More applications and more types of applications are being written for the Windows platform than for any other environment. In addition, increased support for accessibility and localization of applications means that applications are reaching a larger audience. New hardware initiatives and innovative technologies are making computers better for end users. The wide use of features such as common dialog boxes and controls has increased consistency between applications. In short, application developers for Windows are doing a great job of promoting the growth and use of computers everywhere.

The Need for Improved Simplicity

Despite the popular support for Windows, there are still substantial challenges in providing the best experience for users. Computers are still too complicated to use, and support costs are high. Users frequently complain about the number of features they find in applications; they can’t find the features they care about, and they can’t figure out the features they do find.

Many users expect a computer to be as easy to use, and as predictable and reliable, as an appliance. They want a computer to work in a way that is familiar to them. Therefore, simplicity of design involves issues that must be addressed by everyone building applications for Windows.

Delivering simplicity does not mean just removing functions. It requires work. Even a simple interface can require a significant investment of code. However, the rewards and benefits are substantial, including reduced training and support costs and productive, loyal customers.

Key Areas for Improvement

This book offers many recommendations for designing Windows-based applications. The most common design issues are summarized below. You can find more detail throughout the following chapters.

Confusing or Awkward Setup and Uninstall Design

Often, how users will install an application is not addressed until near the end of the development process. Yet because this is the first interface that users see, it is one of the most crucial elements of your application’s design.

Complex, Cluttered Setup

Setup programs often have too many steps, requiring the user to click too many times. You can simplify your setup design by including typical and custom installation options. Use the typical installation option to provide a smooth, easy setup that doesn’t overwhelm the user with options, and include default settings that give the user a reasonable configuration. For example, don’t require that the user supply the target folder. Instead, you can display the recommended subfolder in the system’s Program Files folder as the default. Whenever possible, reduce the number of mouse clicks and pages of options, especially for the typical installation.

Bad setup design is also often characterized by the three "R’s": reboots, Readme files, and random windows. Unless it is absolutely necessary, avoid requiring the user to restart the computer. Restarting is not only inconvenient for users, it could cause them to lose data because they didn’t save changes to open files. To avoid the need to restart, the installation program should detect whether the currently running dynamic link libraries (.dll) or executable (.exe) files are to be replaced and give the user the opportunity to close any applications that might be affected.

Programs that update system components typically require that the computer be restarted. Generally, this is a bad practice that can make the system unstable and confuse the users. To minimize the need for restarting the computer, avoid modifying core system components or installing files in the Windows System (or System32) folder. For more information, see the Microsoft Platform SDK on the MSDN Online Web site at and the Windows Logo Program at

Whenever possible, avoid including unnecessary information in a Readme file. Plan your application’s design far enough ahead so that users do not need to be aware of too many special circumstances.

Do not include technical support information on the Start menu. This just adds clutter and makes it harder for users to access their applications. Similarly, don’t include technical support information as an option in your setup program. Instead, add an entry to your Help menu that accesses this information, or just leave the file in your application’s folder.

Finally, avoid displaying unnecessary message windows while the user is installing and setting up your application. Consolidate progress messages as much as possible, and use the IShellLink system interface to create your Start menu entries, not the outdated DDE mechanism. For more information about the IShellLink interface, see the MSDN Online Web site at

Awkward First Experience

Users’ overall success with an application can be influenced heavily by their initial experience. A first impression is a critical moment in which to gain a user’s trust and confidence. After an application is installed, the user should be able to use it productively within the first five minutes.

Keep in mind that users will often want to use your application immediately after it has been installed. As part of your setup program, include an option to automatically start the application. In addition, let the user know how to start your application in the future by illustrating or referring to your application’s Start menu entry.

You can help users be productive by promoting your application’s key features and functions. A guided feature tour is helpful, but it is often not enough just to highlight your program’s capabilities. You might want to include an initial screen that displays key features and functions and shows how to use them.

At the same time, avoid overwhelming users with all the features in your application. Instead, consider exposing features gradually through contextual tips or some form of intelligent help that tracks the user’s experience.

Remember that your users’ initial experience is not limited to the first five minutes with your product. Your users will have an initial experience every time they use a new feature, so consider the first use of each aspect of your product’s design.

Incomplete or Missing Uninstall Option

Your installation design should also include an option to uninstall your application. The uninstall process is frequently neglected in application design, as evidenced by the fact that the most popular tools for Windows are uninstall utilities. But you need to do more than just support the uninstall process. Users often complain about uninstall programs that require them to re-insert the CD, that do not uninstall completely, or that cannot recover from a failed uninstall.

Make sure that you test your uninstall process in a variety of ways. Test it with previous versions of your application and in circumstances where the uninstall process failed before it finished. This could be because of a power failure or because the user tried to end the process without canceling it first. When this happens, the process can leave behind extra files that clutter the user’s system, and even more importantly, the user may not be able to re-install the application.

The Windows Installer technology can help you provide well-designed install and uninstall processes. It is available in Windows 2000 and on other platforms through a redistributable operating system component. Use the Windows Installer to make your application resilient and to allow for easy distribution through the Windows 2000 Active Directory. The Windows Installer supports features such as self-repair and Install on Demand, and it is integrated with the Windows Control Panel. For more information about the Windows Installer, see the Microsoft Windows Web site at For more information about designing your uninstall process, see Chapter 11, "Integrating with the System."

Improper Use of the File System

A typical user’s hard disk is a mess. Applications often scatter files all over the folder structure, making it hard for users to find their files. This also makes it difficult for users to back up files, roam from computer to computer, and replace a computer or move to a new one. Worse, when application files have cryptic names, users don’t know what the files are for.

Windows provides several folders that can help you avoid these situations as described below. Do not hard code the names or paths for these folders into your application. Instead, you can use Shfolder.dll to help you identify the appropriate locations for storing files in the file system. For more information about these standard folders, see the following sections and Chapter 11, "Integrating with the System." For information about Shfolder.dll, see the MSDN Online Web site at

Missing Support for "My Documents"

Use the My Documents folder as the default location for storing documents that the user creates. The My Pictures subfolder provides a location for storing image files. You can create your own subfolders for storing specialized groups of documents, such as the files included in a programming project.

There are several benefits to supporting the My Documents folder. Because this folder is a system default, users can open your documents more quickly from the desktop and by using the File Open command. The system supports storing files on a per-user basis, and therefore also supports user roaming scenarios under Windows 2000. Support for My Documents is especially important for users in large organizations whose IT departments manage user documents.

However, do not hard code the path for the My Documents folder, such as "C:\My Documents," in your application, because the name of this folder may be localized for some language versions of Windows, and its location may vary. Instead, use the system interface (Shfolder.dll) to properly locate this folder.

Improper Placement of Program Files

Avoid installing application files at the root of the user’s hard disk. This clutters the hard disk and confuses the user. Instead, create a single folder in the Program Files folder to contain your application files. Store read-only files — such as executable (.exe) files, dynamic-link libraries (.dll files), and Help files — in this folder. The Program Files folder should also include read-only data files, such as clip art, samples, and libraries. Do not place any per-user files in this folder; include only files that your application and uninstall utilities can modify or remove. Store any shared components in the Program Files\Common Files subfolder.

Missing Support for Application Data

For files that don’t meet the My Documents or Program Files criteria, create a folder within the Application Data folder and name it using your application’s name. For example, use this location to store modifiable application support files such as custom dictionaries, log files, user history, or e-mail stores.

If the files are discardable (such as cached data or temporary files) or do not need to roam with the user from computer to computer, store them in the Application Data\Local Settings subfolder. Files stored in this location are typically data files that the user implicitly generates. There is also an Application Data folder in the All Users folder. Use this folder to store only local dynamic data files — such as log files, hidden databases, or index files — that are not user-specific.

Scattered Temporary Storage

Many applications, including some of those provided by Windows, include their own caches for temporary files. This organization requires the user to purge several different caches to recover this disk space. The Disk Cleanup utility included in Windows provides a simple interface where users can easily manage disk caches. Make sure that any discardable files your application stores can be managed from this utility.

Cryptic File Names

When users encounter files they didn’t create that have meaningless or indecipherable names, they have no way of knowing which application they belong to or whether the files are to be backed up or deleted. This is also true for files that have no registered type.

You can improve this situation in a number of ways. Avoid cryptic file names, especially those that include obscure abbreviations. Support for long file names in Windows enables you to define comprehensible names for the files and folders that users see. Similarly, use appropriate capitalization in file and folder names for a consistent, recognizable appearance. For example, acronyms such as "MS-DOS" should appear in all caps. If you need to localize your file names, you can use registry entries to map file names to your localized folders or file names.

Whenever possible, use existing data types. When you create a new type, the user should be able to identify the type with your application. For every new file type your application installs, do the following, even if files of this type cannot be edited:

  • Register the file type.
  • Register a user-friendly type description.
  • Register an icon.

If the user can open or edit a particular file type, register your application to automatically handle the file type. However, if the file type is not unique to your application, ask the user before you reassociate the file type and provide a way for the user to return the file type to its previous association. For more information about registering your file types, see Chapter 11, "Integrating with the System."

Finally, hiding files that the user does not need to edit better ensures that the files won’t accidentally be deleted or moved. If you mark a file as both hidden and system, the file will not be displayed at all in Windows 2000. Hidden system files are accessible only directly from the Address bar or command line and are called "protected." While this is a good way to clean up a potentially cluttered folder, use it with care because users will be unable to see or modify such files.

GUI Overload

Remember that the computer screen is the main work area for user tasks, not a place to advertise or compete for the user’s attention. When applications inappropriately use standard Windows graphical user interface (GUI) elements such as the Start menu, desktop, or taskbar, it can become confusing to the user, reducing not only user satisfaction, but also productivity.

Start Menu Abuse

The most common design error is how an application is installed on the Start menu. Too many entries and too many cascading submenus on the Start menu add complexity and reduce user access. Place only entries that a user needs to access frequently on the Start menu. As a general rule, limit your application’s entry to a single item.

For suites or sets of applications that are used together, include an entry for each significant application on the Programs submenu. If you want to provide access to secondary utilities, include a separate group entry. In any case, do not include entries for Help, Readme, and Uninstall.

Finally, avoid installing any entries at the very top (first) level of the Start menu. Users expect to find only primary system commands here, as shown in Figure 1.1.

Figure 1.1 Good Start menu usage (Image Unavailable)

Adding to this level of the Start menu reduces the user’s focus and hampers the user’s ability to find key functions, as shown in Figure 1.2.

Figure 1.2 Bad Start menu usage (Image Unavailable)

Desktop Icon Abuse

Like the Start menu, the desktop is another area where less is more. With the exception of icons that represent access to general information services, such as e-mail, Internet browsers, or online services, avoid creating any icons on the desktop. The Windows desktop provides a general work area and storage location for the user. Usability tests consistently demonstrate that users consider the desktop their space and react negatively to icons appearing there automatically. Furthermore, the Start menu is a better location from which to support quick access.

If it’s important to give users desktop access to your application’s icon, give them the choice by including an option in your application’s interface rather than by pre-installing the icon. For example, you could offer to create a shortcut on the desktop in response to a user action, such as creating a dial-up connection. This makes the availability of the icon the user’s choice, provides a useful service, and does not leave the desktop cluttered.

Start-up Overload

When a user starts Windows, multiple banners or windows should not compete for attention like a six-car pileup. Even if the information is important, its value may be lost if it is presented in a disorganized way, as shown in Figure 1.3. Whenever possible, follow these guidelines:

  • Avoid displaying a dialog box when the system starts.
  • Integrate configuration options into your setup design.
  • Wait until your application has been started before displaying introductory product information.

If your application needs to open a dialog box when it starts, consider using the support in Windows 2000 that puts your dialog box into a queue, so that dialog boxes are displayed one at a time.

Design your application with these points in mind to improve the user interface and decrease support calls.

Figure 1.3 Bad start-up experience (Image Unavailable)

Status Notification Area Abuse

Another common mistake is using the taskbar status notification area inappropriately, as shown in Figure 1.4. The Windows taskbar notification area is intended only for quick, short-term notification (for example, a document is printing) or status information for some ongoing process or event (for example, a low battery warning). A taskbar icon should persist only if it is important for a user to have it available, such as for a dial-up connection. This helps ensure that the user will notice changes in the notification area.

Figure 1.4 Bad use of status notification area (Image Unavailable)

Avoid placing automatically included icons in the notification area just to give users quick access to configuration information. If you want to provide this type of support, include an option in your application’s interface so that users can display this icon if they choose. Set the default to off.

Windows also includes a special area on the taskbar called the Quick Launch toolbar, shown in Figure 1.5.

Figure 1.5 Quick Launch toolbar (Image Unavailable)

This area provides one-click access to icons that the user chooses to put there and to basic tasks, such as e-mail, and basic locations, such as the Web and the desktop. Therefore, do not install your application here unless it is intended to replace a system-provided function, such as e-mail.

Poor Message Design

Messages are one of the most consistent areas of interface abuse. Users often find messages annoying. They disrupt task flow and are often worded poorly so that at best, they are not very helpful, and at worst, they are incomprehensible and condescending, as shown in Figure 1.6.

Figure 1.6 Poor message design (Image Unavailable)

The best strategy is to avoid messages whenever possible. There are several ways you can do this:

  • Disable commands or options when unavailable.
  • Handle any input and fail gracefully, when necessary.
  • Provide other less intrusive forms of feedback, such as the new balloon-style ToolTips, shown in Figure 1.7.

Figure 1.7 A balloon-style ToolTip (Image Unavailable)

When you must write message text, make sure you use non-technical language as much as possible, avoid blaming the user, and provide a clear course of action to resolve a problem.

Missed Opportunities

Many developers of Windows-based applications unintentionally limit their potential audience by overlooking user scenarios that vary from their own. However, it often takes only a little extra effort to support the widest range of users. Time invested here can pay dividends in the form of increasing your application’s potential market or meeting governmental requirements. It also provides consistency of operation for all your users.

Overlooking the System Locale

The advent of the Internet makes it possible to quickly and easily distribute software globally. Yet the impact of an application’s design on an international audience is often overlooked.

Even if you don’t intend to localize your application into other languages, you must carefully consider how your application will operate on configurations set up for other languages. For example, always use the system functions that check for the names and locations of Windows standard folders, such as Program Files and My Documents, because these can differ on other language versions of the operating system. If you assume a specific folder location or name, your application can fail.

If you do plan to localize your application, you will need to consider all elements that are visible and relevant to the user. For example, in double-byte languages such as Japanese, Chinese, and Korean, access-key assignments are formatted differently. Instead of an underlined character in the text label, you include the character in parentheses.

To support multiple languages, create a single worldwide binary with separate language components (.dll files). Your binary should include U.S. English resources that will run on any language system, but it must be designed so that your interface can be changed dynamically.

Remember that localizing the text involves more than translating the words. You should query for and design to accommodate the default interface font. System font metrics such as font name and size can vary widely for different languages and can affect the positioning and spacing of text.

Lack of Adequate Keyboard Support

Keyboard support provides efficiency for many users, but for those with sight impairments or repetitive-stress injuries, it is essential. Keyboard support means including keyboard access to all of your application’s functions. It takes only a little time to confirm that your application’s interface provides a logical tab navigation order.

Complex Secondary Window Design

Your attention to detail most often shows up in the design and layout of controls in property sheets, dialog boxes, and other secondary windows. Because users encounter secondary windows so frequently in the interface, a window that does not follow familiar conventions can disrupt readability and task flow, as users must stop and deal with the inconsistency.

You can improve the usability of your application’s secondary windows by observing the following general guidelines:

  • Use the appropriate control. Controls are typically optimized for certain types of functions. The wrong control not only affects the user’s efficiency, but also confuses the user about the purpose of your design.
  • Use recommended layout conventions. For example, buttons such as OK and Cancel or Yes and No should be aligned either at the top right or bottom right of the dialog box. (In right-to-left versions of Windows, this alignment can be reversed.) OK is always the first button, followed by Cancel, and then any other buttons. If you don’t have an OK button, then Cancel follows all the other buttons. Because OK and Cancel are generally mapped to the enter and esc keys respectively, access key assignments are unnecessary.
  • Use appropriate labeling. Always use the appropriate capitalization and access key assignments. Include colons when you use static text to label another control. This not only identifies the text as a label, but also provides a cue for screen-reader utilities.
  • Use appropriate alignment. Alignment affects readability and therefore usability and efficiency. It also affects the user’s overall impression of the quality of your application. For example, make sure you align the baselines of text labels for text boxes.
  • Use appropriate sizing, spacing, and margins. For example, the recommended spacing between controls is seven dialog units (DLUs). The recommended size for buttons is 50 x 14 DLUs, except where a button must be larger to accommodate its text label. Also make good use of your overall space. The guidelines in this book are for the minimum space recommendations. Avoid cramming too many controls together if you have additional space.

Lack of Support for User Color and Font Preferences

Windows provides standard font and color settings that users can set to match their preferences. Support for these preferences is important for user satisfaction and also ensures readability and accessibility for users who require high contrast to read the screen.

Wherever possible, use the system settings for fonts, especially for menus, icons, and window title bars. Since your application does not operate in isolation, use the system color settings as well. If you do want to vary colors, consider using colors similar to the user’s settings.

In any case, make sure that your application responds appropriately to the High Contrast system flag and to the WM_SETTINGCHANGE event.

Misuse of Color

Applications often fail to adapt to the color depth settings of the user’s display. This can result in palette "flashes" in your application. To avoid this, use the standard halftone color palette when the display is set to 8-bit color. Also be sure to adjust your color usage appropriately to receive theWM_DISPLAYCHANGE event.

Icons are an important design element to consider with regard to color and resolution changes. Guidelines for icon design include color and size conventions for your application and all of its file types.

Neglecting Multiple Monitor Support

The latest versions of Windows enable the user to display windows across multiple monitors. If your application overlooks this user scenario, secondary windows can appear on the wrong monitor when the user moves your application’s primary window to a secondary monitor, as shown in Figure 1.8.

Figure 1.8 The wrong place for a secondary window (Image Unavailable)

To properly support multiple monitors, make sure your application can handle an arbitrarily large coordinate space. Unless a user explicitly moves a secondary window to another monitor, display the secondary window on top of its primary window, as shown in Figure 1.9.

Figure 1.9 The correct place for a secondary window (Image Unavailable)

The best way to determine whether your application supports multiple monitor configurations appropriately is to test your software with this scenario.

Missing Support for Character Sets

To further address the global market for your application, ensure that your application can deal with input and output for different character sets. This is not hard to do, and it is well worth the effort. Windows provides functions to help you. For example, if you use the rich text box control for input and output of text, it automatically handles and preserves text based on the current character set and code-page settings. Similarly, the Fonts common dialog box ensures that the user has access to the appropriate set of fonts. Finally, make sure that your application can respond appropriately to keyboard language changes using the WM_INPUTLANGCHANGEREQUEST event.

For more information about the WM_INPUTLANG-CHANGEREQUEST event, see the Microsoft Platform SDK on the MSDN Online Web site at

Checklist for a Good Interface

The following checklist summarizes the information in the previous section and in this book. Use it to help you confirm that your application is designed to provide the best user experience:

  • Your application installs easily in a minimum number of steps.
  • Your application installation does not require the system to restart.
  • Users do not have to read a Readme file before using your application.
  • User-generated data files are stored by default in the My Documents folder.
  • Your application avoids cryptic file names that are visible to users.
  • Your application does not create folders outside of the Program Files folder.
  • Your application does not write files to the root of the hard disk.
  • If your application uses a disk cache, it also registers with the Disk Cleanup utility.
  • Your application does not include entries to its Help, Readme, and Uninstall files on the Start menu.
  • Your application does not install icons to the Windows desktop without the user’s permission.
  • If your application is run at startup, it loads without displaying splash screens and dialog boxes.
  • Your application does not use the taskbar notification area for status, for launching applications or utilities, or for querying properties. It uses the notification area only to alert the user of an important change.
  • Your application appropriately applies the color choices the user selected in Display properties in Control Panel.
  • Your application is keyboard accessible.
  • Your application works correctly if the user increases the size of the default font.
  • Your application supports the standard set of keyboard shortcuts, where applicable.
  • Your application’s uninstall process leaves no remaining files or registry entries other than files created by the user.
  • Your application does not use jargon in its user interface text. Use industry-specific or technical terms only if they are clearly understood by the user.
  • Your application adjusts appropriately when the user changes the display resolution as well as for multiple-monitor configurations.

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >