出自UXGuide.net

控制面板

Control Panels

目录 1 这样的用户界面是否正确？ 1.1 是创建新的控制项板项还是扩展已有的项？ 2 Design concepts 3 Usage patterns 3.1 Task flow patterns 3.1.1 Hub pages 3.1.2 Spoke pages 3.2 Property sheet patterns 4 Guidelines 4.1 Property sheet control panel items 4.2 Task flow control panel items 4.2.1 General 4.2.2 Task links and buttons 4.2.3 Dialog boxes 4.3 Hub pages 4.3.1 General 4.3.2 Object lists 4.3.3 Interaction 4.3.4 Task panes 4.3.5 See also links 4.4 Spoke pages 4.4.1 General 4.4.2 Interaction 4.4.3 Interaction (intermediate spoke pages) 4.4.4 Interaction (final spoke pages) 4.4.5 Commit buttons 4.4.6 Preview buttons 4.4.7 Immediate previews 4.4.8 Apply buttons 4.5 Control panel integration 4.5.1 Home page categories 4.5.2 Task links 4.5.3 Search terms 4.6 Standard users and Protected administrators 4.7 Schemes and themes 4.8 Miscellaneous 4.9 Default values 5 Text 5.1 Item names 5.2 Title page 5.3 Task link text 5.4 Main instructions 5.5 Supplemental instructions 5.6 Page text 5.7 Task links 5.8 Commit buttons 6 Documentation

通过 Microsoft® Windows® 中的“控制面板”，用户能够配置系统级的功能特性并执行一些相关的操作。所谓系统级的功能特性配置包括硬件和软件的安装与配置、安全、系统维护、以及用户帐户管理等。

术语“控制面板”指整个 Windows 控制面板功能。单个的控制面板被称为“控制面板项”。

典型的控制面板项

“控制面板主页”是所有控制面板项的主入口点，按照不同分类列出各控制面板项及其最常见的任务。它在用户单击开始菜单上的控制面板时显示。

“控制面板分类页面”中列出了单个分类下的所有控制面板项及其最常见的任务。它在用户单击主页上的分类名称时显示。

控制面板项是通过任务流程或属性表来实现的。对于 Windows Vista® 来说，倾向于使用任务流程式的用户界面（UI）。

注：与属性表相关的设计规范请参考各自相应的章节。

这样的用户界面是否正确？

考虑下列问题以进行判断：

• 其目的是否是对系统级特性进行配置？如果不是，则应使用其他的集成点。你的应用程序的功能应当可以通过提供选项对话框 UI 来直接进行配置，而非使用控制面板。对于那些并非用于安装、配置或相关任务的实用工具（如疑难解答），应当将开始菜单用作集成点。
• 该系统级特性是否具有自己的 UI？如果是，那么那个 UI 才是用户应当进行设置更改的地方。例如，系统备份工具应当在其程序选项中进行配置，而不是控制面板。
• 用户是否经常需要更改配置？如果是（是指一周好几次），考虑使用控制面板之外的其他方案。例如，Windows 主要卷设置可以直接通过通知区域的图标来进行配置。有些设置则可以自动配置。例如在 Windows Explorer 中，应用程序属性中的兼容性选项卡使应用程序可以运行在 256 色模式下，而无须用户手工更改显示模式。
• 目标用户是否是 IT 专业人员？如果是，则应改用 Microsoft Management Console（MMC）控制台，它专为系统管理任务而设计。有些情况下，最好的解决方案则是既为普通用户提供控制面板项，又为 IT 专业人员提供 MMC 控制台。

在这个示例中，Local Users and Groups MMC 控制台面向 IT 专业人员提供用户管理功能。其他用户则通常更愿意使用控制面板中的用户帐户项。

• 该功能是否是只在系统初始化配置时使用的 OEM 功能？如果是，则应使用 Windows 欢迎中心作为集成点。

