Windows 用户体验交互设计规范 » 对话框 - Fung Gor

Windows 用户体验交互设计规范 » 对话框

Posted on 2011-04-22 11:27 Fung Gor 阅读(1131) 评论(0) 收藏举报

对话框
Dialog Boxes

模式对话框必须在用户完成操作并将其关闭后才能继续操作其所有者窗口。这类对话框最适用于关键的或是不常见的、一次性的，需要在继续之前先行完成的任务。
无模式对话框允许用户在对话框与其所有者窗口之间进行切换。这类对话框最适用于那些频繁的、重复性的、持续的任务。

“任务对话框”是指使用任务对话框 API 实现的对话框。它由下列部分中的全部或部分组成：

标题栏，用于标识对话框所来自的应用程序或系统功能。
主标题说明，带有可选的图标，用于标识用户在该对话框中的目标。
内容区域，用于描述信息和控件。
命令区域，用于提交按钮，包括取消按钮，以及可选的更多选项和“不再显示此 <项>”控件。
脚注区域，用于可选的附加说明和帮助，通常为缺乏使用经验的用户而设计。

Aa511268_Dialogs30(en-us,MSDN_10).png

典型的任务对话框

只要有可能，就推荐使用任务对话框，因为它易于创建且具有统一的外观。你可以使用 TDPad 工具来快速轻松地创建和评估任务对话框。任务对话框需要 Windows Vista® 或更新版本，因此它不适用于早期的 Microsoft® Windows® 版本。

“任务窗格”和对话框很像，除了它出现在窗口的窗格内而不是一个独立的窗口。因此，任务窗格所带来的直接、上下文感比对话框要强。即使在技术上它们不同，但由于任务窗格与对话框如此相近，它们的设计规范都包含在本文中。

Aa511268_Dialogs02b(en-us,MSDN_10).png

典型的任务窗格

属性窗口是一类特殊的对话框，用于查看或更改一个或一组对象或程序的属性。另外，属性窗口通常支持多个任务，而对话框则通常只支持单个任务或一个任务中的单个步骤。由于其特殊用途，属性窗口会有另外的一组设计规范。

对话框可能包含选项卡，此时则被称为“带选项卡的对话框”。是否为属性窗口是根据其属性的呈现方式来确定的，而不是根据选项卡的使用。

注：与布局、窗口管理、通用对话框、属性窗口、向导、确认信息、错误信息和警告信息相关的设计规范请参考各自相应的章节。

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

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

是否用于向用户提供信息、进行询问、或是让用户选择选项以执行命令或任务？如果不是，则应当使用其他的用户界面。
是否用于查看或更改某个对象、一组对象或一个程序的属性？如果是，则应改用属性窗口或工具栏。
是否用于呈现一组命令或工具？如果是，则应使用工具栏或调色板窗口。
是否用于确认用户是否希望继续某个操作？是否有明确的理由不再继续，且有合理的用户也许不想继续的可能？如果是，则应使用确认信息。
是否用于提供错误或警告信息？如果是，则应使用错误信息或警告信息。
是否用于下列用途？
- 打开文件
- 保存文件
- 打开文件位
- 查找与替换文本
- 打印文档
- 选择打印页面的属性
- 选择字体
- 选择颜色
- 浏览文件、文件夹、计算机或打印机
- 在 Microsoft 活动目录®中搜索用户、计算机或组。
- 提示用户输入用户名或密码

如果是，则应改用合适的通用对话框。大部分通用对话框是可以扩展的。

是否用于完成那些需要多个窗口的多步骤任务？如果是，则应改用任务流程或向导。
是否用于通知用户那些与其当前活动无关的、不需要用户立即采取行动的、且用户可以完全忽略的系统或程序事件？如果是，则应改用通知。
是否用于显示程序状态？如果是，则应改用状态栏。
使用就地用户界面是否更好？对话框需要用户的关注，会打断其操作。有时打断用户的操作是经过权衡的，比如用户必须离开当前上下文来完成某个操作。另外有些时候，则直接在上下文中呈现用户界面更好些，无论是直接在就地用户界面中显示（如任务窗格），或使用渐进展开方式按需提供。
是否用于显示非关键用户输入问题或特殊情况？如果是，则应改用气球状提示。
对于任务流程来说，是否使用另外的页面更好？通常来说，你希望任务是在一个单独的窗口中一页页地进行。对话框应当用来对就地命令进行确认、为就地命令获取输入、以及完成那些最好单独在主任务流程之外进行的次要、独立的任务。
对于选择选项来说，用户是否很有可能更改这些选项？如果不是，则考虑其他方案，如：
- 使用默认选项，不再询问，但允许用户之后再进行更改。
- 同时提供带选项的版本（例如，菜单栏中的“打印...”）和不带选项的版本（例如，工具栏上的“打印”）。通常来说，工具栏命令应当立即进行，避免显示对话框。
对于选择选项来说，是否存在更简单、更直接的呈现选项的方式？如果有，则应考虑其他方案，如：
- 使用分割按钮来选择一个命令的变体。
- 为命令、复选框、单选按钮及简单列表使用子菜单。

在这些示例中，子菜单用于代替显示简单列表的对话框。

设计理念

如果使用得当，对话框则是为你的程序提供强大功能和灵活性的绝佳方式。如果使用不当，对话框则很容易打扰用户、打断他们的捷足先登、让人觉得程序不够直接而且难以使用。模式对话框需要用户注意。实现对话框比扩展用户界面往往要容易得多，因此对话框很容易被使用过度。

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

要设计高效的对话框，应当有效地使用下列元素：

最关键的一点：

确保你对话框的设计（由其作用、类型及用户操作决定）符合它的用途（由其内容、用户行动的可能性、以及显示的频率决定）。

