出自UXGuide.net

对话框设计理念

Dialog Box Design Concepts

目录 1 设计高效的对话框 1.1 对话框的特性 1.2 Dialog box interactions 1.3 Dialog box contexts 1.4 Creating effective dialog boxes 1.5 Improving ineffective dialog boxes 2 Using the Don't show this <item> again option

如果使用得当，对话框是为你的程序提供功能性和灵活性的极好方式。但如果使用不当，对话框就会轻易成为骚扰用户、打断其操作、使程序变得不直接且用起来单调乏味的方式。模式对话框会要求用户予以关注。实现对话框往往比其他用户界面要容易，因此常常被过度使用。

设计高效的对话框

当对话框的设计特点符合它的用途时效率最高。对话框的设计在很大程度上取决于其目的（提供选项、提问、提供信息或反馈）、类型（模式或无模式）和用户操作（必选、可选或确认）。其用途在很大程度上取决于上下文（用户或启动的程序）、用户行动的可能性以及显示的频率。

对话框的特性

模式对话框具有以下特性：

• 显示在用户当前的活动之外的单独窗口中。
• 需要进行操作——用户必须关闭之后才能继续在所有者窗口内的工作。
• 会打断用户的操作。
• 使用延迟提交模式；直到显式提交后更改才会生效。
• 具有用于提交至任务的命令按钮。
• 最适用于关键的或不常见的、一次性的，必须先完成才能继续的任务。

无模式对话框具有下列特性：

• 可以通过任务窗格或独立窗口在上下文中显示。
• 没有必要的操作——用户可以在对话框或窗格及调用窗口之间根据需要进行切换。
• 可以使用立即提交模式；更改会立即生效。
• 具有用于关闭窗口的命令按钮。
• 最适用于频繁、重复或持续的任务。

Dialog box interactions

Dialog boxes also have different types of user interaction:

• Response required. Users must respond to provide required input. For example, a Replace command requires displaying a dialog box so users can specify the Find and Replace strings.
• Response optional. Users might respond to provide optional input, but the default values are usually acceptable. For example, while users might make changes in a Print dialog box, they usually accept the default options.
• Acknowledgement only. Users' only interaction is to acknowledge the dialog box by reading and closing it.

Dialog box contexts

Dialog boxes are displayed in different contexts:

• User initiated. A dialog box is displayed as the direct or indirect result of a user interaction.
• System or program initiated. A dialog box is displayed independently of any user interaction.

Creating effective dialog boxes

Consider these effective examples:

• A modal dialog box is an excellent choice for user initiated, one-off tasks that require a response:

• A modal dialog box is an excellent choice for infrequent system or program initiated, one-off tasks that require a response:

• A modeless dialog box is an excellent choice for user initiated, on-going tasks:

• A modal dialog box is a good choice for critical or infrequent, program initiated messages that are likely to change user behavior:

Now consider these ineffective examples:

• A modal dialog box is a poor choice for frequent tasks to provide options that users don't have to change. Instead, use the default options without asking, but allow users to make changes later.

Incorrect:

Correct:

In the correct example, Microsoft® Word correctly displays a modeless smart tag instead of a modal dialog when users paste text. That way, users aren't required to respond.

• A modal dialog box is a poor choice for messages that are unlikely to change user behavior. Instead, consider using a notification or a status bar, or even doing nothing.

Incorrect:

Correct:

Using a modal dialog box for status is annoying. In the correct example, Microsoft Outlook® correctly uses the status bar for this purpose, instead.

• A modal dialog box is often a poor choice for displaying important options. Instead, display essential options either directly with in-place UI, or on demand using progressive disclosure.

Incorrect:

Correct:

In this example, the search options could be set in an owned dialog box, but Word correctly uses progressive disclosure instead.

• A modal dialog box is a poor choice for giving feedback of minor importance, because it requires acknowledgement.

Incorrect:

In this example, Word uses a modal dialog to indicate that it has finished searching a document, which forces users to click the OK button to acknowledge. Modeless feedback would be a better choice.

If you do only one thing...

Make sure that your dialog box design (determined by its purpose, type, and user interaction) matches its usage (determined by its context, probability of user action, and frequency of display).

Improving ineffective dialog boxes

Often the best solution to a bad modal dialog box is either to eliminate the dialog or to redesign it in a way that isn't modal. Some people have concluded that this means all modal dialog boxes are bad and should be eliminated. This is not a correct conclusion (except for Web-based applications, which really should try to avoid pop-up blockers). For example, it is perfectly acceptable to interrupt users with a model dialog box for tasks that require interaction. Modal dialog boxes are the right choice in many circumstances. Trying to eliminate every modal dialog box can reduce the quality of your overall UI.

If you have a dialog box that isn't effective, consider these alternatives:

• If the dialog box is modal but doesn't have to be, consider using a modeless dialog box, task pane, or other modeless UI.
• If the dialog box is for acknowledgement only, consider adding commands to make it actionable. For example, if the dialog box is presenting a problem, consider also providing solutions to the problem.
• Review Is this the right user interface? to determine if there is a better solution.
• If the user experience isn't harmed by removing the dialog box, consider just removing it.

Using the Don't show this <item> again option

Sometimes optional modal dialog boxes turn out to be annoying, especially when displayed often. Such dialog boxes typically strive to inform users about a recurring situation or a feature that addresses such situations. A common solution to this problem is to provide a Don't show this <item> again option that suppresses the dialog box in the future:

In this example, the dialog box attempts to educate users about a recurring situation. Selecting Don't show this <item> again prevents the dialog box from being displayed in the future.

This solution has problems. It assumes that users:

• Make rational decisions about which dialog boxes to suppress based on their future needs and not on their emotions ("Stop pestering me!").
• Can accurately recognize the reoccurring situations in the future.
• Can remember and apply the information from the previous instance of the dialog box, no matter how long ago it was displayed.

If users fail in any of these steps, they won't see the dialog box in their moment of need, and there is no obvious way to get the dialog box back once suppressed.

If you think your dialog box needs a Don't show this <item> again option, that is a clear sign that it is annoying and potentially unnecessary. Before adding this option, consider the following alternatives:

• Change the design to eliminate the need for the message.
• Make the hard design decision: do users really need to see this dialog box? Will bad things happen if users don't know this information? If so, always display it; if not, never display it.

Incorrect:

In this example, users don't need this confirmations because dismissing Outlook reminders has no adverse consequences. This confirmation shouldn't be displayed at all.

• Use less intrusive solutions, such as in-place UI, progressive disclosure, modeless UI (such as balloons or tooltips), or notifications.

Do the right thing by default. Don't force users to configure their way out of a bad initial experience. Keep in mind that littering your program with unnecessary modal dialog boxes is more likely to foster outrage than user education. At a certain point, users tend to dismiss such dialog boxes without reading them.

If you are convinced that users really need to see the information for a while and a dialog box is the best solution, only then should you use the Don't show this <item> again option. If users may need to restore these dialog boxes, provide a Restore messages command in the program's Options dialog box.

Tip: When running your own program, don't change any of the Don't show this <item> again defaults. Doing so helps you evaluate your program's experience the same way your users will.