Design Specifications and Guidelines - Integrating with the System

Integrating with the Shell

Windows includes programming interfaces that enable you to integrate and extend the system's operational environment, also known as the shell. Some of these interfaces enable you to add features to the shell and the user interface components it provides. Others enable you to build similar conventions for your own application.

Taskbar Integration

The system provides support for integrating your application's interface with the taskbar. The following sections provide information about some of the capabilities and appropriate guidelines.

Taskbar Window Buttons

When an application creates a primary window, the system automatically adds a taskbar button for that window and removes it when that window closes. For some specialized types of applications that run in the background, a primary window may not be necessary. In such cases, make sure you provide reasonable support for controlling the application using the commands available on the application's icon. This type of application should not include an entry on the taskbar. Similarly, the secondary windows of an application should also not appear as a taskbar button.

The taskbar window buttons support drag-and-drop operations, but not in the conventional way. When the user drags an object over a taskbar window button, the system automatically restores the window. The user can then drop the object in the window.

Quick Launch Toolbar

The taskbar includes a toolbar called the Quick Launch toolbar that enables users to start an application quickly. Unless your application replaces a user system service, such as an Internet browser or e-mail service, do not pre-install an icon for your application on the Quick Launch toolbar. This area is designed primarily for users to customize.

Status Notification

The system allows you to add status or notification information to the taskbar. Because the taskbar is a shared resource, the only kind of information you should add to it is information that is global or that needs monitoring by the user while the user works with other applications. Do not automatically install an icon in the status notification area just to provide convenient access to your application's features or properties. Such convenience icons might be useful for advanced users; however, for typical users, they only add clutter to a potentially already cluttered area of the screen. You can include an option for users to display an icon in the taskbar status notification area, but always configure such an option to be off by default.

More Information

The Shell_NotifyIcon function provides support for adding a status item in the taskbar. For more information about this function, see the Microsoft Platform SDK on the MSDN Online Web site at /library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shell_notifyicon.asp.

Present status notification information in the form of a graphic supplied by your application, as shown in Figure 11.1.

Figure 11.1 Status indicator on the taskbar

When you add a status indicator to the taskbar, also support the following interactions:

• Provide a pop-up window that displays further information or controls for the object represented by the status indicator when the user clicks the primary mouse button. For example, the audio (speaker) status indicator displays a volume control. Use a pop-up window rather than a dialog box to supply further information, because the user should be able to dismiss the window by clicking elsewhere. Position the pop-up window near the status indicator so the user can navigate to it quickly and easily. Avoid displaying other types of secondary windows because they require explicit user interaction to dismiss them. If no information or control applies, do not display anything.
• Display a shortcut menu for the object represented by the status indicator when the user clicks the status indicator by using the secondary mouse button. On this menu, include commands that open property sheets or other windows related to the status indicator. For example, the audio status indicator provides commands that display the audio properties as well as the Volume Control mixer application.
• Carry out the default command defined in the shortcut menu for the status indicator when the user double-clicks.
• Display a ToolTip that indicates what the status indicator represents. For example, this could include the name of the indicator, a value, or both.
• Provide an option so that users can choose not to display the status indicator. This option would preferably appear in the property sheet for the object displaying the status indicator. This allows users to determine which indicator to include in this shared space. You may need to provide an alternate way to convey this status information when users turn off the status indicator.
• Use balloon tips to provide message notifications for your taskbar icon. This can help bring users' attention to the taskbar icon or communicate state changes that users may need to be aware of but that don't require immediate user interaction.

More Information

For more information about balloon tips, see Chapter 8, "Menus, Controls, and Toolbars."

Message Notification

Sometimes your application's window is inactive but the application needs to display a message. Avoid displaying a message box on top of the currently active window and switching the input focus; instead, flash your application's title bar and taskbar window button to notify the users of the pending message. This avoids interfering with the user's current activity but lets the user know a message is waiting. When the user activates your application's window, the application can display a message box.

More Information

The FlashWindow function supports flashing your title bar and taskbar window button. The GetCaretBlinkTime function provides access to the current cursor blink rate setting. For more information about these functions, see the Microsoft Platform SDK on the MSDN Online Web site at /library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shell_notifyicon.asp.

To set your flash rate, use the system setting for the cursor blink rate. This allows users to set the flash rate to a comfortable frequency.

Rather than flashing the button continually, you can flash the window button only a limited number of times (for example, three), then leave the button in the highlighted state, as shown in Figure 11.2. This lets users know there is still a pending message.

Figure 11.2 Flashing a taskbar button to notify a user of a pending message (click to enlarge image)

The taskbar status notification area and balloon tips are alternative ways to alert users about a special condition when your application's window is not active. In the taskbar status notification area, you can create an icon that displays a balloon tip. This is less intrusive than a message box. After the user resolves the condition that required notification, remove the icon and balloon tip.