更多信息及示例，参见对话框设计理念。

使用模式

对话框具有下列使用模式：

问题对话框（使用按钮）用于询问用户单个问题或确认某个命令，并通过一些横向排列的命令按钮提供一些简单的回应选项。
问题对话框（使用命令链接）用于询问用户单个问题或选择要执行的任务，并通过垂直排列的命令链接表示的详细回应选项。
选择对话框用于向用户提供一组选择，通常更完整地描述某个命令。与问题对话框不同，选择对话框可以提多个问题。
进度对话框用于在耗时操作（长于五秒）的过程中向用户提供进度反馈，并提供用于取消或停止操作的命令。
信息对话框用于显示用户需要的信息。

更多信息和示例，参见对话框使用模式。

设计规范

常规

不要使用可滚动的对话框。不要使用正常情况下需要使用滚动条才能完整查看的对话框。应当重新设计该对话框。考虑使用渐进展开或选项卡。
不要使用菜单栏或状态栏。相反，应当能够在对话框上直接访问命令或状态，或者在相关的控件上提供快捷菜单。
- 例外：当对话框用作实现主窗口时（例如用于实用程序）则可以使用菜单栏。

错误：

在这个示例中，Find Certificates（查找证书）是带有菜单栏的无模式对话框。

如果对话框需要用户的立即关注且程序并非当前活动程序时，应闪烁其任务栏按钮三次以引起注意，然后保持其高亮。不要有任何其他动作：不要恢复或激活该窗口，也不要播放任何声音效果。而是应当尊重用户的窗口状态选择，并让用户方便的时候激活窗口。

更多设计规范与示例，参见任务栏。

模式对话框

用于那些必须完成后才能继续的关键或不常见的、一次性的任务。
使用延迟提交模式以在明确提交之后再生效。
尽可能使用任务对话框来实现以取得统一的外观。任务对话框需要 Windows Vista 或更高版本，因此不适用于早期的 Windows 版本。

无模式对话框

用于频繁、反复、持续性的任务。
使用立即提交模式以立即生效。
对于无模式对话框来说，应当在对话框中使用显式的“关闭”命令按钮来关闭窗口。对于两者来说，都应当在标题栏上使用关闭按钮来关闭窗口。
考虑让无模式对话框能够停靠。可停靠的无模式对话框可以使位置更加灵活。

用于 Microsoft Office 的一些无模式对话框是可以停靠的。

多个对话框

不要同时显示来自同一个父选择对话框的多个子选择对话框。显示多个对话框会使得用户难以理解提交按钮的含义。你可能得根据需要显示其他类型的对话框（例如问题对话框）。
对于一系列相关的对话框来说，如果可能的话，可以考虑使用多页对话框。如果没有非常明确的关联的话，则应使用独立的对话框。

多页面对话框

当“相关”页面以下列顺序出现时，应当用多页对话框代替单独的多个对话框：
1. 单个输入页面（可选）
2. 进度页面
3. 单个结果页面

输入页面是可选的，因为该任务可能由其他位置引发。

这么做能够提供稳定、简单、轻量感的最终体验。

在这个示例中，Windows 网络诊断由进度和结果页面组成。

如果输入页面是标准对话框的话，则不要使用多页面对话框。这种情况下，使用标准对话框的一致性更为重要。
不要为不超过三页的对话框使用下一页或后退按钮。多页面对话框是用于带反馈的单步骤任务的。它们不是向导，向导是用于多步骤任务的。与多页面对话框相比，向导的界面更加复杂，间接感更强。
在输入页面中，应当使用明确的命令按钮或命令链接来启动任务。
在输入及进度页面中应当使用取消按钮，而在结果页面中使用关闭按钮。

致开发人员：你可以通过 TDM_NAVIGATE_PAGE 消息创建多页面任务对话框。

呈现

为使对话框易于查找和访问，应当将其明确关联到源，并在多显示器上正常使用：

对话框初次显示时，应将其“居中”显示在父窗口的上方。以后显示的时候，如果更为方便，应考虑将其显示在最后一次出现的位置（相对于父窗口）。

将对话框初始化居中显示在父窗口的上方。

如果窗口是上下文相关的，应当将其显示在靠近触发它的对象旁边。不过，应当把它放在靠旁边的位置（最好是向右下方一些），这样对象不会被窗口挡住。

对象属性显示在对象的旁边。

对于无模式对话框来说，应当初始化显示在父窗口的上方。如果用户激活了父窗口，则可能会隐藏无模式对话框。
如果必要的话，应当调整初始位置以使整个对话框可以显示在目标监视器上。如果可缩放窗口比目标监视器要大，则应当缩小以适合。
当对话框再次显示时，应当考虑以与上次访问相同的状态显示。当关闭时，保存使用的监视器、窗口尺寸、位置及状态（最大化或还原）。当再次显示时，恢复已保存的窗口尺寸、位置及状态，并使用合适的监视器。而且，考虑基于特定的用户，跨越各程序实例保留这些属性。
对于可缩放窗口，如果当尺寸低于某值时内容将不再可用的话，则应设置最小窗口尺寸。考虑更改呈现方式以保存内容可以用于更小的尺寸。

在这个示例中，Windows Media Player® 在因窗口太小而标准形式不再适用时，改变了它的形式。

不要使用“Always on Top（保持顶端）”属性。
- 例外：仅当对话框实现了必要的模式操作时才应使用，但它会被暂时搁置以访问父窗口。例如，当对文档进行拼写检查时，用户可能需要临时离开拼写检查对话框并访问文档以更正错误。

更多信息与示例，参见窗口管理。

标题栏