控制面板项是必要的，因为许多系统级特性不具有更加明显或直接的集成点。不过控制面板不应当被视为所有配置设置的“百宝箱”。具有用户界面的应用程序应当通过其 UI 进行直接配置，而非使用控制面板项。

错误：

在这个示例中，Windows Internet Explorer® 不应当出现在控制面板中，因为其自身的 UI 是更好的集成点。

是创建新的控制项板项还是扩展已有的项？

考虑下列问题以进行判断：

• 该功能是否能够被表述为可以插入已有的可扩展控制面板项中的任务？可扩展的控制面板项包括：蓝牙设备、显示、Internet、键盘、鼠标、网络、电源、系统、无线（红外）等。
• 这些属性和任务是否会取代已有的可扩展控制面板项的特性？如果会，你应当扩展已有的控制面板项以获得更加简洁的用户体验。如果不会，则创建一个新的控制面板项。

Design concepts

The Control Panel concept is based on a real-world metaphor. A real-world control panel is a collection of controls (knobs, switches, gauges, and displays) used to monitor and control a device. Users of such control panels often need training to understand how to use them.

Unlike their real-world counterparts, Windows control panel designs are optimized for first-time users. Users don't perform most control panel tasks very often, so they usually don't remember how to do them and effectively have to relearn them every time.

To design a control panel item that is useful and easy to use:

• 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 specific users, especially limited users (non-administrators).

When designing and evaluating items to include in Control Panel, 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 control panel items:

• Initial configuration
• Infrequent changes (for most settings)
• Frequent changes (for a few important settings)
• Rolling back settings to an initial or previous state
• Troubleshooting

If you do only one thing...

Design control panel pages for specific tasks, and present them in terms of user goals instead of technology.

Usage patterns

For control panel items, you can use a task flow or a property sheet. Here are their usage patterns:

Task flow patterns

Task flow items use a hub page to present the high-level choices, and spoke pages to perform the actual configuration.

Hub pages

• Task-based hub pages. These hub pages present the most commonly used tasks. They are best used for a few commonly used or important tasks where users need more guidance and explanation. Hub pages don't have commit buttons. Hybrid task-based hub pages also have some properties or commands directly on them. Hybrid hub pages are strongly recommended when users are most likely to use Control Panel to access those properties and commands.
• Object-based hub pages. These hub pages present the available objects. They are best used when there could be several objects. Hub pages don't have commit buttons. There are two variations of this pattern:
  • The standard version is implemented using a standard list view control.
  • The hybrid version is an object-based hub page that also has some properties or commands directly on it. Hybrid hub pages are strongly recommended when users are most likely to use Control Panel to access those properties and commands.

Spoke pages

• Task pages. These spoke pages present a task or a step in a task with a specific, task-based main instruction. They are best used for tasks that benefit from additional guidance and explanation.
• Form pages. These spoke pages present a collection of related properties and tasks based on a general main instruction. They are best used for features that have many properties and benefit from a direct, single-page presentation, such as advanced properties.

Property sheet patterns

• Property sheets are best used in legacy items with many settings targeted at advanced users. New items can achieve the same effect with a task flow using the form page pattern.

For more information and examples, see Control Panel Patterns.

Guidelines

Property sheet control panel items

• Don't use property sheets for new control panel items. Instead, use task flows to create a seamless experience and make full use of the categorization and search functionality of the control panel home page.

Task flow control panel items

General

• Keep the most important content and controls visible without scrolling. Users won't scroll to see page content unless they have a reason to. You can make commit buttons always visible by placing them in a command area instead of the content area. Don't break up pages just to avoid scrolling.
  • You can vertically scroll long pages, as long as the most important controls are visible without scrolling.
  • Don't use horizontal scrolling. Instead, redesign the page content and use vertical scrolling. Pages may have horizontal scrollbars only when made very narrow.
• To navigate between pages:
  • Use task links to start a task.
  • Use task links or a Next button to navigate to the next page in a multi-step task.
  • Use commit buttons to complete a task.
  • Use the Back button in the menu bar to return to previously viewed pages. Do not add a Back button to the command area.
  • Use the Address bar to return directly to the control panel home page.
  • Use See also links in the task pane to navigate to pages in other control panel items. Otherwise, navigation should stay within a single control panel item.