Control Panel Integration

Windows Control Panel includes special objects that let users configure overall settings or features of their operating environment. Your application can add Control Panel objects or add property pages to the property sheets of existing Control Panel objects.

Adding Control Panel Objects

Before you create an object to be included in Control Panel (also known as a CPL), consider whether the feature and its settings meet the following criteria:

• The settings represent a system component for Windows. It is not appropriate to create a Control Panel object for application-centric settings.
• The settings are user-oriented rather than administrator-oriented. Administrator-oriented features should be implemented as part of the defined policy interfaces.
• The settings are best designed to require manual user interaction. Settings that can be automated should not also appear in Control Panel.
• The settings require high, centralized visibility.
• The settings are pervasive and have significant impact on the user's interaction. For example, the settings for a mouse or keyboard significantly determine how users interact with Windows.
• The settings cannot logically be added as an extension of the existing user interface. Many of the system-supplied CPLs are extensible, allowing you to add extra pages to the existing property sheets. For example, you can extend the Display CPL to support specific settings for a particular graphics adapter. Extending the existing CPLs, instead of adding new ones, results in a simpler experience for users.
• The settings are not intended to provide product support. If your application must expose certain settings to facilitate help desk or product support, include a program in your application's folder or its utilities folder that can be accessed directly.
• The settings provide parameters that users are likely to need or want to change and are not used only to display status information.

More Information

For more information about developing Control Panel objects, see the Microsoft Platform SDK on the MSDN Online Web site at /library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shell_notifyicon.asp.

When you create a Control Panel object, choose a user-friendly name that generically describes its function rather than the name of a technology. Because Control Panel is a system folder, design the icon for your Control Panel object to be consistent with the Windows guidelines. If the icon relates to a product, the icon can be designed to be more representative of the product (for example, a specific type of mouse or keyboard), but keep its name generic, not product-specific.

If your CPL is an object, such as the keyboard or mouse, the name of the icon in Control Panel should be "[object]," and the title of the resulting window should be named "[object] Properties." For a concept, such as the Regional or Accessibility CPL, use the name of the concept and the word "Options," as in "Regional Options," for both the icon and the title of the window. In general, use a single secondary window, typically a property sheet or wizard, to display the settings of your Control Panel object.

Every Control Panel object is a .dll file. To ensure that the file can automatically be loaded by the system, give the file name a .cpl extension and install the file in the Windows System folder.

Recycle Bin Integration

The Recycle Bin provides a repository for deleted files. If your application includes a facility for deleting files, support the Recycle Bin using the system file operation programming interfaces.

More Information

The SHFileOperation function supports deletion using the Recycle Bin interface. For more information about this function, see the Microsoft Platform SDK on the MSDN Online Web site at /library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shell_notifyicon.asp.

Your application can support OLE drag-and-drop transfers into the Recycle Bin. This is done by using the standard drag-and-drop mechanism. Because the Recycle Bin cannot store application data, you should support an Undo command to enable users to restore the data after a drag-and-drop transfer to the Recycle Bin. You can also generate a warning message box in this situation so that users are aware that the data will be deleted permanently.

Creating Active Desktop Items

Windows includes support for users to optionally configure the desktop to display dynamic objects called Active Desktop items. Active Desktop items enable you to deliver content directly to the user without the need for a window. However, creating an Active Desktop item requires special design considerations. For example, Active Desktop items are not visible or accessible to many users, so avoid making this type of item the sole interface to your application or data.

Keep It Simple, Small, and Unobtrusive

Design Active Desktop items to be simple and unobtrusive. Remember that desktop real estate is limited and that the desktop is an active work area for the user. Even if the Active Desktop item is intended to provide continuous updated content, such as a stock ticker or news ticker, limit the size of the update area. This avoids distracting the user and minimizes system performance impact. When an Active Desktop item is obtrusive, the user often removes the item.

Avoid Relying on an Active Connection

An Active Desktop item will often be viewed when the system is not connected to the Internet. Therefore, you may want to support caching the updated content so that users can still browse the information. Also, consider indicating when the content was last updated.

Make It Personal

Whenever possible, enable users to customize the content presented by an Active Desktop item. For example, for a stock ticker or news ticker, users should be able to personalize the item with specific stocks or types of news items.

Creating Folder Web Views

Windows includes support for creating Web views, HTML-authored pages that provide a backdrop for folders. You can use a Web view to create a graphical, interactive view to customize any folder. However, keep your design simple and relatively passive to avoid distracting users.

For example, you can use Web views for corporate branding; that is; add graphical elements that identify your product, as shown in Figure 11.3.

Figure 11.3 Example of a Web view (click to enlarge image)