对话框没有标题栏图标。标题栏图标是视觉上用于区别主窗口辅助窗口的。
- 例外：如果对话框用于实现主要窗口（比如实用程序）且将显示在任务栏上的话，它确实应当包含标题栏图标。在这种情况下，应当对此标题为任务栏显示而优化，将具有辨别性的简要信息放在前面。
对话框应当始终具有关闭按钮。无模式对话框也可具有最小化按钮。可缩放对话框可具有最大化按钮。
不要禁用关闭按钮。具有关闭按钮可以让用户关闭他们不想要的窗口，有助于将控制权留给用户。
- 例外：对于进度对话框来说，如果必须完成整个任务以达到有效状态或防止数据丢失的话，你可以禁用关闭按钮。
标题栏上的关闭按钮应当与对话框内的取消或关闭按钮效果相同。不要让其与确定按钮效果相同。
如果标题栏文字与图标已经在靠近窗口顶端的显著位置显示的话，你可以隐藏标题栏文字和图标以避免重复。但是，你仍然应当设置合适的内部标题以为 Windows 所用。

交互

由用户启动的对话框在显示时应当始终具有输入焦点。由程序启动的对话框则不应具有输入焦点，因为用户可能正在操作其他窗口。这种因对话框误导的操作可能会产生非预期的结果。
将起始输入焦点赋予用户最有可能首先操作的控件，这往往是（但并不总是）第一个交互控件。
对于键盘导航来说，Tab 顺序应当遵循逻辑顺序，大体上是从左至右，从上至下。Tab 顺序通常遵循阅读顺序，但可以存在以下例外：
- 将最常用的控件的 Tab 顺序排得靠前一些。
- 在对话框底端放置帮助链接，Tab 顺序排在提交按钮之后。

当指定顺序时，假设用户打开对话框是为了其本来用途的。也就是说，例如，用户打开选择对话框是为了进行选择，而不是查看和单击取消。

单击 Esc 键应当始终关闭活动的对话框。对于带有取消或关闭的对话框来说确实如此，即使因结果不能再被撤销而将取消按钮被更名为关闭按钮后也同样适用。

访问键

尽可能为所有交互控件或其标签分配唯一的访问键。只读文本框也是交互控件（因为用户可以滚动并复制文本），因此它们也需要访问键。不要将访问键分配给：
- 确定、取消及关闭按钮。 Enter 及 Esc 键已经用作它们的访问键。但是，一定要给那些表示确定或取消，但标签文字不同的控件分配访问键。

在这个示例中，表示正面意义的提交按钮被分配了访问键。

- 分组框标签。通常，组内的控件会被单独分配访问键，因此组标签并不需要。但是，如果访问键不够用的话，可以为组标签分配访问键，而不是单独分配给每个控件。
- 普通帮助按钮，可通过 F1 键访问。
- 链接标签。通常链接太多，无法分配唯一的访问键，且链接下划线会隐藏访问键下划线。让用户改用 Tab 键访问链接。
- 选项卡名称。选项卡是通过 Ctrl+Tab 和 Ctrl+Shift+Tab 键来循环访问的。
- 标签为“...”的浏览按钮。这无法分配唯一的访问键。
- 没有标签的控件，如微调控件、图形命令按钮及没有标签的渐进展开控件。
- 无标签的静态文本或用于不可交互控件的标签，如进度条。
尽可能按照标准访问键分配表为经常使用的命令分配快捷键。很难使所有的访问键分配都保持一致，但对于经常使用的对话框来说最好如此。
先为提交按钮分配访问键以确保他们具有标准的访问键分配。如果确实无法使用标准访问键分配，则使用第一个单词的首字母。例如，用于 Yes（是）和 No（否）提交按钮的访问键应当始终是“Y”和“N”，无论对话框中其他的控件如何。
为使访问键易于查找，应当使用标签中较靠前的字符分配为访问键，最好是首字母，即使关键字是在标签较后的地方出现。
优先考虑较宽的字符，如 w、m 以及大写字母。
优先考虑独特的辅音或元音，如“Exit”中的“x”。
避免使用会导致下划线难以发现的字符，例如（从最严重到最轻）：
- 只有一个像素宽的字母，比如 i 和 l。
- 带有下伸部的字母，比如 g、j、p、q 和 y。
- 紧靠带有下伸部的字母的字母。

关于更多规范与示例，参见键盘。

进度对话框

对于长时间运行的任务来说，应假设用户会在任务进行过程中做其他的事情。将任务设计为无人参与的运行。

应在耗时操作（长于五秒）的过程中向用户提供进度反馈，并提供用于取消或停止操作的命令。
- 例如：对于向导及任务流程来说，仅当任务留在同一页面时（与进入下一页相对）或用户除了等待无事可做时，才为进度使用模式对话框。否则，则应使用进度页面或就地进度。
如果该操作是需要长时间运动的任务（超过 30 秒），且可以在后台执行的话，应当使用无模式进度对话框使得用户能够在等待过程中继续使用你的程序。
无模式进度对话框：
- 标题栏上具有最小化按钮。
- 始终显示在任务栏上。
应实现无模式进度对话框，使得即使父窗口关闭之后仍能继续运行。

在这个示例中，即使父窗口关闭，文件也会继续复制。

如果完成任务不止几秒钟，或者有可能永远无法完成的话，则应提供命令按钮用于中止操作。如果取消后能够回退到先前的状态（没有副作用）的话，则将按钮的标签写为“取消”，否则则写为“停止”以表示会已经完成的那部分操作的影响会持续存在。如果在某一时刻，不再可能将环境退回到先前的状态的话，你可以在操作进行的中途将按钮的标签从“取消”改为“停止”。

在这个示例中，中止问题诊断程序不会带来任何副作用。