• Put only the control panel home page in the Address bar. Clicking that link returns to the control panel home page, abandoning any work in progress without a confirmations.
• Don't put a Close command button on control panel pages. Users can close a control panel window using the Close button on the title bar.

Task links and buttons

• 当一个页面包含一组少量固定的选项时，应当使用命令链接来代替选项按钮和提交按钮的组合。这样用户能够只单击一次就做出选择。
• You can put task links and buttons in the following places (in order of discoverability):
  • The command area (for command buttons on spoke pages only).
  • The content area:
    • Command buttons
    • Task links
    • Other links
  • Links in the task pane (hub pages only).
• Base the location of task links and buttons on importance and need for discoverability.
  • Put only commit buttons in the command area.
  • Put essential tasks in the content area. Command buttons tend to draw the most attention, so reserve them for commands users must see. Task links also draw attention, but less than command buttons.
  • Reserve the task pane and plain links for secondary (less important) tasks. The task pane is the least discoverable area of a task page, and plain links aren't as visible as command buttons and task links.
• For task links presented in the content area:
  • If there are more than seven links, group the links into categories. Provide headings for each of the groups.
  • For fewer than seven links, present the links in a single group without a heading.
• Present task links and buttons in a logical order. List task links vertically, command buttons horizontally.
• Within categories, divide the commands into related groups. Present the task groups by placing the most commonly used first, and within each group, place the most commonly used tasks first. The resulting order should roughly follow the likelihood of use, but also have a logical flow.
  • Exception: Task links that result in doing everything should be placed first.
• If there are many task links, give the most important tasks a more prominent appearance by using a 24x24 pixel icon and two lines of text. For less important tasks, use a 16x16 pixel icon, or no icon, and a single line of link text.

In this example, important commands are given a more prominent appearance.

• Have clear physical separation between frequently used commands and destructive commands. Otherwise, users might click destructive commands accidentally. You may need to reorder your commands somewhat to put destructive commands together.
• Provide the mechanism to undo commands directly on the page. Users shouldn't have to navigate somewhere else to undo a mistake.
• For task links, use either all default task link icons or all custom icons. Don't mix them. Consider using custom icons only if:
  • They aid users in comprehending the tasks.
  • They comply with the Aero icon standards.
  • They have an unobtrusive appearance.

Dialog boxes

When using task flows, you generally want a task to flow from page to page within a single window, but the following circumstances are exceptions.

• Use dialog boxes in the following circumstances:
  • To prompt users for an administrator user name and password. Always use the credential manager dialog box for this purpose. (Should be modal.)
  • To confirm an in-place command using a task dialog or message box. (Should be modal.)
  • To get input for in-place commands, such as for New, Add, Save As, Rename, and Print commands.

In this example, the Delete command is performed in a dialog box instead of a separate page.

• • To perform secondary, stand-alone tasks. Using a modeless, secondary window allows such tasks to be performed independently and outside the main task flow.

Hub pages

General

• Use task-based hub pages when:
  • There are a small number of commonly used or important tasks.
  • The configuration involves one or two objects (examples: monitors, keyboard, mouse, game controllers).
  • The configuration applies system-wide (examples: date and time, security, power options).
• Use object-based hub pages when:
  • The configuration could involve several objects (examples: user accounts, network connections, printers).
  • The configuration applies only to the selected object.
• Don't use a hub page if the control panel item has a single page that contains all the tasks and properties involved.

Object lists

• List items in a logical order. Sort named objects in alphabetical order, numbers in numeric order, and dates in chronological order.
• For object-based hubs, provide object view commands in the task pane if the ability to change the view is important to the tasks. The ability to change views is important if there are many objects and the default presentation doesn't work well for all scenarios. Users can change the list view even if there aren't explicit commands through the list view shortcut menu, but it's less discoverable.

