Fundamentals of Designing User Interaction - Getting Started
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.
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.
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 http://msdn.microsoft.com/ui/guide/sdk.asp and the Windows Logo Program at http://msdn.microsoft.com/winlogo/.
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 http://msdn.microsoft.com/ui/guide/ishellLink.asp.
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.
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 http://msdn.microsoft.com/ui/guide/install.asp. For more information about designing your uninstall process, see Chapter 11, "Integrating with the 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 http://msdn.microsoft.com/ui/guide/shellfolder.asp.
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.
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.
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.
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.
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 DEL eted. 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:
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 DEL eted 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.
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.
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 (click to enlarge image)
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 (click to enlarge image)
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.
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:
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 (click to enlarge image)
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
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
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.
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 (click to enlarge image)
The best strategy is to avoid messages whenever possible. There are several ways you can do this:
Figure 1.7 A balloon-style ToolTip (click to enlarge image)
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.
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.
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.
More Information
For more information about supporting international users, see Chapter 15, "Special Design Considerations."
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.
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.
More Information
For more information about controls and when and how to use them, see Chapter 8, "Menus, Controls, and Toolbars."
You can improve the usability of your application's secondary windows by observing the following general guidelines:
More Information
For more information about secondary window design, see Chapter 9, "Secondary Windows" and Chapter 14, "Visual Design."
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.
More Information
For more information about supporting accessibility, see Chapter 15, "Special Design Considerations."
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 the WM_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.
More Information
For more information about icon design, see Chapter 14, "Visual Design."
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 (click to enlarge image)
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 (click to enlarge image)
The best way to determine whether your application supports multiple monitor configurations appropriately is to test your software with this scenario.
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.
More Information
For more information about the WM_INPUTLANGCHANGEREQUEST event, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/sdk.asp.
Fundamentals of Designing User Interaction
Design Specifications and Guidelines