Use branding only in Web view folders, not in dialog boxes (such as Add/Remove, Search, Printer, Organize Favorites, or Http Errors). Corporate branding uses up valuable screen real estate, especially in smaller formats. Branding graphics could also be replaced by Windows Plus Pack themes, leading to unforeseen problems.

Creating Themes

Windows supports installation and user selection of themes. A theme is a collection of visual and audio system settings designed to enhance the user's experience and help provide a consistent design across the Windows environment. More specifically, a theme consists of the following elements:

• Wallpaper: a visual image for the desktop
• Icons: including at least images for My Computer, My Documents, Network Neighborhood, and Recycle Bin (full and empty)
• Pointers: including the fourteen standard system pointers
• System sounds: including the 20 system sounds (for more information, see "Creating System Sounds" later in this chapter)
• Web views
• Screen saver: one or more
• Palette settings (color settings)
• Display scheme: including fonts, font sizes, icon spacing, system color scheme, and desktop background colors

When you design a theme, consider the following aesthetic and functional guidelines:

• Set all your sounds to the same reasonable volume and make sure they fit together as a collection.
• Use sounds that are pleasant and natural. Select sounds that users will not find irritating or annoying after continued use.
• Consider the impact of multiple-monitor display configuration and password protection for your screen-saver definition.
• Make sure your color scheme provides sufficient contrast, especially so that fonts are readable.
• Avoid designing wallpapers with too much clutter. Keep things simple enough so that screen-saver content and desktop content do not conflict.
• Define pointers with obvious hotspots.
• Include icons for all recommended sizes and color palettes.
• Make sure that there is some level of consistency between the screen saver and the wallpaper.

To support your theme, install all of its elements in a single folder. Define and register a theme file (stored as ASCII text) that includes the path names to all the theme elements.

More Information

For more information about icon design, see Chapter 14, "Visual Design."

Creating System Sounds

In general, Windows system sounds should be subtle to avoid annoying users. Since there is no overall system amplitude control, set the relative amplitude for each sound so that, for example, critical notification sounds are slightly louder than frequently occurring window open and close sounds. Individual sounds should not be normalized. When you design custom system sounds, it is useful to compare new sound amplitudes with the associated default Windows event sound amplitude.

Windows defines the following standard system sound events.

You can also add your own application-defined sound events. For more information, see "Registering Sound Events" later in this chapter.

Format

Sounds must be in .wav file format. They can be 8-bit or 16-bit files, have up to a 44K sample rate, play in mono or stereo, and can be compressed.

The recommended format for sounds is as follows:

• 16-bit
• 22kHz

The sound format you choose to use in your application depends on your target platform. Because sounds can be processed through only one translation before being played, not all sounds are compatible with all hardware. For example, a 16-bit stereo file compressed with ADPCM cannot be played on an 8-bit sound card. If you plan to compress your sound files to save disk space, use 16-bit files with mono sounds. If you do not plan to compress them, then 16-bit stereo sounds will work on most systems.

Many applications are available for creating and editing .wav files, including the Sound Recorder program included with Windows. Although Sound Recorder is adequate, it is recommended that you use commercially available tools that offer good down-sampling functions for creating final sounds.

Guidelines for Sounds

In general, sounds should be designed to complement their associated graphical or functional event. The most common system or application sounds should be designed to convey functional or navigational information to users about what they are doing.

The more often the sound is played, the less obtrusive the sound should be. Unless you are designing a sound for an infrequently used novelty application or theme, sounds should be subtle, even barely noticeable. Most well-designed sound schemes are barely noticeable, but if they were absent, the user would miss them.

Appropriate sound design generally reflects the physics of the dominant interface metaphor being used. For example, playing a .wav file of a bird chirping every time the user opens a new Window may be appropriate as a novelty children's theme, but for everyday use, it would eventually become annoying to the average user.

For the most common notification and alert sounds, shorter sounds work best. For example, a sound that plays for five seconds would not be appropriate for the Menu popup event, but a five-second sound might work for the Exit Windows event.

In addition to using shorter sounds for the more frequent sound events, the audio frequency of each sound plays a significant role in user fatigue. It is best to avoid repetitive use of sounds that contain too much low-frequency information. For example, if you use a swish sound for the Open Program or Close Program event, it is much more pleasant and less annoying to use a swish sound that does not sound like a stormy wind gust. In the majority of cases, selecting the appropriate equalization (frequency-based filtering) for the sound to cut back the low frequencies will help users tolerate repetitive sounds.

Registering Sound Events

Your application can register specific events to which the user can assign sound files. When those events are triggered, the assigned sound file is played. To register a sound event, create a key under the HKEY_CURRENT_USER key, as follows:

HKEY_CURRENT_USER

AppEvents

Event Labels

EventName* = *Event Name

Set the value for EventName to a name that users can read. This is what will appear in Control Panel.

Registering a sound event makes it available in Control Panel so that users can assign a sound file to it. Your application must provide the code to trigger that event when appropriate.