For more guidelines about presenting object lists, see List Views.

Interaction

• Don't put commit buttons on hub pages. Hub pages are fundamentally launch points. Users never "commit" hub pages—they are never done with them. And commit buttons on hub pages make any tasks initiated from a hub confusing (users will wonder if those tasks need to be committed).
  • Exception: If changing a setting requires elevation, provide an Apply button with a security shield icon. Disable the commit button once changes have been applied.

In this example, changing a setting requires elevation, so an Apply button is used.

• Consider putting the most useful properties directly on hub pages. Such hybrid hub pages are strongly recommended when users are most likely to use Control Panel to access those properties.

In this example, the Power Options control panel item has the most useful settings directly on the hub page.

• Use an immediate commit model for any settings on hybrid hub pages so that changes are made immediately. Again, users never commit a hub page. If a setting requires a commit button, don't put it on a hub page.
• Consider putting simple, "one-step" commands directly on hub pages instead of using navigation links.
• Confirm in-place commands whose effects cannot be easily undone. Use a task dialog or message box.

In this example, the Delete command is confirmed with a dialog box.

• For task-based hub pages, identify each task with a task link and an icon. You can also provide an optional description for each link. However, try to make the task links self-explanatory and provide optional descriptions only to links that really need them.

In this example, each task has a task link and an icon.

• For object-based hub pages, single-clicking selects objects, and double-clicking selects an object and navigates to its default page. The default page is typically a property page or a task-based hub page.
• An object-based hub page may navigate to a task-based hub for the selected objects. However, such secondary hubs should be avoided because they make a control panel item feel too indirect.

Task panes

Use task panes to present links to commands, views, and related control panel items.

• For task panes in task-based hubs, present links in the following order:
  1. Secondary commands. Present primary tasks only in the content area. Use the task pane for secondary, optional tasks. Consider a task primary if users must discover it in important scenarios; secondary if it's acceptable for users not to discover it.
  2. See also. The optional links that navigate to related control panel items.
• For task panes in object-based hubs, present links in the following order:
  1. Object views. The optional links used to control the presentation of the objects.
  2. Fixed commands. The commands that are independent of the currently selected objects.
  3. Contextual commands. The commands that depend on the currently selected objects, and are therefore not always displayed.
  4. See also. The optional links that navigate to related control panel items.
• Don't use task panes in spoke pages. Unlike hub pages, spoke pages should be focused on completing the task. You don't want to encourage users to navigate away before completion.

See also links

• Provide See also links in the task pane to help users find related control panel items, or the right control panel item if they have the wrong one. Link to items users are likely to associate with your control panel item.

In this example, the Performance control panel item links to the Security Center and Problem Reports and Solutions items, because users are likely to want to perform tasks from those control panel items.

• Link to a specific task page if that is what users are more likely to recognize. Otherwise, link to the entire control panel item. Use the control panel name without adding the phrase, control panel.

Spoke pages

General

• Use task pages for commonly used or important tasks where users need more guidance and explanation.
• Use form pages for features that have many settings and benefit from a direct, single-page presentation. The ideal tasks for such pages typically involve obvious changes to a few simple properties.
• Don't use task panes in spoke pages.

Interaction

• Try to limit main tasks to a single page. If more than one page is required, you can:
  • Use intermediate spoke pages for additional or optional steps. Intermediate spoke pages are committed by the final spoke page.
  • Use independent windows for independent auxiliary tasks. Independent windows are committed on their own, and independently of the main task.

Doing so keeps the meaning of the commit buttons for the main task clear and unambiguous. Users should always be confident in understanding what they are committing to.

• Don't use See Also links within a task flow. These link to related, but different, control panel items. Although navigating to a different item is acceptable in hub pages, it is not in spoke pages, because doing so interrupts the task.
• Don't use spoke pages for simple input or confirmations. Use modal dialog boxes instead.

Interaction (intermediate spoke pages)