如果完成某操作需要数分钟，且它会降低用户完成工作的能力时，应当提供一个命令按钮以暂停该操作。这么做不会强迫用户在完成任务和完成他们的工作之间进行选择。
应在任务开始前收集尽可能多的信息。
如果检测到可恢复的问题的话，应当在任务结束时让用户处理所有发现的问题。如果这不太现实的话，让用户在问题发生时进行处理。
不要因为出现了可以恢复的错误而重复执行任务。

在这个示例中，Windows Explorer 使用户在出现可恢复错误后能够继续任务。

通过将进度条变红来指示问题。

在这个示例中，文件复制的过程中，可移动磁盘被移除。

如果结果对于用户来说是显而易见的话，应当在成功完成之后自动关闭进度对话框。否则，仅在报告问题时给出反馈：
- 要显示简单反馈，则在进度对话框中显示反馈，并将取消按钮改为关闭。
- 要显示详细反馈，则关闭进度对话框并显示信息对话框。

不要将通知用于完成时的反馈。使用进度对话框，或者是操作成功通知，不要将两者同时使用。

剩余时间

使用下列时间格式。从下列格式中选择一个最大时间单位不是零的，然后当最大时间单位变成零时再更换为下一个格式。

对于进度条：

如果相关信息是以冒号格式显示的：

Time remaining: h hours, m minutes（剩余时间：h 小时 m 分）

Time remaining: m minutes, s seconds（剩余时间：m 分 s 秒）

Time remaining: s seconds（剩余时间：s 秒）

如果屏幕空间紧张：

h hrs, m mins remaining（剩余 h 小时 m 分）

m mins, s secs remaining（剩余 m 分 s 秒）

s seconds remaining（剩余 s 秒）

否则：

h hours, m minutes remaining（剩余 h 小时 m 分）

m minutes, s seconds remaining（剩余 m 分 s 秒）

s seconds remaining（剩余 s 秒）

对于标题栏：

hh:mm remaining（hh:mm 剩余）

mm:ss remaining（mm:ss 剩余）

0:ss remaining（0:ss 剩余）

该精简格式先显示最重要的信息，以使其不会在任务栏上被截断。

估算要准确，但不要给出错误的精度。如果最大单位是小时，那么应当给出分钟数（如果有意义的话）而不是秒数。

错误：

hh hours, mm minutes, ss seconds（hh 小时 mm 分 ss 秒）

保持估算值是最新的。至少每隔 5 秒更新一次估计剩余时间。
关注剩余时间，因为这是用户最关心的信息。仅当经过的总时间有意义的情况下（如该操作可能会重复进行）才给出经过的总时间。如果估计剩余时间和进度条一起使用的话，则不要提供完成百分比文本，因为该信息已经由进度条本身传达了。
使用正确的语法。当数值为 1 时使用单数形式。

错误：

1 minutes, 1 seconds

使用句子大写样式。

更多信息与示例，参见进度条。

图标与图形

图形

不要使用那些除了填充空白、华而不实而没有任何实际意义的大尺寸图形。应当保持简单的外观。

错误：

在这个示例中，大尺寸图形没有任何实际意义。

标题栏图标

对话框没有标题栏图标。
- 例外：如果对话框用于实现主要窗口（比如实用程序）且将显示在任务栏上的话，它确实应当包含标题栏图标。

主体图标（body icon）

应基于设计模式选用主体图标：

模式
主体图标

问题对话框
程序、功能、对象、警告图标（如果可能丢失数据或无法访问系统）、安全警告或无。

选择对话框
无。

进度对话框
无（但可以使用动画）。

信息对话框
无。

错误：

在这个示例中，警告图标错误地被用于与可能丢失数据或无法访问系统无关的问题。

考虑使用图标帮助用户从视觉上认出你程序的功能。该技术当图标易于识别且在你的程序中多次使用时最为有效。

在这个示例中，黄色的星形图标表示收藏夹。该图标很容易识别，而且在整个 Windows 中始终用于表示收藏夹。

用图标帮助用户识别问题中的对象。

在这个示例中，对象的图标能够帮助用户识别要打开或保存的文件类型。

考虑使用图标使功能具备自描述性。

在这个示例中，这些图标帮助用户将这些功能视觉化。

在关于对话框中用图标来宣传应用程序的品牌。

在这个示例中，关于对话框中使用了一个位图来标识和宣传应用程序的品牌。

脚注图标

如果你使用脚注，考虑使用脚注图标来对脚注内容进行总结。

在这个示例中，脚注图标指出该问题会对安全性产生影响。

脚注图标不要与正文图标重复。
不要使用错误或信息标准图标。错误情况必须通过正文图标来传送，而脚注则始终用于传达信息，因此信息图标是多余的。不过，你可以使用标准警告图标和黄色盾牌符号来警告用户可能存在的风险。

更多信息和示例，参见图标。

提交按钮

注意：

这些设计规范不适用于使用命令链接的问题对话框，因为该模式用命令链接代替了按钮。
[做某事] 和 [不做某事] 分别是指针对主标题说明的肯定与否定回答。

常规

根据设计模式选择提交按钮：

模式
提交按钮

问题对话框（使用按钮）
使用下列简要命令组合之一：是/否、是/否/取消、[做某事]/取消、[做某事]/[不做某事]、[做某事]/[不做某事]/取消。

问题对话框（使用链接）
取消。

选择对话框

模式对话框：确定/取消或 [做某事]/取消
无模式对话框：对话框及标题栏上的关闭按钮
任务窗格：标题栏上的关闭按钮

进度对话框
如果能退回之前的状态（没有任何副作用）则用“取消”，否则用“停止”。

信息对话框
关闭