Defining as many sound events as possible for your application can be especially helpful for users who need additional feedback — for example, users with visual and some types of cognitive impairments. This does not mean that your application must generate sounds for all events. You can simply not assign sounds to an event by default. This way, users who want additional feedback can use Control Panel to add appropriate sounds.

Always specify sounds to be played by using registry entries. Avoid specifying sounds by file name or resource, because these cannot be customized through Control Panel, and because accessibility aids cannot determine the meaning of these sounds.

In addition, always trigger standard sound events when carrying out equivalent actions. For example, if you display the equivalent of a critical message box, play the SND_ALIAS_SYSTEMEXCLAMATION event sound.

More Information

For more information about system sound events, see the Microsoft Platform SDK on the MSDN Online Web site at /library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shell_notifyicon.asp.

Creating Application Desktop Toolbars

The system supports applications supplying their own desktop toolbars, also referred to as access bars or appbars, that operate similarly to the Windows taskbar. Before you include a desktop toolbar, consider whether your application's tasks really require one. Remember that a desktop toolbar potentially reduces the visible work area for all applications. Therefore, you should include a desktop toolbar only for frequently used interfaces that can be applied across applications. If a toolbar applies only to a specific application or set of applications, consider removing it when those applications are closed. Also, design a desktop toolbar to be optional so that users can close it or otherwise specify that it not appear.

When you create your own desktop toolbar, design its behavior to be consistent with the system taskbar. For example, support auto-hide. This allows the desktop toolbar to be visible only when the user moves the pointer to the edge of the screen. The system supports the same auto-hide behavior for application desktop toolbars as it does for the taskbar; but only for one desktop toolbar on each edge of the display. Support drag-and-drop transfers to your desktop toolbar if it includes objects that support transfer operations.

Support undocking and redocking of the desktop toolbar. Display an undocked toolbar as a palette window that no longer constrains other windows. However, if the toolbar supports the Always on Top property, it should remain on top of other application windows.

More Information

For more information about the recommended behavior for undocking and redocking tool-bars, see Chapter 8, "Menus, Controls, and Toolbars."

Provide a shortcut menu to give users access to commands that apply to the toolbar as a whole, such as Close, Move, Size, and Properties. Do not include on the shortcut menu any commands — such as Minimize All Windows — that are included on the desktop toolbar. If the system-supplied customization does not fit your design, be sure to provide your own property sheet for setting these attributes for your desktop toolbar.

You can choose to display a desktop toolbar when the user runs a specific application, or you can create a separate application and include a shortcut icon to it in the system's Startup folder. Set the initial size and position of your desktop toolbar so that it does not interfere with other desktop toolbars or with the taskbar. The system supports docking multiple desktop toolbars along the same edge of the display screen. When you dock a toolbar on the same edge of the display screen as the taskbar, the system places the taskbar on the outermost edge.

Supporting Full-Screen Display

Although the taskbar and application desktop toolbars normally constrain or clip windows displayed on the screen, you can define a window to the full extent of the display screen. Because this is not the typical form of interaction, consider using full-screen display only for very special circumstances, such as a slide presentation, and only when users explicitly choose a command for this purpose. Make sure you provide an easy way for users to return to normal display viewing. For example, you can display an on-screen button that users can click to restore the display. In addition, keyboard interfaces, such as ALT+TAB and esc, should automatically restore the display.

Remember that desktop toolbars, including the taskbar, should support auto-hide options that allow users to reduce toolbars' visual impact on the screen. Consider whether this auto-hide capability may be sufficient before designing your application to require a full-screen presentation. Advising users to close or hide desktop toolbars may provide you with sufficient space without having to use the full display screen.

Some users rely on accessibility aids that must be visible at all times for them to interact with the computer. For example, an on-screen keyboard allows users to simulate keystrokes using a pointing device. When your application is in full-screen mode, such utilities may attempt to position themselves on top of your window. Do not prevent this by requiring that your window always be on top.

Using the Folder Metaphor

Windows also includes interfaces that enable you to create your own folder-like containers. However, if you intend to use the folder metaphor for collections of objects, ensure that you provide consistent support for the full range of folder behaviors. Users have certain expectations about what can be done with objects that express the folder metaphor. For example, a Windows folder includes support for the following functions:

• Drag-and-drop operations
• Property sheets on objects contained in the folder
• Large icon, small icon, list, and details view
• Web view of contents
• Common commands for contents, such as Cut, Copy, Paste, Rename, Delete, and Create Shortcut
• Standard verbs used for files, such as Open and Edit

More Information

If your design cannot provide reasonable consistency, you may be better off using a list box or list view control in a dialog box.

Fundamentals of Designing User Interaction

Windows Interface Components

Design Specifications and Guidelines

Appendixes and References