• Use task links or a Next button to navigate to the next page. The way to proceed to the next step should always be obvious.
• You can have navigation links to optional task steps. To avoid confusion when users commit to the task, those extra pages should be intermediate pages within the same control panel item. They shouldn't have commit buttons, but should be committed when the main task is committed.

Interaction (final spoke pages)

• Use commit buttons to complete a task. Use a delayed commit model for spoke pages, so that changes aren't made until explicitly committed (if users navigate away using Back, Close, or the Address bar, changes are abandoned). The commit buttons are a visual clue that the user is about to complete a task. Don't use links for this purpose.
• Don't confirm commit buttons (including Cancel). Doing so can be annoying. Exceptions:
  • The action has significant consequences and, if incorrect, not readily fixable.
  • The action may result in a significant loss of the user's time or effort.
  • The action is clearly inconsistent with other actions.
• Don't confirm if users abandon changes by navigating away using Back, Close, or the Address bar.
• Don't use command or navigation links (including See also links). On final spoke pages, users should explicitly complete or cancel the task. Users should not be encouraged to navigate somewhere else, because doing so would likely cancel the task implicitly.
• When users complete or cancel a task, they should be sent back to the hub page from which the task was launched. If there is no such hub page, close the control panel window instead. Don't assume that spoke pages are always launched from their hub.
• Remove the stale "committed" pages from the Windows Explorer Back stack when you return users back to the page that the task was launched from. Users should never see the pages that they have already committed to when clicking the Back button. Users should always make additional changes by completely redoing the task instead of clicking Back to modify stale pages.
  • Developers: You can remove these stale pages using the ITravelLog::FindTravelEntry() and ITravelLogEx::DeleteEntry() APIs.

Commit buttons

Note: Cancel buttons are considered to be commit buttons.

• Confirm tasks using commit buttons that are specific responses to the main instruction, instead of generic labels such as OK. The labels on commit buttons should make sense on their own. Avoid using OK because it isn't a specific response to the main instruction, and therefore easier to misunderstand. Furthermore, OK is typically used with modal dialog boxes and incorrectly implies closing the control panel item window.
  • Exceptions:
    • Use OK for pages that don't have settings.
    • Use OK when the specific response is still generic, such as Save, Select, or Choose, as when changing a specific setting or a collection of settings.
    • Use OK if the page has radio buttons that are responses to the main instruction. To maintain the delayed commit model, you can't use task links on a final spoke page.

In this example, the radio buttons, not the commit buttons, are responses to the main instruction.

• Provide a Cancel button to let users explicitly abandon changes. While users can implicitly abandon a task by not confirming their changes, providing a Cancel button allows them to do so with greater confidence.
  • Exception: Don't provide a Cancel button for tasks where users can't make changes. The OK button has the same effect as Cancel in this case.
• Don't use Close, Done, or Finish commit buttons. These buttons are typically used with modal dialog boxes and incorrectly imply closing the control panel item window. Users can close the window using the Close button on the title bar. Also, Done and Finish are misleading because users are returned to the page where the task was launched from, so they aren't really done.
• Don't disable commit buttons. Otherwise users have to deduce why the commit buttons are disabled. It's better to leave commit buttons enabled, and give a helpful error message whenever there is a problem.
• Make sure the commit buttons appear on the page without scrolling. If the page is long, you can make commit buttons always visible by placing them in a command area, instead of in the content area.

In this example, content area size is unbounded, so the commit buttons are placed in the command area.

• Right-align the commit buttons and use this order (from left to right): positive commit buttons, Cancel, and Apply.

Preview buttons

• Make sure the Preview button means to apply the pending changes now but restore the current settings if users navigate away from the page without committing to the changes.
• You can use Preview buttons on any spoke page. Hub pages don't need Preview buttons because they use an immediate commit model.
• Consider using a Preview button instead of an Apply button for control panel pages. Preview buttons are easier for users to understand and can be used on any spoke page.
• Provide a Preview button only if the page has settings (at least one) with effects that users can see. Users should be able to preview a change, evaluate the change, and make further changes based on that evaluation.
• Always enable the Preview button.