除“应用”以外的所有提交按钮都应当关闭对话框窗口。
不要对提交按钮再进行确认。这么做没有必要而且令人厌烦。

例外：

- 该操作可能会导致灾难性后果。
- 该操作与其他操作明显不一致。
- 如果操作错误，该操作可能会导致严重的数据丢失，以及用户的时间与精力的损失。

更多设计规范与示例，参见确认信息。

不要禁用提交按钮。关于例外情况，参见禁用或移除控件 vs 给出错误信息。
将提交按钮向右对齐排成一行，置于对话框的底部，但位于脚注区域上方。即使只有一个提交按钮（比如确定）也应当如此。

错误：

在这个示例中，确定按钮错误地居中了。

应当以下列顺序呈现提交按钮：
1. 确定/[做某事]/是
2. [不做某事]/否
3. 取消
4. 应用（如果有的话）
5. 帮助（如果有的话）
如果有大量相关的提交按钮，应用分割按钮来进行组合。
提交按钮（会关闭窗口的）与所有其他命令按钮（比如“高级”）之间应当有明显的分隔。

回应主标题说明

使用肯定语气的、明确回应了主标题说明的提交按钮，而不要使用含义模糊的标签（如“确定”）。用户仅仅阅读按钮文字就应当能够快速地理解选项。例外：
- 对于没有设置的对话框使用“Close（关闭）”，如信息对话框。绝不要为具有设置的对话框使用“关闭”。
- 当针对性的回答仍然很一般时可以使用“OK（确定）”，如“Save（保存）”、“Select（选择）”或“Choose（选择）”。在更改某个特定设置或一组设置时使用“确定”。
- 对于没有主标题说明的老式对话框，你可以使用常规的标签，如“OK（确定）”。这类对话框往往不是为了完成特定任务而设计的，避免使用过于针对性的回应。
- 有些任务需要用户进行思考和仔细阅读以做出合理的选择。这往往出现在有确认信息的情况。在这种情况下，你可以故意使用常规的提交按钮标签来强迫用户阅读主标题说明，以避免仓促做出决定。

正确：

在这个示例中，使用 Yes（是）/No（否）提交按钮以强迫用户至少阅读主标题说明。

- 或者，你可以为表示肯定的提交按钮标签添加“anyway（仍然）”一词以表明该对话框给出了不继续进行的理由而且用户在继续之前应当仔细阅读该对话框。

正确：

在这个示例中，提交按钮标签中加上了“anyway（仍然）”以表明用户应当仔细进行。

对于表示否定的提交按钮，应当使用“取消”或“关闭”，而不要使用针对主标题说明的回应。用户往往会在一看到对话框之后意识到并不想完成某个任务。如果“取消”或“关闭”被写成其他明确的回应，用户可能需要仔细阅读所有提交按钮才能确定应当如何取消。统一将其标签写为“取消”和“关闭”使其易于查找。例外：
- 不要使用“是/取消”。始终成对使用“是/否”。
- 当“取消”有歧义时应使用有针对性的回应。关于更多信息，参见用于简接对话框的提交按钮。
不要在内容区域的文本中将特殊含义映射到常规标签上。相反，应当使用有针对性的提交按钮标签，或当标签太长时使用带链接的问题对话框。

错误：

在这个示例中，OK（确定）被映射为“继续”，Cancel（取消）被映射为“留在该页面”。

是否按钮

最好使用有针对性的回答，而不是“是”“否”按钮。虽然使用“是”和“否”并没有什么问题，但有针对性的回答理解起来更快，做决定的效率也更高。不过，确认信息通常使用“是”“否”按钮以使用户在做出回应之前能够进行思考。
仅用“是”和“否”按钮来回答是否判断问题。应当自然地将主标题说明表述为是非问句。不要使用“确定”和“取消”来回答是否判断问题。

错误：

正确：

更好：

在这些示例中，“是”和“否”对于是非问句来说是好的回答，但有针对性的回答则更好。

如果使用针对性表述的提交按钮可能会太长或显得奇怪的话，可以考虑将主标题说明表述为是非问句。另外，你可以使用命令链接来对主标题说明给出较长的回应（超过 5 个单词）。

错误：

正确：

在错误示例中，针对性的表述太长，正确的示例则使用了“是”和“否”。

如果“否”的含义不明确的话，则不要使用“是”和“否”按钮。此时应当改用有针对性的回应。

确定按钮

在模式对话框中，单击“确定”意味着应用所有的值、完成任务并关闭窗口。
不要用“确定”按钮来回答问题。
不要为“确定”按钮分配访问键，因为 Enter 键即是默认按钮的访问键。这可使其他访问键更易于分配。
正确标注“确定（OK）”按钮。OK 按钮应当被标为“OK”，而不是“Ok”或“Okay”。
不要为错误或警告信息使用“确定（OK）”按钮。出了问题一点也不 OK。应当改用“关闭（Close）”。

错误：

在这个示例中，OK 应当被改为 Close。

不要在无模式对话框中使用“确定”按钮。相反，无模式对话框应当使用针对任务的提交按钮（如“查找”）。不过，有些无模式对话框只需要一个“关闭（Close）”按钮。

取消按钮

单击“取消”意味着丢弃所有更改、取消任务、关闭窗口并将环境退回到先前的状态，没有任何副作用。对于嵌套的选项对话框来说，在父选项对话框中单击“取消”意味着任何子选项对话框中进行的修改也都会丢弃。
提供“取消”按钮以使用户能够明确地放弃更改。对话框需要一个明确的退出点。不要指望让用户找到标题栏上的关闭按钮。
- 例外：不要为不包含设置的对话框提供“取消”按钮。此时，“确定”和“关闭”按钮与“取消”按钮的效果是一样的。

