出自UXGuide.net

属性窗口：设计理念

Property Window: Design Concepts

目录 1 使属性窗口可用 2 Make sure the properties are necessary 3 Present properties in terms of user goals, not technology 4 Present properties at the right level 5 Design pages for specific tasks 6 Design pages for Standard users and Protected administrators 7 Organize property windows efficiently 7.1 Reducing the number of tabs 7.2 Deciding what goes on a page 7.3 Simplifying a page

注：本节内容主要适用于属性表及选项对话框，但也在一定程度上适用于属性查看器。

使属性窗口可用

开发人员往往是通过关注程序 80% 的主要部分并提供属性窗口让用户来处理剩余的 20% 的方式来简化其程序的用户界面。这是一个非常好的办法，但如果不小心，就会产生设计糟糕的属性窗口。

属性窗口往往成为各种古怪的底层基于技术的设置聚集地。更经常的是，这些属性被组织在选项卡中，却又不是为任何任务或用户而设计的。结果，当用户在属性窗口中面临一项任务时，他们往往无所适从。

要确保你的属性窗口是有用的且可用的，应当遵从下列步骤：

• 确保这些属性是必要的。
• 按照用户的目标来呈现属性，而非技术。
• 在合适的层面上呈现属性。
• 为特定的任务设计页面。
• 为标准用户和受保护的管理员设计页面。
• 有效地组织属性页。

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 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.