Immediate previews

A control panel item has an immediate preview when changes on a spoke page take effect immediately.

• Consider using an immediate preview for display settings when:
  • The changes are obvious, typically because they apply to the entire monitor.
  • The changes are applied immediately, without significant delay.
  • The changes are safe and can easily be undone.

In this example, Windows Color and Appearance changes are applied immediately. Doing so allows users to make changes with minimal effort.

• Use OK and Cancel for the commit buttons. OK keeps the current settings, whereas Cancel reverts to the original settings.
• Don't undo changes if users navigate away using Back, Close, or the Address bar. Users don't expect the need to commit when the desired effect has already occurred.

Apply buttons

• Make sure the Apply button means apply the pending changes (made since the task was started or the last Apply), but remain on the current page. Doing so allows users to evaluate the changes before moving on to other tasks.
• Use Apply buttons only on final spoke pages. Apply buttons should not be used on intermediate spoke pages to maintain an immediate commit model.
  • Exception: You can use Apply buttons on a hybrid hub page if changing a setting requires elevation. For more details, see hub page interaction.
• Provide an Apply button only if the page has settings (at least one) with effects that users can evaluate in a meaningful way. Typically, Apply buttons are used when settings make visible changes. Users should be able to apply a change, evaluate the change, and make further changes based on that evaluation.
• Enable the Apply button only when there are pending changes; otherwise, disable it.
• Assign "A" as the access key.

Control panel integration

To integrate your control panel item with Windows, you can:

• Register your control panel item (including its name, description, and icon), so that Windows is aware of it.
• Associate your control panel item with home page categories.
• Provide task links (including their name, description, keywords, and command line) to indicate primary tasks and allow users to navigate directly to them.
• Provide search terms to help users find your task links using the Control Panel Home Page search feature.

Note that you can provide this information only for new control panel items—you can't add or change this information for control panel items that you extend.

Home page categories

