Property Window Design Concepts

Property Windows
Property Window Usage Patterns

Note: This section applies primarily to property sheets and options dialog boxes, but also applies to property inspectors to a lesser degree.

Make property windows usable

Developers often simplify their program's user interfaces (UIs) by focusing on the primary 80 percent of the program, and giving users a way to handle the remaining 20 percent through property windows. This can be an excellent approach, but if not done carefully, it may result in poorly designed property windows.

Property windows often become a dumping ground for an odd assortment of low-level, technology-based settings. Too often, these properties are organized into tabs, but beyond that not designed for any particular tasks or users. As a result, when users are faced with a task in a property window, they often don't know what to do.

To ensure that your property windows are useful and usable, follow these steps:

• Make sure the properties are necessary.
• Present properties in terms of user goals, not technology.
• Present properties at the right level.
• Design pages for specific tasks.
• Design pages for Standard users and Protected administrators.
• Organize the property pages efficiently.

Make sure the properties are necessary

Of course you want your program to be powerful and flexible, but too much choice can be overwhelming for users. Review all the properties in your property windows and do the following:

• Identify a task that requires the property.
• Identify a target user for the property.
• Assign a probability that the target user will actually use the property.

If the probability is low (perhaps because doing so violates a best practice), consider removing the property. Don't clutter your property pages with unnecessary properties just to avoid making hard design decisions. Focus on the probable, not the possible.

Present properties in terms of user goals, not technology

Although a property configures a specific technology, you don't have to present it in terms of that technology. Compare the following settings:

Technology-based:

In these examples, properties are presented in terms of technology.

Goal-based:

In these examples, the same properties are presented in terms of user goals.

A simple way to evaluate property page text is to pretend that you are explaining the property and why it is useful to a friend. How would you explain it? What language would you use? Most likely you would explain the setting using plain language in terms of the user's goals (such as printing on both sides of paper) instead of obscure technology (such as manual duplex). That's the language to use in your property pages.

If you must present properties in terms of technology (perhaps because your target users recognize the technology's name), also include a brief description of the actual benefit to the user of the property.

If you do only one thing...
Present properties in terms of user goals, not technology. Pretend that you are explaining the property and why it is useful to the target user in person. How would you explain it? What language would you use? That's the language to use in your property pages.

Present properties at the right level

Sometimes individual low-level settings don't correlate to users' goals. You don't have to present individual, low-level settings in a property page, so present the properties at a level that makes sense to the target user.

Consider this sample of the low-level, technology-based security settings in Windows® Internet Explorer®:

Too low level:

This example shows a small portion (about 15 percent) of the low-level Windows Internet Explorer security settings.

Few users know if they want to enable or disable these settings, but they do know their high-level goals, such as wanting to browse the Internet safely while still maintaining most functionality. Consequently, the Windows Internet Explorer security settings are presented in terms of goal-based levels:

Better:

In this example, the collection of settings is presented in terms of users' goals.

If users need to change individual settings, they can choose the most appropriate built-in security level, and then create a custom level.

Design pages for specific tasks

When designing and evaluating pages, determine the common tasks that users perform and make sure there is a clear path to perform those tasks. Users typically perform the following types of tasks with property windows:

• View an object's current settings and attributes.
• Change an object's settings.
• Perform tasks related to an object's settings and attributes.
• Troubleshoot an object's settings to determine why it doesn't behave as expected.
• Restore or roll back an object's settings to some known functional state (such as its default settings).

To determine if a property window supports specific tasks, write a one-sentence description of the purpose of each group of properties, and determine how well the supported tasks map to those descriptions. You don't need to put these descriptions in the property windows, but you should if the goals aren't obvious.

In this example, the Windows Internet Explorer Content tab has one-sentence descriptions for each group of settings.

Design pages for Standard users and Protected administrators

Many settings require administrator privileges to change. If a process requires administrator privileges, Windows Vista and later requires Standard users and Protected administrators to elevate their privileges explicitly. Doing so helps prevent malicious code from running with administrator privileges.

For more information and examples, see User Account Control.

Organize property windows efficiently

The most common user complaints about property windows are the use of too many tabs and the inclusion of too much content on property pages. Here are some techniques to address both of these problems.

Reducing the number of tabs

Traditionally, Windows has used horizontal tabs, which work best with a single row (a maximum of five to seven tabs). You can use vertical tabs, which do a better job of handling more tabs. Even so, if you have more than 12 tabs, you have too many.

To reduce the number of tabs, identify the properties that users are least likely to need. Then put those settings into a dialog box displayed using a command button instead of placing them directly on a page. This technique works well if you want to encourage users to maintain the default settings.

In this example, the Windows Internet Explorer General tab reduces the number of tabs by moving infrequently changed settings to separate dialog boxes.

Of course, you can have too few tabs.

Incorrect:

In this example, tabs should be used to organize the settings.

Deciding what goes on a page

To decide which properties should go on a page, consider the properties' grouping and coherence. Properties are grouped well when:

• The settings on the page are related or even dependent upon each other.
• The settings on a page are not related or dependent upon settings on other pages.

Changing a setting on one page should never change a setting on another page.

Properties are coherent when:

• All the properties on the page relate to a single concept.
• The concept is specific.
• The concept is based on tasks or goals, not technology.

You can determine coherence by reviewing the tab labels. Specific labels are a strong sign of coherence; generic labels like General and Advanced are not.

Simplifying a page

Beyond making sure the properties are necessary and presented at the right level, you can simplify a property page's presentation using these techniques:

• Use larger property pages. Don't be afraid to use screen space.
• Use more compact controls:
  • Group controls with separators instead of group boxes.
  • Use list boxes instead of many individual radio buttons.
  • Use check box lists instead of many individual check boxes.
  • Use drop-down lists instead of list boxes.
  • Use split buttons for a group of related controls instead of individual command buttons.
• Move advanced or infrequently used settings to a separate dialog box, displayed using a command button.
• If the page has weak grouping and coherence, split up the page and move the properties to a new page or a generic page, such as General or Advanced.