出自UXGuide.net

错误信息：设计规范

Error Messages: Guidelines

目录 1 呈现 2 疑难解答 3 图标 4 渐进展开 5 不要再显示此信息 6 默认值 7 帮助 8 错误码 9 声音

呈现

• 尽可能使用任务对话框来达成统一的外观和布局，任务对话框需要 Windows Vista® 或更新版本，因此不适用于早期的 Windows 版本。如果你必须使用消息框的话，应将主标题说明与辅助说明用两个换行符分开。

• 尽可能通过以下方式避免或减少用户的输入错误：
  • 使用带约束的仅限输入有效值的控件。
  • 禁用那些会产生错误的控件和菜单项，只要那些控件和菜单被禁用的原因显而易见即可。
  • 提供适当的默认值。

错误：

在这个示例中，无约束的文本框被用于需要约束的输入。应当改用滑块。

• 对于上下文相关的用户输入错误，应使用无模式的错误处理方式（就地错误信息或气球状提示。
• 当在文本框中输入时，或刚刚离开文本框时检测到非关键性的、单点的用户输入错误，应使用气球状提示。气球状提示不需要额外的屏幕空间，也不需要动态布局来显示就地消息。每次只显示一个气球状提示。由于问题并不严重，因此不需要使用错误图标。气球状提示在被单击后消失，在问题被解决或经过一段时间之后也会自动消失。

在这个示例中，气球状提示指出控件中存在的输入问题。

• 对于延后检测到的错误，应使用就地错误信息，这类错误通常是在单击了提交按钮后被发现的。（不要将就地错误信息用于那些立即提交的设置。）同一时间可能有多个就地错误信息。使用普通的文本和 16x16 像素的错误图标。就地错误信息不会自行消失，除非用户重新提交并没有发现其他错误。

在这个示例中，就地错误信息用于单击提交按钮后发现的错误。

• 对于其他类型的问题，使用模式错误处理方式（任务对话框或消息框），包括涉及到多个控件的错误、与上下文无关的错误、以及在单击提交按钮后发现的非输入型错误。
• 当报告了用户输入问题之后，应将输入焦点放置在有错误数据的控件上。如果需要的话，应当将控件滚动至可视范围。如果控件是文本框，则选中全部内容。错误信息所提到的问题应当总是显而易见的。
• 不要清除错误的数据输入。相反，应当留在原处，使得用户能够看到并更正问题，而不必从头开始。
  • 例外：清除错误的密码和凭据文本框，因为用户无法迅速更正经过掩码的输入内容。

疑难解答

• Avoid creating troubleshooting problems. Don't rely on a single error message to report a problem with several different detectable causes.
• Use a different error message (typically a different supplemental instruction) for each detectable cause. For example, if a file cannot be opened for several reasons, provide a separate supplemental instruction for each reason.
• Use a message with multiple causes only when the specific cause can't be determined. In this case, present the solutions in order of likelihood of fixing the problem. Doing so helps users solve the problem more efficiently.

图标

• Modal error message dialogs don't have title bar icons. Title bar icons are used as a visual distinction between primary windows and secondary windows.

Use an error icon. Exceptions:

If the error is a user input problem displayed using a modal dialog box or balloon, don't use an icon. Doing so is counter to the encouraging tone of Windows Vista. However, in-place error messages should use a small error icon (16x16 pixel) to clearly identify them as error messages.

In these examples, user input problems don't need error icons.

In this example, an in-place error message needs a small error icon to clearly identify it as an error message.

If the problem is for a feature that has an icon (and not a user input problem), you can use the feature icon with an error overlay. If you do this, also use the feature name as the error's subject.

In this example, the feature icon has an error overlay, and the feature is the subject of the error.

Don't use warning icons for errors. This is often done to make the presentation feel less severe. Errors aren't warnings.

Incorrect:

In this example, a warning icon is incorrectly used to make the error feel less severe.

For more guidelines and examples, see Standard Icons.

渐进展开

• Use a Show/Hide details progressive disclosure button to hide advanced or detailed information in an error message. Doing so simplifies the error message for typical usage. Don't hide needed information, because users might not find it.

In this example, the progressive disclosure button helps users drill down to more detail if they want it, or simplify the UI if they don't.

• Don't use Show/Hide details unless there really is more detail. Don't just restate the existing information in a more verbose format.
• Don't use Show/Hide details to show Help information. Use Help links instead.

For labeling guidelines, see Progressive Disclosure Controls.

不要再显示此信息

• If an error message needs this option, reconsider the error and its frequency. If it has all the characteristics of a good error (relevant, actionable, and infrequent), it shouldn't make sense for users to suppress it.

For more guidelines, see Dialog Boxes.

默认值

• 将最可靠（防止数据丢失或系统访问）且最安全的选项作为默认值。如果可靠性或安全性不是需要考虑的因素，则选择最常用或最方便的命令。

帮助

• Design error messages to avoid the need for Help. Ordinarily users shouldn't have to read external text to understand and solve the problem, unless the solution requires several steps.
• Make sure the Help content is relevant and helpful. It shouldn't be a verbose restatement of the error message—rather, it should contain useful information that is beyond the scope of the error message, such as ways to avoid the problem in the future. Don't provide a Help link just because you can.
• Use specific, concise, relevant Help links to access Help content. Don't use command buttons or progressive disclosure for this purpose.
• For error messages that you can't make specific and actionable, consider providing links to online Help content. By doing so, you can provide users with additional information that you can update after the program is released.

For more guidelines, see Help.

错误码

• For error messages that you can't make specific and actionable or they benefit from Help, consider also providing error codes. Users often use these error codes to search the Internet for additional information.
• Always provide a text description of the problem and solution. Don't depend just on the error code for this purpose.

Incorrect:

In this example, an error code is used as a substitute for a solution text.

• Assign a unique error code for each different cause. Doing so avoids troubleshooting.
• Choose error codes that are easily searchable on the Internet. If you use 32-bit codes, use a hexadecimal representation with a leading "0x" and uppercase characters.

Correct:

1234

0xC0001234

Incorrect:

-1

-67113524

• Use Show/Hide details to display error codes. Phrase as Error code: <error code>.

In this example, an error code is used to supplement an error message that can benefit from further information.

声音

• 不要在呈现错误信息时伴随声音效果或蜂鸣。这么做很刺耳，而且没有必要。
  • Exception: Play the Critical Stop sound effect if the problem is critical to the operation of the computer, and the user must take immediate action to prevent serious consequences.