• Associate your control panel item with the category under which users are most likely to look for it. This decision should be based on user testing. The following categories are available:
  • System and Maintenance
  • Security
  • Ease of Access
  • Network and Internet
  • Hardware and Sound
  • Programs
  • Mobile PC (visible only on mobile PCs)
  • User Accounts and Family Safety (or just User Accounts when parental controls isn't available)
  • Appearance and Personalization
  • Clock, Language, and Region
  • Additional Options (if your item doesn't logically fit anywhere else)
• Consider associating your control panel item with the second most likely category as well. You should associate a control panel item with two categories if users are likely to look for its main tasks in more than one place.
• Don't associate your control panel item with more than two categories. The value of the categorization is undermined if control panel items appear in several categories.

Task links

• Associate your control panel item with its primary tasks. You can display up to five tasks on a Category page, but additional tasks are used for control panel searching. Use the same phrasing as you do for task links, possibly removing some words to make the task links more succinct.
• Prefer to have task links lead to different places in your control panel item. Having multiple links to the same place can be confusing.

Search terms

• Register search terms for your control panel item that users are most likely to use to describe it. These search terms should include:
  • The features or objects configured.
  • The primary tasks.

These search terms should be based on user testing.

• Also include common synonyms for these search terms. For example, monitor and display are synonyms, so both words should be included.
• Include alternative spellings or word breaks. For example, users might search for either web site and website. Consider providing common misspellings as well.
• Consider singular vs. plural noun forms. The control panel search feature doesn't automatically search for both forms; supply the forms for which users are likely to search.
• Use simple present tense verbs. If you register connect as a search term, the search feature won't automatically look for connects, connecting, and connected.
• Don't worry about case. The search feature is not case-sensitive.

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.

Schemes and themes

A scheme is a named collection of visual settings. A theme is a named collection of settings across the system. Examples of schemes and themes include Display, Mouse, Phone and Modem, Power Options, and Sound and Audio Options.

• Allow users to create schemes when:
  • Users are likely to change the settings.
  • Users are most likely to change settings as a collection.

Schemes are useful when users are in a different environment, such as a different physical location (country/region, time zone); using their computer in a different situation (on batteries, docked/undocked); or using their computer for a different function (presentations, video playback).

• Provide at least one default scheme. The default scheme should be well named and apply to most users in most circumstances. Users shouldn't have to create a scheme of their own.
• Provide a preview or other mechanism so that users can see the settings within the scheme.

In this example, the Theme Settings control panel item shows a preview of the desktop and appearance settings.

• Provide Save As and Delete commands. A rename command isn't necessary—users can rename schemes by saving under the desired name and deleting the original scheme.
• If the settings can't be applied without a scheme, don't allow users to delete all the schemes. Users shouldn't have to create a scheme of their own.
• If the schemes are not completely independent (for example, power schemes depend upon the current laptop mode of operation), make sure there is an easy way to change settings that apply across all schemes. For example with power schemes, make sure that users can set what happens when a portable computer's lid is closed in a single location.

Miscellaneous

• Use Control Panel extensions for features that replace or extend existing Windows functionality. The following control panel items are extensible: Bluetooth Devices, Display, Internet, Keyboard, Mouse, Network, Power, System, Wireless (infrared).

Default values

• The settings within a control panel item must reflect the current state of the feature. Doing otherwise would be misleading and possibly lead to undesired results. For example, if settings reflect the recommendations but not the current state, users might click Cancel instead of making changes, thinking that no changes are needed.
• Choose the safest (to prevent loss of data or system access) and most secure initial state. Assume that most users won't change the settings.
• If safety and security aren't factors, choose the initial state that is most likely or convenient.

Text

Item names

• Choose a descriptive name that clearly communicates and differentiates what the control panel item does. Most names describe the Windows feature or object being configured, and are displayed in the Classic View of the control panel home page.
• Don't include the words "Settings," "Options," "Properties," or "Configuration" in the name. This is implied, and leaving it off makes it easier for users to scan.

Incorrect:

Accessibility Options

Modem Settings

Power Options

Regional and Language Options

Correct:

Accessibility

Modem

Power

Regional Formats and Languages

In the correct examples, unnecessary words are removed.

• If the control panel item configures related features, list only those features required to identify the item, and list the features the most likely to be recognized or used first.

Incorrect:

Folder Options

Phone and Modem Options

Correct:

Files and Folders

Modem

In the correct examples, the primary control panel item features are given emphasis.

• Use title-style capitalization.

Title page

• Use the control panel item name for the title.

Task link text

The following guidelines apply to links to task pages, such as Category page task links and See also links.

• Choose concise task names that clearly communicate and differentiate the task. Users shouldn't have to figure out what the task really means or how it differs from other tasks. Incorrect: Adjust display settings Correct: Screen resolution In the correct example, the wording conveys more precision.
• Retain similar language between task links and the pages they point to. Users shouldn't be surprised by the page that is displayed by a link.
• For task pages, design the main instruction, commit buttons, and task links as a related set of text. Examples:

  Task link:	Connect to a wireless network
  Main instruction:	Choose a network to connect to
  Commit button:	Connect
  Task link:	Set up parental controls
  Main instruction:	Choose a user and set up parental controls
  Commit button:	Apply parental control
  Task link:	Resolve your sync conflicts
  Main instruction:	How do you want to resolve this conflict?
  Commit button:	Resolve

  These examples show the relationship of the task link text, main instruction, and commit button text.
• While tasks often start with verbs, consider omitting the verb on Category pages if it is a generic, configuration-related verb that doesn't help communicate the task. Specific, helpful verbs: Add Check Connect Copy Create Delete Disconnect Install Remove Set up Start Stop Troubleshoot Generic, unhelpful verbs: Adjust Change Choose Configure Edit Manage Open Pick Set Select Show View
• If the task configures several related features, list only the features that are representative of the set. Omit details that can be readily inferred. Incorrect: Speaker volume, mute, volume icon Speakers, microphones, MIDI, and sound schemes Correct: Speaker volume Speakers and microphones In the correct examples, only the representative features are given in the task link.
• You should phrase tasks in terms of technology only if target users would do so as well. Incorrect: Connectoids Pixel depth DPI Correct: Printers Scanners Mouse The correct examples are technology-based terms that target users are likely to use, whereas the incorrect examples are not.
• Use plural nouns only if the system can support more than one.
• 使用句子大写样式。
• Don't use ending punctuation.

Main instructions

• For the hub page, use the main instruction to explain the user's objective with the control panel item. The main instruction should help users determine if they have selected the right control panel item. Keep in mind that users might have selected your control panel item in error and are actually looking for settings that are part of another control panel item.

Examples:

Keep your computer secure and up-to-date

Optimize your computer so it's easier to see, hear, and control

• For spoke pages, use the main instruction to explain what to do on the page. The instruction should be a specific statement, imperative direction, or question. Good instructions communicate the user's objective with the page rather than focusing purely on the mechanics of manipulating it.

Incorrect:

Pick a notification task

Correct:

Indicate how to handle incoming information

The correct version better communicates the goal achieved by the page.

• 尽可能使用明确的动词。对于用户来说，明确的动词比常规动词更加有意义。
• 使用句子大写样式。
• 如果主标题说明文本是陈述句的话，不要在末尾使用句号。但如果说明文本是问句的话，则需要在末尾添加问号。

Supplemental instructions

• For the hub page, use the optional supplemental instruction to further explain the purpose of the control panel item.
• For spoke pages, use the optional supplemental instruction to present additional information helpful to understanding or using the page. You can provide more detailed information and define terminology.
• 使用带句末标点的完整句子，并使用句子大写样式。（原文中无“带句末标点”，参照对应章节补充。——译者注）

Page text

• Don't restate the main instruction in the content area.
• Use the word "page" to refer to the page itself.
• Use the second person (you, your) to tell users what to do in the main instruction and content area. Often the second person is implied.

Example:

Choose the pictures you want to print.

• Use the first person (I, me, my) to let users tell the control panel item what to do in the content area that responds to the main instruction.

Example:

Print the photos on my camera.

Task links

• Choose concise link text that clearly communicates and differentiates what the task link does. It should be self-explanatory and correspond to the main instruction. Users shouldn't have to figure out what the link really means or how it differs from other links.
• Always start task links with a verb.
• 使用句子大写样式。
• Don't use ending punctuation.
• If the task link requires further explanation, provide the explanation in a separate text control using complete sentences and ending punctuation. However, add such explanations only when needed—don't add explanations to all task links because another task link needs one.

For more information and examples, see Links.

Commit buttons

• Use specific commit button labels that make sense on their own and match the main instruction. Ideally users shouldn't have to read anything else to understand the label. Users are far more likely to read command button labels than static text.
• Always start commit button labels with a verb.
• Don't use Close, Done, or Finish. These button labels are better suited for other types of windows.
• 使用句子大写样式。
• Don't use ending punctuation.
• 分配唯一的访问键。
  • 例外：不要将访问键分配给取消按钮，因为 Esc 键即是其访问键。这么做会使其他访问键更容易分配。

Documentation

When referring to the control panel home page or category pages:

• In user documentation, refer to Control Panel, using title-style capitalization and omitting a preceding definite article the.

Example:

In Control Panel, open Security Center.

• In programming and other technical documentation, refer to control panel home page and control panel category page, without capitalizing any of the words. A preceding definite article is optional.

For control panel items:

• When referring to an individual control panel item, use "[control panel item name] in Control Panel" or generally "Control Panel item" in user documentation. Don't use applet, program, or control panel to refer to individual control panel items.
• When referring to a control panel item's hub page, use "main [control panel item name] page."
• When possible, format the control panel name using bold text. Otherwise, put the name in quotation marks only if required to prevent confusion.

Examples:

• In Control Panel, open Parental Controls.
• Return to the main Parental Controls page.