错误：

在这个示例中，仅在标题栏上有一个关闭按钮看起来似乎用户没有选择的余地。

不要将“取消”按钮用于回答疑问句。

错误：

在这个示例中，错误地用“确定”和“取消”按钮来回答是非问题。

不要将访问键分配给取消按钮，因为 Esc 键即是其访问键。这可以使其他访问键更容易分配。
不要在无模式对话框中使用“取消”按钮。而应当改用“关闭”。
不要禁用“取消”按钮。用户应当能够随时取消对话框。
- 例外：在进度对话框中，如果操作在某个阶段内无法被取消的话，可以禁用“取消”按钮。但是，更好的解决方案是将这类操作设计为始终可被取消。

关闭按钮

为无模式对话框以及那些无法取消的模式对话框使用“关闭”按钮。
单击“关闭”意味着关闭对话框窗口，保留所有已经生效的设置。不要使用“完成（Done）”，因为这不是一个祈使结构。对于嵌套的选项对话框，在父选项对话框中单击“关闭”意味着所有子选项对话框中进行的修改都将得以保留。
在对话框内放置一个明确的“关闭”按钮。对话框需要一个明确的退出点。不要指望让用户找到标题栏上的关闭按钮。
确保标题栏上的“关闭”按钮与“取消”或“关闭”按钮具有同样的效果。
不要为“关闭”按钮分配访问键，因为 Esc 即是它的访问键。这可以使其他访问键更容易分配。

应用按钮

不要在非属性表对话框中使用“应用”按钮。“应用”按钮表示应用那些未生效的更改，但仍保持窗口打开。这使用户能够在关闭窗口之前看到更改的效果。但是，只有属性表才有这样的需要。

错误：

在这个示例中，选项对话框中存在多余的“应用”按钮。

间接对话框的提交按钮

注：间接对话框是脱离上下文出现的，要么是某任务的间接结果，要么是系统或后台进程出现了问题而导致的。对于间接对话框来说，“取消”按钮存在歧义，因为它既可以表示取消该对话框，也可以表示取消整个任务。

如果用户需要同时取消对话框和任务，应当提供这样的提交按钮。将取消对话框的按钮标注为对主标题说明的否定回答。将取消整个任务的按钮标注为“取消”。使用“取消”使对话框能够适用于不同的环境。

正确：

在这个示例中，如果 Windows 画图中的图像未保存时执行了“新建”或“退出”命令的话，则会显示该对话框。“Don't Save（不保存）”则不进行保存并关闭对话框，而“Cancel（取消）”则取消的是“新建”或“退出”命令。

错误：

在这个示例中，没有办法取消显示该对话框的任务（关闭 Office 快捷方式栏）。该对话框需要一个“取消”按钮。

如果用户只需要取消对话框而非整个任务的话，应当使用明确针对主标题说明的否定回答按钮，并不要使用“取消”按钮。

在这个示例中，该对话框是因为访问了要安装 ActiveX 控件的网页而间接显示的。使用“取消”可能会产生歧义，因而改用“Don't run（不运行）”。

更多信息和示例，参见命令按钮。

命令链接

应用命令链接来呈现一组文本较长的命令，以代替命令按钮或是选项按钮与确定按钮的组合。这可以使用户回答时只需单击一次。不过，该方式仅适用于单个问题的情况。
将最常用的命令链接放在前面。最后的顺序应当大致符合被用到的可能性，当然也应当具有逻辑顺序。
- 例外：那些什么都做的命令链接应当被放在最前面。
如果某命令链接需要进一步的解释，则应提供补充说明。补充说明描述了用户为什么可能需要选择该项或是选择该项之后会发生什么。
不要使用仅仅在字面上将命令链接进行重新表述的补充说明。仅当你无法使命令能够自我描述时才应使用补充说明。为某个命令链接提供补充说明并不代表所有命令都需要。

在这个示例中，补充说明描述了该选项的影响。

使用以动词开头的短语，不带句末标点。
如果一个选项是强烈推荐的，应当在标签中添加“(recommended)”/“（推荐）”字样。确保添加至控件标签，而不是附加说明。
如果一个选项是仅为高级用户设计的，应当在标签中添加“(advanced)”/“（高级）”字样。确保添加至控件标签，而不是附加说明。
提供明确的取消按钮。不要为此种用途使用命令链接。

错误：

在这个示例中，对话框使用命令链接来代替“取消”按钮。

更多信息和示例，参见命令链接。

不要再显示此 <项>

考虑使用“不要再显示此 <项>”的选项，以让用户能够禁用一个重复出现的对话框，但仅适用于没有更好的其他途径时。最好是只在用户真正需要它的时候才显示该对话框，或者如果用户不需要的话干脆把它去掉。
将 <项> 替换为特定的名称。例如，“不要再显示此提醒”。当泛指对话框时，应使用“不要再显示此消息。”
明确指出用户输入的内容将在未来用作默认值，在选项下方添加这样一句话：“你的选择会用作未来的默认值。”
不要默认选中该选项。如果该对话框确实只需要显示一次，就直接这么做，不需要询问。不要将此选项用作侵扰用户的借口——确保默认的行为不会侵扰用户。

错误：

在这个示例中，该消息应当仅显示一次，没有问的必要。

该设置应当基于特定的用户。
如果用户选中该项之后又单击“取消”，该选项仍应“生效”。该设置是基元选项（meta-option），不遵循标准的取消行为——没有任何副作用。要知道如果用户不希望再看到该对话框，他们多半也会要取消它。
如果用户可能需要还原这些对话框的话，应当在程序的选项对话框中提供还原消息（Restore messages）选项。

更多信息，参见设计理念中的使用“不要再显示该 <项>”选项。

稍候询问

仅在下列情况下提供消除该对话框的选项：
- 该对话框是间接的，因此用户可能会将注意力集中在其他任务上。
- 用户必须立即回应，然后才可继续工作。
- 该问题需要继续思考或操作，用户可能需要多一些时间来决定。
- 该对话框或选项将在稍候自动出现（即确实会稍候询问用户）。

错误：

在这个示例中，该问题非常简单，加上“Ask me later（稍候询问）”选项只会让它变得更复杂。

否则，期望用户立即回应，但也让其能够通过“取消”或“关闭”来关闭该对话框。如果使用恰当，该选项应当很少出现。

脚注

将脚注用于那些对于对话框本身用途来说并非必须，而可能有助于用户进行决定的信息。大多数用户在回应对话框时，即使跳过脚注也应能做出合适的决定。

在这个示例中，脚注信息是补充性质的，而非必要的。

禁用或移除控件 vs 给出错误信息

当某控件不适用于当前上下文时，考虑以下选项：
- 如果用户无法使其可用，或用户不认为它适用且其状态不会频繁更改的话，应移除该控件。这能够简化对话框，且用户不会感到不妥。让控件反复出现或消失是很让人厌烦的。
- 当用户认为它是适用的或者它的状态会频繁更改，且用户很容易就能推理出控件为什么不可用的话，应当禁用该控件。因一个必填文本框为空而禁用了提交按钮即是一个容易推理的例子。你可以为文本框和可编辑下拉列表中使用气球状提示来显示非关键的用户输入错误。不过，如果该问题无法通过气球状提示来解释，或者涉及多个控件时，推理就不那么容易了。
- 其他情况下，保持控件可用，当它被错误使用的时候给出错误信息。在这类情况下，禁用控件可能会使用户难以理解为什么控件会被禁用。用户可能会被迫通过反复尝试和推理来确定问题所在。如果提供有帮助的错误信息来明确解释问题则会更好些。
提示：如果你无法确定应该禁用控件还是提供错误信息的话，可以先试着写要给出的错误信息。如果该错误信息包含目标用户无法快速得出的有用信息的话，则保持控件可用并提供错误信息。否则的话，禁用该控件。
如果禁用控件，则应同时禁用附属的控件，例如其标签、补充说明或命令按钮等。不过，不要禁用其分组框（如果有的话）。

必填项

要表明用户必须在控件中提供信息，可考虑以下方式：
- 什么也不说明，但在必填项未填时提供错误信息。这种方式可以减少视觉混乱，如果大多数内容都是选填的或者用户不太会跳过的话比较适用。这可以保持错误信息的数量较少。
- 在必填项的标签前部用星号标出。以下列方式之一来解释星号的作用：
  - 在内容区域底部的脚注部分注明“* 必填项”。
  - 在星号的工具提示上注明“必填项”。

当必填项数量不多时，该方式较为适用，但如果大多数都是必填项则不太合适。

在这个示例中，星号用于标识必填项。

- 在可选项的标签后用“(optional)”（“（可选填）”）注明。当大多数都是必填项时，该方式较为适用，但如果大多数都是选填项时则不太合适。
为了保持统一，尽量在整个程序中使用相同的方法来标明必填项。具体地说，可以根据需要标明必填项或者选填项，但不要在同一个程序中两种同时使用。

错误处理

可通过使用仅接受有效用户输入的控件来防止出现错误。你也可以通过提供合理的默认值来帮助减少错误的数量。
尽早验证用户输入，并将错误显示在尽可能靠近输入点的位置。
对于用户输入中存在的问题使用无模式的错误处理方式（就地错误提示或气球状提示）。
- 当在文本框中或者文本框刚刚失去焦点时检测到非关键的单点用户输入错误时，应使用气球状提示。气球状提示不需要预留屏幕空间或者动态布局来显示就地信息。每次只显示一个气球状提示。因为问题并不关键，所以无须使用错误图标。单击后、或者问题被解决、或者超时之后，气球状提示将消失。

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

- 为延后错误检测使用就地错误信息，这类错误通常是在单击提交按钮后被发现。（不要为那些立即提交的设置使用就地错误信息。）一次可以显示多个就地错误信息。使用普通文本以及 16x16 像素的错误图标。就地错误信息不会消失，除非用户再次提交且没有出现其他错误。

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

其他所有情况，应使用模式错误处理（任务对话框或消息框），包括涉及多个控件的错误、或者在单击提交按钮后发现的非上下文相关的或非输入错误。
当发现并报告输入问题之后，应当将输入焦点置于包含错误数据的第一个控件上。如果需要的话，滚动屏幕使控件进入可见区域。

更多信息和示例，参见错误信息和气球状提示。

帮助

当向用户提供帮助时，考虑下列方案（以优先程度列出）：
- 为交互控件提供自描述标签。相对于其他文本来说，用户更有可能阅读交互控件上的文本。
- 用静态文本标签提供基于上下文的详细说明。
- 提供明确指向相关帮助主题的帮助链接。

Locate Help links at the bottom of the content area of the dialog box. If the dialog box has a footnote and the Help link is related to it, place the Help link within the footnote.

In this example, the Help link applies to the entire dialog.

- Exception: If a dialog box has several distinct groups of settings that have separate Help topics (perhaps within group boxes), locate the Help links at the bottom of the groups.
Don't use general or vague Help topic links or generic Help buttons. Users often ignore generic Help.

For more information and examples, see Help.

Default values

Include a default commit button on every dialog box.
For question dialogs:
- 将最可靠（防止数据丢失或系统访问）且最安全的选项作为默认值。如果可靠性或安全性不是需要考虑的因素，则选择最常用或最方便的选项。
  - Exception: Don't make a destructive response the default unless there is an easy, obvious way to undo the command.
For choice dialogs:
- For the initial default values, select the safest (to prevent loss of data or system access) and most secure values for each control. If safety and security aren't factors, select the most likely or convenient options.
- For the subsequent default values, reselect the previously selected options if those values are likely to be repeated, and doing so is safe and secure. Otherwise, select the initial default values.

In this example, users are most likely to choose the same printing settings as they did last time. However, the number of copies desired is likely to change, so this setting isn't reselected.

Text

General

Remove redundant text. Look for redundant text in titles, main instructions, supplemental instructions, content areas, command links, and commit buttons. Generally, leave full text in instructions and interactive controls, and remove any redundancy from the other places.
Use positive phrasing. Positive phrasing is easier for users to understand.

Correct:

Do you want to enable file and printer sharing?

Incorrect:

Do you want to disable file and printer sharing?

However, phrasing must match the associated command, even if the command is negatively phrased; so, for example, use disable to confirm a Disable command.

If necessary, use the word "window" to refer to the dialog box 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.

Examples:

Choose the pictures you want to print

Choose an account

Use the first person ("I/me/my") to let users tell the program what to do in controls in the content area that respond to the main instruction.

Example: Print the photos on my camera.

Dialog box titles

Use the title to identify the command, feature, or program where a dialog box came from.
- If dialog is user initiated, identify it using the command or feature name. Exceptions:
  - If a dialog box is displayed by many different commands, consider using the program name instead.
  - If that title would be redundant with the main instruction, use the program name instead.
- If it is program or system initiated (and therefore out of context), identify it using the program or feature name to give context.
- Don't use the title to explain what to do in the dialog—that's the purpose of the main instruction.
Use the exact command name for command-based names, but don't include the ellipsis if there is one. You can include the command's menu title if necessary to compose a good title. Example: for an Object... command in an Insert menu, use the title Insert Object.
If a modeless dialog box appears on the taskbar, optimize the title for display on the taskbar by concisely placing the distinguishing information first. Examples:

"66% Complete," and "3 Reminders."

Don't include the words "dialog" or "progress" in the title. This is implied, and leaving it off makes it easier for users to scan.
Use title-style capitalization, without ending punctuation.

Main instructions

使用主标题说明来简要地解释一个页面或对话框用来做什么。好的主标题说明传达的是用户的目标，而不只是关注于操作用户界面。
Omit the main instruction when the only thing you can say is obvious. In such cases, the content of the dialog box is self-explanatory. For example, the File Open and File Save common dialogs don't need a main instruction because their context and design make their purpose obvious.
Omit control labels that restate the main instruction. In this case, the main instruction takes the access key.

Acceptable:

In this example, the text box label is just a restatement of the main instruction.

Better:

In this example, the redundant label is removed, so the main instruction takes the access key.

保持简洁——只使用一个完整的句子。简化主标题说明，只保留最基本的信息。如果你还需要进一步解释，考虑使用辅助说明。
尽可能使用明确的动词。对于用户来说，明确的动词（如：链接、保存、安装）比常规动词（如：配置、管理、设置）更加有意义。
使用句子大写样式。
如果主标题说明文本是陈述句的话，不要在末尾使用句号。但如果说明文本是问句的话，则需要在末尾添加问号。
对于进度对话框，应当使用动名词短语来简要地说明正在进行的操作，并以省略号结尾。例如：“Printing your pictures...（正在打印图片...）”。
提示：你可以想像你会和你的朋友说些什么，以此来评估主标题说明。如果对主标题说明的回应可能不自然、无用或者显得古怪，应当重写该说明文字。

Supplemental instructions

必要时，使用可选的辅助说明来呈现有助于理解和使用该窗口或页面的附加信息。你可以提供更加详细的信息并定义术语。
如果该对话框是由程序或系统触发的（因此脱离了上下文），应使用辅助说明来解释该对话框为何出现。对于这类对话框，其上下文通常并不明显。
不要在其他地方以相似的措辞重复主标题说明。相反，如果没有什么需要补充的话，就省略辅助说明。
使用带句末标点的完整句子，并使用句子大写样式。

Command links

Choose concise link text that clearly communicates and differentiates what the command 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 command links with a verb.
Use sentence-style capitalization.
Don't use ending punctuation.
If necessary, provide any further explanation using complete sentences and ending punctuation. However, add such explanations only when needed—don't add explanations to all command links just because one command link needs one.

For more information and examples, see Command Link guidelines.

Commit buttons

Use specific commit button labels that make sense on their own and are a response to 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.
Start commit button labels with a verb. Exceptions are OK, Yes, and No.
Use sentence-style capitalization.
Don't use ending punctuation.
分配唯一的访问键。
- 例外：不要将访问键分配给确定和取消按钮，因为 Enter 及 Esc 键即是它们的访问键。这么做会使其他访问键更容易分配。

Documentation

When referring to dialog boxes:

In programming and other technical documentation, refer to dialog boxes as dialog boxes. Everywhere else, refer to dialog boxes by their title. If the title bar is hidden, refer to the dialog using the main instruction.
If you must refer to a dialog box in general, use window in user documentation. You can refer to a simple question dialog or confirmation as a message.
Use the exact title or main instruction text, including its capitalization.
When possible, format the title using bold text. Otherwise, put the title in quotation marks only if required to prevent confusion.

Example: In Windows Security, click More Options.

Quote: http://www.uxguide.net/wiki/windows:Windows/dialog-boxes#.E6.8F.90.E4.BA.A4.E6.8C.89.E9.92.AE

刷新页面返回顶部

Fung

公告