Windows 7 对话框（设计基础知识）

注意

此设计指南是为 Windows 7 创建的，尚未针对更高版本的 Windows 进行更新。 原则上大部分准则仍适用，但演示和示例没有反映我们的当前设计准则。

对话框是一个辅助窗口，允许用户执行命令、询问用户问题或为用户提供信息或进度反馈。

典型对话框。

对话框由标题栏（用于标识对话框所在的命令、功能或程序）、可选的主指令（用于解释用户的目标与对话框）、内容区域中的各种控件（显示选项）和提交按钮（指示用户希望如何提交任务）。

对话框有两种基本类型：

• 模式对话框要求用户在继续所有者窗口之前完成并关闭。 这些对话框最适合在继续之前需要完成的关键任务或不频繁的一次性任务。
• 无模式对话框允许用户根据需要在对话框和所有者窗口之间切换。 这些对话框最适合用于频繁、重复、正在进行的任务。

任务对话框是使用任务对话应用程序编程接口 (API) 实现的对话框。 它们由以下部分组成，这些部件可以组合在各种组合中：

• 用于标识对话框所在的应用程序或系统功能的标题栏。
• 包含可选图标的主要说明，用于通过对话框标识用户的目标。
• 描述性信息和控件的内容区域。
• 提交按钮的命令区域，包括“取消”按钮和可选的“更多”选项，以及“不再次显示此项”<>控件。
• 用于可选附加说明和帮助的脚注区域，通常针对不太有经验的用户。

典型的任务对话框。

无论何时适当，都建议使用任务对话框，因为它们易于创建，并可以实现一致的外观。 任务对话框确实需要 Windows Vista 或更高版本，因此它们不适用于早期版本的 Microsoft Windows。

任务窗格类似于对话框，只是它显示在窗口窗格中，而不是单独的窗口。 因此，任务窗格具有比对话框更直接、更有上下文的感觉。 尽管从技术上说它们不一样，但任务窗格与对话框非常相似，因此本文中提供了其指南。

典型的任务窗格。

属性窗口是一种专用的对话框类型，用于查看和更改对象、对象集合或程序的属性。 此外，属性窗口通常支持多个任务，而对话框通常支持任务中的单个任务或步骤。 由于它们的用法是专用的，因此属性窗口包含在一组不同的指南中。

对话框可以具有选项卡，如果有，则称为选项卡式对话框。 属性窗口由属性的呈现决定，而不是通过使用选项卡。

注意：与布局、窗口管理、常见对话框、属性窗口、向导、确认、错误消息和警告消息相关的指南显示在单独的文章中。

这是正确的用户界面吗？

在决定之前，请考虑以下问题：

• 目的是为用户提供信息、询问用户问题或允许用户选择执行命令或任务的选项吗？ 如果不是，请使用另一个用户界面 (UI)。
• 目的是查看和更改对象、对象集合或程序的属性吗？ 如果是，请改用属性窗口或工具栏。
• 目的是提供命令或工具集合吗？ 如果是，请使用工具栏或调色板窗口。
• 目的是验证用户是否要继续执行操作吗？ 是否有明确的理由和合理的机会不继续，有时用户没有这些？ 如果是，请使用确认。
• 目的是提供错误或警告消息吗？ 如果是，请使用错误消息或警告消息。
• 目的是：
  • 打开文件
  • 保存文件
  • 打开文件夹
  • 查找或替换文本
  • 打印文档
  • 选择打印页的属性
  • 选择字体
  • 选择颜色
  • 浏览文件、文件夹、计算机或打印机
  • 在 Microsoft Active Directory 中搜索用户、计算机或组
  • 是输入用户名和密码的提示吗？

如果是，请改用相应的常见对话框。 其中许多常见对话框是可扩展的。

• 目的是执行需要多个窗口的多步骤任务吗？ 如果是，请改用任务流或向导。
• 目的是通知用户与当前用户活动无关、不需要立即用户操作，用户可以自由忽略的系统或程序事件吗？ 如果是，请改用通知。
• 目的是显示程序状态吗？ 如果是，请改用状态栏。
• 最好使用就地 UI 吗？ 对话框可能会通过要求注意来破坏用户的流。 有时，流中断是合理的，例如，用户必须执行当前上下文之外的操作。 在其他情况下，更好的方法是在上下文中呈现 UI，无论是直接使用就地 UI（如任务窗格），还是按需使用渐进式披露。
• 目的是显示非关键用户输入问题或特殊条件吗？ 如果是，请改用气球。
• 对于任务流，最好使用另一页吗？ 通常希望任务在单个窗口中从页面流向页面。 使用对话框确认就地命令、获取就地命令的输入，以及执行独立完成的辅助独立任务，这些任务最好是在主任务流之外完成的。
• 对于选择选项，用户是否可能会更改这些选项？ 如果不是，请考虑替代方法，例如：
  • 在不询问的情况下使用默认选项，但允许用户稍后进行更改。
  • 提供包含选项的版本（例如，在菜单中打印……）以及不包含选项的版本（例如，在工具栏中打印）。 通常工具栏命令应是即时的，避免显示对话框。
• 对于选择选项，是否有更简单、更直接的方式来显示选项？ 如果是，请考虑替代方法，例如：
  • 使用拆分按钮选择命令的变体。
  • 对命令、复选框、单选按钮和简单列表使用子菜单。

在这些示例中，子菜单替代对话框，用于简单选择。

设计概念

正确使用时，对话框是为程序提供力量和灵活性的好方法。 滥用时，对话框是一种容易惹恼用户、中断其流并使人感觉程序使用间接和繁琐的方法。 模式对话框需要用户注意。 对话框通常比替代 UI 更容易实现，因此它们往往过度使用。

当对话框的设计特征与其用法匹配时，对话框最有效。 对话框的设计在很大程度上取决于其用途（提供选项、提问、提供信息或反馈）、类型（模式或非模式的）和用户交互（必需、可选响应或确认），而其用法主要取决于其上下文（用户或程序启动）、用户操作的概率和显示频率。

若要设计有效的对话框，请有效地使用以下元素：

• 对话框文本
• 主要说明
• 不要再次显示此项<>选项

如果你只做一件事……

确保对话框设计（由其用途、类型和用户交互确定）与其使用情况匹配（由其上下文、用户操作概率和显示频率确定）。

使用模式

对话框有多个使用模式：

• 问题对话框（使用按钮）询问用户单个问题或确认命令，并在水平排列的命令按钮中使用简单的响应。
• 问题对话框（使用命令链接）询问用户单个问题或选择要执行的任务，并在垂直排列的命令链接中使用详细响应。
• 选择对话框向用户提供一组选项，通常更完整地指定命令。 与问题对话框不同，选择对话框可以提出多个问题。
• 进度对话框在长时间的操作（超过 5 秒）期间向用户显示进度反馈，以及用于取消或停止操作的命令。
• 信息对话框显示用户请求的信息。

准则

常规

• 不要使用可滚动的对话框。 不要使用要求在正常使用期间需要使用滚动条才能完全查看的对话框。 请改为重新设计对话框。 请考虑使用渐进式披露或选项卡。

• 不要包含菜单栏或状态栏。 而是直接在对话框本身或使用相关控件上的上下文菜单来访问命令和状态。

  • 例外：当对话框用于实现主窗口（如实用工具）时，菜单栏是可接受的。

  错误：

  

  在此示例中，“查找证书”是带有菜单栏的无模式对话框。

• 如果对话框需要立即注意且程序未处于活动状态，闪烁其任务栏按钮三次以吸引注意力，并使其保持突出显示状态。请勿执行任何其他操作：请勿还原或激活窗口，也不要播放任何声音效果。 相反，尊重用户的窗口状态选择，并让用户在准备就绪时激活窗口。

• 有关更多指南和示例，请参阅任务栏。

模式对话框

• 用于在继续之前需要完成的关键任务或不频繁的一次性任务。
• 使用延迟提交模型，使更改在显式提交之前不会生效。
• 在适当的时候使用任务对话框实现一致的外观。 任务对话框确实需要 Windows Vista 或更高版本，因此它们不适用于早期版本的 Windows。

无模式对话框

• 用于频繁、重复、正在进行的任务。
• 使用即时提交模型，使更改立即生效。
• 对于无模式对话框，请使用对话框中的显式“关闭”命令按钮关闭窗口。 对于这两者，请使用标题栏上的“关闭”按钮关闭窗口。
• 请考虑使无模式对话框可停靠。 可停靠的无模式对话框允许更灵活的放置。

Microsoft 办公室中使用的某些无模式对话框是可停靠的。

多个对话框

• 不要从所有者选择对话框一次显示多个拥有的选择对话框。 显示多个对话框会使用户难以理解提交按钮的含义。 可以根据需要显示其他类型的对话框（如问题对话框）。
• 对于相关对话框序列，请考虑尽可能使用多页对话。 如果各个对话框不明确相关，请使用单个对话框。

多页对话框

• 如果具有以下相关页面序列，请使用多页对话框，而不是单个对话框：
  • 单个输入页（可选）
  • 进度页
  • 单个结果页

输入页是可选的，因为任务可能已在其他位置启动。 这样做使生成的体验具有稳定、简单、轻量的感觉。

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

• 如果输入页是标准对话框，请不要使用多页对话框。 在这种情况下，使用标准对话框的一致性更为重要。
• 不要使用“下一步”或“后退”按钮，并且不要使用三个以上的页面。 多页对话框适用于具有反馈的单步任务。 它们不是用于多步骤任务的向导。 与多页对话框相比，向导具有繁重、间接的感觉。
• 在输入页上，使用特定的命令按钮或命令链接来启动任务。
• 使用输入和进度页上的“取消”按钮和结果页上的“关闭”按钮。

开发人员：可以使用 TDM_NAVIGATE_PAGE 消息创建多页任务对话框。

呈现

若要使对话框易于查找和访问，请将对话框与其源明确关联，并很好地处理多个监视器：

• 最初在所有者窗口顶部显示“居中”对话框。 对于后续显示，如果这样做可能更方便，请考虑将其显示在其最后一个位置（相对于所有者窗口）。

最初在所有者窗口顶部居中对话框。

• 如果对话框具有上下文，则将其显示在启动对话框的对象附近。 但是，将其放在一边（最好是向下偏移和向右偏移），以免对话框覆盖对象。

对象的属性显示在对象附近。

• 对于无模式对话框，最初显示在所有者窗口顶部，以便轻松查找。 如果用户激活所有者窗口，则可能掩盖无模式对话框。
• 如有必要，请调整初始位置，使整个对话框在目标监视器中可见。 如果可调整大小的窗口大于目标监视器，请缩小以适应。
• 重新显示对话框时，请考虑将其显示为与上次访问的状态相同。 关闭时，保存使用的监视器、窗口大小、位置和状态（最大化与还原）。 在重播时，使用相应的监视器还原保存的对话框大小、位置和状态。 此外，请考虑使这些属性在按用户的基础上跨程序实例保留。
• 对于可调整大小的窗口，如果低于某个尺寸时内容不可用，请设置最小窗口大小。 请考虑更改呈现，以使内容在更小的尺寸下可用。

在此示例中，当窗口对于标准格式来说太小时，Windows 媒体播放器更改其格式。

• 请勿使用“总在最前面”属性。
  • 例外：仅在对话框实现基本模式操作时使用，但需要短暂挂起才能访问所有者窗口。 例如，在对文档进行拼写检查时，用户有时可能会离开拼写检查对话框，并访问文档以更正错误。

有关详细信息和示例，请参阅窗口管理。

标题栏

• 对话框没有标题栏图标。 标题栏图标用作主窗口和辅助窗口之间的可视区别。
  • 例外：如果对话框用于实现主窗口（如实用工具），因此显示在任务栏上，则它确实具有标题栏图标。 在这种情况下，请首先通过简洁地放置区分信息来优化任务栏上的显示标题。
• 对话框始终具有“关闭”按钮。 无模式对话框还可以有“最小化”按钮。 可调整大小的对话框可以具有“最大化”按钮。
• 不要禁用“关闭”按钮。 拥有“关闭”按钮有助于用户通过允许关闭不需要的窗口来保持控制状态。
  • 例外：对于进度对话框，如果任务必须运行到完成，以达到有效状态或防止数据丢失，则可以禁用“关闭”按钮。
• 标题栏上的“关闭”按钮应与对话框中的“取消”或“关闭”按钮的效果相同。 切勿给予它与“确定”相同的效果。
• 如果标题栏描述文字和图标已以靠近窗口顶部的突出方式显示，则可以隐藏标题栏描述文字和图标，以避免冗余。 但是，仍然必须在内部设置合适的标题，以供 Windows 使用。

交互

• 显示时，用户启动的对话框应始终具有输入焦点。 程序启动的对话框不应具有输入焦点，因为用户可能正在与另一个窗口交互。 错误定向到此对话框的此类交互可能会产生意外的后果。

• 将初始输入焦点分配给用户最有可能第一个与其交互的控件，这通常（但并非总是）是第一个交互式控件。 避免将初始输入焦点分配给帮助链接。

• 对于键盘导航，Tab 键顺序应按逻辑顺序流动，通常从左到右，从上到下。 通常 Tab 键顺序遵循阅读顺序，但请考虑把以下情况视为例外：

  • 按 Tab 键顺序先放置最常用的控件。
  • 将帮助链接放在对话框底部，在 Tab 键顺序的提交按钮之后。

  分配顺序时，假定用户出于预期目的显示对话框；因此，例如，用户显示选项对话框进行选择，而不是查看并单击“取消”。

• 按 Esc 键始终关闭活动对话框。 对于具有“取消”或“关闭”的对话框，即使已将“取消”重命名为“关闭”也是如此，因为无法再撤消结果。

访问密钥

• 尽可能为所有交互式控件或其标签分配唯一访问键。只读文本框是交互式控件（因为用户可以滚动和复制文本），因此它们受益于访问键。 不要将访问键分配给：

  • “确定”、“取消”和“关闭”按钮。 Enter 和 Esc 用于其访问键。 但是，始终将访问键分配给表示“确定”或“取消”、但具有不同的标签的控件。

    

    在此示例中，为正提交按钮分配了访问键。

  • 组标签。 通常，组中的各个控件都分配了访问键，因此组标签不需要访问键。 但是，如果访问键短缺，请将访问键分配给组标签，而不是单个控件。

  • 通用“帮助”按钮，使用 F1 访问。

  • 链接标签。 通常链接过多，无法分配唯一访问键，并且通常用下划线表示隐藏访问键下划线的链接。 改为使用 Tab 键访问链接。

  • Tab 名称。 使用 Ctrl+Tab 和 Ctrl+Shift+Tab 循环使用 Tab。

  • 浏览标记为“...”的按钮。 无法为这些“浏览”按钮分配唯一的访问键。

  • 未标记的控件，如旋转控件、图形命令按钮和未标记的渐进式披露控件。

  • 非标签静态文本或非交互式控件的标签，如进度栏。

• 尽可能根据标准访问键为常用命令分配访问键。 虽然一致的访问键分配并非总是可能的，但它们肯定是首选的，尤其是经常使用的对话框。

• 首先为提交按钮分配访问键，以确保它们具有标准访问键分配。 如果没有标准键分配，请使用第一个单词的第一个字母。 例如，“是”和“否”提交按钮的访问键应始终为“Y”和“N”，而不考虑对话框中的其他控件。

• 若要使访问键易于查找，请将访问键分配给标签早期出现的字符，最好是第一个字符，即使标签中后面出现关键字也是如此。

• 首选宽字符，如 w、m 和大写字母。

• 首选独特的辅音或元音，如 Exit 中的“x”。

• 避免使用难以看到下划线的字符，例如（从最有问题到问题最小的字符）：

  • 只有一个像素宽的字母，例如 i 和 l。
  • 带有下行字符的字母，如 g、j、p、q 和 y。
  • 带有下行字符的字母旁边的字母。

有关更多指南和示例，请参阅键盘。

进度对话框

对于长时间运行的任务，假定用户在任务完成时会执行其他操作。 设计任务以无人参与的形式运行。

• 如果操作完成时间超过 5 秒，则向用户显示进度反馈对话框，以及用于取消或停止操作的命令。
  • 例外：对于向导和任务流，仅当任务停留在同一页上（而不是前进到另一个页面）时，才使用进度的模式对话框，并且用户在等待时无法执行任何操作。 否则，请使用进度页或就地进度。
• 如果操作是长时间运行的任务（超过 30 秒），并且可以在后台执行，请使用无模式进度对话框，以便用户可以在等待时继续使用程序。
• 无模式进度对话框：
  • 标题栏上有“最小化”按钮。
  • 显示在任务栏上。
• 执行无模式进度对话框，使其继续运行，即使所有者窗口已关闭也是如此。

在此示例中，即使关闭所有者窗口，文件复制也会继续。

• 提供一个命令按钮，以停止需要几秒钟才能完成或可能永远不会完成的操作。 如果取消将环境返回到其以前的状态，请标记按钮为“取消”（不产生副作用）；否则，请标记按钮为“停止”，以指示它使部分完成的操作保持不变。 如果在某个时候无法将环境返回到其以前的状态，则可以在操作中间将按钮标签从“取消”更改为“停止”。

在此示例中，停止问题诊断没有副作用。

• 提供一个命令按钮，用于暂停需要几分钟以上才能完成的操作，它会损害用户完成工作的能力。 这样做不会强制用户在完成任务和完成工作之间进行选择。
• 在开始任务之前收集尽可能多的信息。
• 如果检测到可恢复的问题，请让用户在任务结束时处理发现的所有问题。 如果这不可行，让用户在问题发生时处理。
• 不要因可恢复错误而放弃任务。

在此示例中，Windows 资源管理器允许用户在可恢复错误后继续执行任务。

• 通过将进度栏变为红色来指示问题。

在此示例中，在文件复制期间删除了可移动磁盘。

• 如果用户清楚地看到结果，请在成功完成后自动关闭进度对话框。 否则，请仅使用反馈报告问题：
  • 若要显示简单的反馈，在进度对话框中显示反馈，并将“取消”按钮更改为“关闭”。
  • 若要显示详细的反馈，请关闭进度对话框，并显示信息性对话框。

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

剩余时间

• 使用下列时间格式。 从以下格式的第一个开始，其中最大时间单位不为零，然后在最大时间单位变为零后更改为下一种格式。

进度栏：

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

剩余时间：h 小时、m 分钟

剩余时间：m 分钟、s 秒

剩余时间：s 秒

如果屏幕空间处于高级阶段：

剩余 h 小时，m 分钟

剩余 m 分钟，s 秒

剩余 s 秒

否则：

剩余 h 小时，m 分钟

剩余 m 分钟，s 秒

剩余 s 秒

对于标题栏：

剩余 hh:mm

剩余 mm:ss

剩余 0:ss

此紧凑格式首先显示最重要的信息，以免在任务栏上截断它。

• 使估计准确，但不给出假精确。 如果最大单位为小时，则提供分钟数（如果有意义），但不指定秒。

错误：

hh 小时，mm 分钟，ss 秒

• 使估算保持最新状态。 剩余的时间估计至少每 5 秒更新一次。
• 关注剩余时间，因为这是用户最关心的信息。 仅当运行时间有帮助（例如任务可能重复时）的情况下，才提供总运行时间。 如果剩余的估计时间与进度栏相关联，则不具有完成百分比文本，因为进度栏本身传达了该信息。
• 语法正确。 当数字为 1 时，请使用单数单位。

错误：

1 分，1 秒

• 使用句子样式的大写。

有关详细信息和示例，请参阅进度栏。

图标和图形

显卡

• 不要使用没有用处、只是填充空间的华而不实的大型图形。 保持简单的外观。

错误：

在此示例中，大型图形毫无用处。

标题栏图标

• 对话框没有标题栏图标。
  • 例外：如果对话框用于实现主窗口（如实用工具），因此显示在任务栏上，则它确实具有标题栏图标。

正文图标

• 根据设计模式选择正文图标：

模式	正文图标
问题对话框	程序、功能、对象、警告图标（如果数据或系统访问可能丢失）、安全警告或无。
选择对话框	无。
进度对话框	无（但可能有动画）。
信息性对话框	无。

• 错误：

在此示例中，警告图标错误地用于不涉及数据或系统访问丢失的问题。

• 请考虑使用图标帮助用户直观识别程序的功能。 当图标易于识别，并在程序中的多个位置使用时，此方法最有效。

在此示例中，黄色星形图标表示“收藏夹”。 该图标易于识别，并且在整个 Windows 中一致地用于表示“收藏夹”。

• 使用图标帮助用户识别有问题的对象。

在此示例中，对象的图标可帮助用户识别打开或保存的文件的类型。

• 请考虑使用图标来帮助使功能不言自明。

在此示例中，这些图标可帮助用户直观显示其功能的效果。

• 使用“关于”对话框中的图标进行应用程序标记。

在此示例中，在“关于”中使用位图来标识和标记应用程序。

脚注图标

• 如果有脚注，请考虑使用脚注图标来汇总脚注的主题。

在此示例中，脚注图标指示问题具有安全隐患。

• 不要使用重复正文图标的脚注图标。
• 请勿使用错误或信息标准图标。 错误条件必须通过正文图标传达，脚注始终用于信息，这使信息图标冗余。 但是，可以使用标准警告图标和黄色安全防护来提醒用户风险后果。

有关详细信息和示例，请参阅图标。

提交按钮

注意：

• 这些准则不适用于使用命令链接的问题对话框，因为该模式使用命令链接，而不是按钮。
• [执行]和[请勿执行]分别是对主要指令的肯定和否定的回应。

常规

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

Label	值
模式	提交按钮
问题对话框（使用按钮）	以下简明命令集之一：是/否、是/否/取消、[执行]/取消、[执行]/[请勿执行]、[执行]/[请勿执行]/取消。
问题对话框（使用链接）	取消。
选择对话框	模式对话框：确定/取消或[执行]/取消 无模式对话框：对话框和标题栏上的“关闭”按钮 任务窗格：标题栏上的“关闭”按钮
进度对话框	如果将环境返回到其以前的状态（不产生副作用），请使用“取消”；否则，请使用“停止”。
信息性对话框	接近了。

• 所有提交按钮（“应用”除外）会关闭对话框窗口。

• 请勿确认提交按钮。 不必要地这样做可能非常令人恼火。 异常：

  • 该操作可能是灾难性的。
  • 该操作显然与其他操作不一致。
  • 如果操作不正确，操作可能会导致用户的数据、时间或工作量大幅丢失。

  有关更多指南和示例，请参阅确认。

• 不要禁用提交按钮。 异常：

  • 如果用户必须提升权限才能进行更改，请禁用正提交按钮，直到用户进行更改。 这样做可以防止用户只是为了关闭窗口而提升，强制他们单击“取消”。
  • 有关更多例外，请参阅“禁用或删除控件”和“提供错误消息”。

• 在对话框底部、但在脚注区域上方的单行中右对齐提交按钮。 即使有一个提交按钮（如“确定”），也执行此操作。

  错误：

  

  在此示例中，“确定”按钮未正确居中。

• 按以下顺序显示提交按钮：

  1. 确定/[执行]/是
  2. [不执行]/否
  3. Cancel
  4. 应用（如果存在）
  5. 帮助（如果存在）

• 如果有许多相关的提交按钮，请使用拆分按钮将其合并。

• 提交按钮（关闭窗口）和所有其他命令按钮（如“高级”）具有明确的分离。

响应主要说明

• 使用对主指令的具体响应的正提交按钮，而不是通用标签，如“确定”或“是/否”。 用户应仅通过阅读按钮文本就能理解这些选项。 异常：

  • 对没有设置的对话框（如信息性对话框）使用“关闭”。 切勿对具有设置的对话框使用“关闭”。

  • 当“特定”响应仍为通用时使用“确定”，例如“保存”或“选择”。 更改特定设置或设置集合时使用“确定”。

  • 对于没有主指令的旧对话框，可以使用通用标签，例如“确定”。 通常，此类对话框不设计为执行特定任务，从而防止更具体的响应。

  • 某些任务需要用户更多地思考和仔细阅读，以便做出明智的决策。 确认通常是这种情况。 在这种情况下，可以有意使用通用提交按钮标签强制用户阅读主要说明，并防止仓促决策。

    更正：

    

    在此示例中，使用“是/否”提交按钮强制用户至少阅读主指令。

• 或者，可以将“无论如何”一词添加到正提交按钮标签，以指示对话框显示不继续的原因，并且用户应在继续之前仔细阅读对话框。

  更正：

  

  在此示例中，“无论如何”添加到提交按钮标签，以指示用户应谨慎继续。

• 对否定提交按钮使用“取消”或“关闭”，而不是对主指令的具体响应。 通常，用户一旦看到对话框，就会意识到他们不想执行一项任务。 如果将“取消”或“关闭”重新标记为具体响应，用户必须仔细阅读所有提交按钮，以确定如何取消。 标记“取消”和“关闭”保持一致，使其易于查找。例外：

  • 请勿使用“是/取消”。 始终将“是/否”成对使用。
  • 当“取消”不明确时，请使用具体的响应。

• 不要将通用标签映射到其特定含义，并在内容区域中显示文本。 相反，请使用具体的提交按钮标签，或者使用链接（如果标签很长）的问题对话框。

  错误：

  

  在此示例中，“确定”映射到“继续”，“取消”映射到“在页面上保留”。

“是”和“否”按钮

• 首选对“是”和“否”按钮的具体响应。 虽然使用“是”和“否”没有任何问题，但具体响应可以更快理解，从而产生高效的决策。 但是，确认通常具有“是”和“否”按钮，让用户在响应之前进行一些思考。

• 仅使用“是”和“否”按钮回复是或否的问题。 主要指令应自然地表示为是或否的问题。 切勿将“确定”和“取消”用于是或否的问题。

  错误：

  

  更正：

  

  更好的：

  

  在这些示例中，“是”和“否”是对是或否的问题的良好响应，但具体的响应更好。

• 如果具有具体措辞的提交按钮较长或尴尬，请考虑将主要指令措辞为是或否的问题。 或者，可以对主指令的较长响应（五个字或更多）使用命令链接。

  错误：

  

  更正：

  

  错误示例中的具体措辞太长，因此正确的示例使用“是”和“否”。

• 如果“否”响应的含义不清楚，请勿使用“是”和“否”按钮。 如果是这样，请改用具体的响应。

“确定”按钮

• 在模式对话框中，单击“确定”表示应用值、执行任务和关闭窗口。

• 不要使用“确定”按钮来回答问题。

• 不要给“确定”分配访问键，因为 Enter 是默认按钮的访问键。 这样做会使其他访问键更易于分配。

• 正确标记“确定”按钮。 “确定”按钮应标记为“确定”，而不是“确”或“定”。

• 不要对错误或警告使用“确定”按钮。 问题绝不能“确定”。 请改用“关闭”。

  错误：

  

  在此示例中，应使用“关闭”，而不是“确定”。

• 不要在无模式对话框中使用“确定”按钮。 相反，无模式对话框应使用特定于任务的提交按钮（例如“查找”）。 但是，某些无模式对话框只需要“关闭”按钮。

“取消”按钮

• 单击“取消”意味着放弃所有更改，取消任务，关闭窗口，并将环境返回到其以前的状态，不会造成任何副作用。 对于嵌套选择对话框，单击所有者选择对话框中的“取消”意味着选择对话框所做的任何更改也会被放弃。

• 提供“取消”按钮，让用户显式放弃更改。 对话框需要明确的退出点。 不要指望用户在标题栏上找到“关闭”按钮。

  • 例外：不要为没有设置的对话框提供“取消”按钮。 在这种情况下，“确定”和“关闭”按钮的效果与“取消”相同。

  错误：

  

  在此示例中，标题栏上只有一个“关闭”按钮，就好像用户别无选择一样。

• 不要使用“取消”按钮来回答问题。

  错误：

  

  在此示例中，错误地使用“确定”和“取消”来响应是或否的问题。

• 不要给“取消”分配访问键，因为 Esc 是访问键。 这样做会使其他访问键更易于分配。

• 不要在无模式对话框中使用“确定”按钮。 相反，请改用“关闭”。

• 不要禁用“取消”按钮。 用户应始终能够取消对话框。

  • 例外：如果某个时间段无法取消操作，则可以在进度对话框中禁用“取消”按钮。 但是，更好的解决方案是将此类操作设计为始终可取消。

“关闭”按钮

• 对无模式对话框以及无法取消的模式对话框使用“关闭”按钮。
• 单击“关闭”意味着关闭对话框窗口，留下任何现有的副作用。 请勿使用“完成”，因为它不是强制性构造。 对于嵌套选择对话框，单击所有者选择对话框中的“关闭”意味着保留选择对话所做的任何更改。
• 将显式“关闭”按钮放在对话框正文中。 对话框需要明确的退出点。 不要指望用户在标题栏上找到“关闭”按钮。
• 确保标题栏上的“关闭”按钮的效果与“取消”或“关闭”的效果相同。
• 不要给“关闭”分配访问键，因为 Esc 是访问键。 这样做会使其他访问键更易于分配。

“应用”按钮

• 请勿在不属于属性表或控制面板的对话框中使用“应用”按钮。 “应用”按钮表示应用挂起的更改，但使窗口保持打开状态。 这样，用户就可以在关闭窗口之前评估更改。 但是，只有属性表和控制面板才具有此需求。

  错误：

  

  在此示例中，选择对话框具有不必要的“应用”按钮。

间接对话框的“提交”按钮

注意：间接对话框在上下文中显示为任务间接结果或系统或后台进程出现问题的结果。 对于间接对话框，“取消”按钮不明确，因为它可能意味着取消对话框或取消整个任务。

• 如果用户需要同时取消对话框和任务，请提供提交按钮来执行这两项操作。 使用对主指令的否定响应来标记取消对话框的按钮。 使用“取消”标记取消整个任务的按钮。 使用“取消”可在许多上下文中使用对话框。

  更正：

  

  在此示例中，当图形未保存时，Windows 画图将显示此对话框，作为“新建”或“退出”命令的结果。 “不要保存”会不保存地关闭对话框，而“取消”会取消“新建”或“退出”命令。

  错误：

  

  在此示例中，无法取消导致显示此对话框的任务（关闭 Office 快捷栏）。 此对话框需要“取消”按钮。

• 如果用户只需取消对话框而不是任务，请使用对主指令的具体、否定响应的按钮，并且不包含“取消”按钮。

  

  在此示例中，由于导航到安装 ActiveX 控件的网页，此对话框间接显示。 在此处使用“取消”将不明确，因此改用“不要运行”。

有关详细信息和示例，请参阅命令按钮。

命令链接

• 使用命令链接来呈现一组冗长的命令，而不是命令按钮或单选按钮和“确定”按钮的组合。 这样，用户只需单击一下即可做出响应。 但是，此方法仅适用于单个问题。
• 首先提供最常用的命令链接。 生成的顺序应大致遵循使用的可能性，但也具有逻辑流。
  • 例外：导致执行所有操作的命令链接应放在首位。
• 如果命令链接需要进一步说明，提供补充说明。补充说明描述用户可能想要选择此命令的原因，或者选择此命令时会发生什么情况。
• 不要使用冗长的命令链接的重述来补充说明。 仅当无法进行命令链接自我解释时，才使用补充说明。 为一个命令链接提供补充说明并不意味着你必须为所有命令提供补充说明。

在此示例中，补充说明描述了其中一个选项的含义。

• 使用以动词开头的短语，无需结尾的标点符号。
• 如果强烈建议使用命令，请考虑将“（建议）”添加到标签。 请务必添加到链接标签，而不是补充说明。
• 如果命令仅适用于高级用户，请考虑将“（高级）”添加到标签。 请务必添加到链接标签，而不是补充说明。
• 始终提供显式的“取消”按钮。 不要为此目的使用命令链接。

错误：

在此示例中，对话框使用命令链接，而不是“取消”按钮。

有关详细信息和示例，请参阅命令链接。

不要再次显示此项<>

• 请考虑使用“不再显示此项<>”选项，以允许用户取消定期的对话框，前提是没有更好的替代方法。 如果用户真的需要，最好始终显示对话框，或者直接消除对话框（如果他们不需要）。
• 使用此特定措辞将项替换为具体项<>。 例如，“不要再次显示此提醒”。 在一般情况下提及对话框时，使用“不要再次显示此消息”。
• 在选项下添加以下句子，明确指示何时将用户输入用于将来的默认值：将在将来默认使用所选内容。
• 默认情况下不要选择该选项。 如果对话框真的应该只显示一次，不用问就这样做。 不要使用此选项作为惹恼用户的借口，确保默认行为不会令人恼火。

错误：

在此示例中，消息应只显示一次。 无需询问。

• 使设置保持基于每位用户。
• 如果用户选择该选项并单击“取消”，则此选项生效。 此设置是元选项，因此它不遵循不留副作用的标准“取消”行为。 请注意，如果用户将来不想看到对话框，他们很可能也希望取消对话框。
• 如果用户需要还原这些对话框，请在程序的“选项”对话框中提供“还原消息”命令。

稍后问我

• 提供此选项以仅在以下情况下关闭对话框：
  • 对话框是间接的，因此用户可能专注于另一个任务。
  • 用户必须响应，但无需立即响应，这样他们可以继续工作。
  • 问题需要足够的思考或努力，这样用户就可以在给予更多时间的情况下做出更好的决策。
  • 对话框或选项将在以后自动显示（以便稍后确实询问用户）。
• 错误：
• 
• 在此示例中，问题非常简单，添加“稍后询问”选项只会使它复杂化。
• 否则，期望用户现在会做出响应，但允许用户使用“取消”或“关闭”正常关闭对话框。 正确使用时，此选项应很少见。

更多/更少

• 使用“更多/更少”的渐进式公开按钮来显示或隐藏目标用户通常不需要的高级或很少使用的选项、命令或详细信息。 这样做会简化典型用法的对话框。 不要隐藏常用的选项、命令或信息，因为用户可能找不到它们。

在此示例中，默认情况下，很少使用的选项处于隐藏状态。

• 除非确实有更详细的显示，否则不要使用“更多/更少”的控件。 不要只以不同的格式重述相同的信息。
• 不要使用“更多/更少”的控件来显示“帮助”。 请改用“帮助”链接或脚注。
• 使用任务对话框时，请避免将“更多/更少”的控件与“不再显示此项<>”组合在一起。 这种组合具有尴尬的外观。
• 有关标记准则，请参阅渐进式披露。

脚注

• 使用脚注获取对对话框用途并不重要、但用户可能会觉得有助于做出决策的信息。 大多数用户应能够跳过脚注，并仍在对对话框的响应中做出明智的决策。

在此示例中，脚注信息是补充性的，不是必要的。

禁用或删除控件与提供错误消息

• 当控件在当前上下文中不适用时，请考虑以下选项：
  • 如果用户无法启用控件，或者用户不希望它应用，并且其状态不会频繁更改，请删除该控件。 这样做可以简化对话框，用户不会错过它。 控件频繁出现和消失令人恼火。
  • 当用户期望它应用或其状态频繁更改，并且用户可以轻松推断控件被禁用的原因时，禁用该控件。 简单扣减的一个示例是在有一个需要任何输入的空文本框时，禁用提交按钮。 可以使用气球显示文本框和可编辑下拉列表的非关键用户输入问题。 但是，如果无法用气球解释问题或涉及多个控件，则扣减将不再容易。
  • 否则，请使控件保持启用状态，但在未正确使用控件时提供错误消息。 在这种情况下，禁用会使用户难以理解控件被禁用的原因。 用户将被迫通过试验和扣减逻辑来确定问题。 最好提供一条有用的错误消息来显式解释问题。
• 提示：如果不确定是应禁用控件还是提供错误消息，请首先撰写可能提供的错误消息。 如果错误消息包含目标用户不太可能快速推断的有用信息，请使控件保持启用状态，并给出错误。 否则，请禁用该控件。
• 如果禁用控件，还要禁用所有关联的控件，例如其标签、补充说明或命令按钮。 但是，如果存在，请不要禁用其分组框、组标签或组说明。

在此示例中，禁用的文本框标签也处于禁用状态，但其组标签和组说明不是。

要求的输入

• 若要指示用户必须在控件中提供信息，请考虑以下选项：

  • 不要指示任何内容，而是使用错误消息处理缺少的输入。 如果大多数输入是可选的，或者用户不太可能跳过控件，则此方法会减少混乱，有效运作，从而降低错误消息的数量。

  • 在标签开头使用星号指示必需的输入。 使用以下任一方法解释星号：

    • 内容区域底部的脚注，显示“* 必需输入”。
    • 星号上的工具提示，显示“必需输入”。

    如果没有许多必需的控件，则此方法效果良好，但如果大多数控件是必需的，则效果不佳。

    

    在此示例中，星号用于指示必需的输入。

  • 如果所有控件都需要输入，请在内容区域顶部的适当位置声明“所有输入必需”。 此方法可减少此特定情况的混乱。

  • 在标签后面用“（可选）”指示可选输入。 如果大多数输入是必需的，此方法效果良好，但其他情况下效果不佳。

• 为了保持一致性，请尝试使用相同的方法来指示整个程序所需的输入。 具体而言，请根据需要指示必需或可选输入，但避免在同一程序中同时使用这两种指示。

错误处理。

• 通过使用限制为有效用户输入的控件来防止错误。 还可以通过提供合理的默认值来帮助减少错误数。

• 尽快验证用户输入，并尽可能在接近输入点的位置显示错误。

• 对用户输入问题使用无模式错误处理（就地错误或气球）。

  • 将气球用于在文本框中检测到的或在文本框失去焦点后立即检测到的非关键单点用户输入问题。 气球不需要可用的屏幕空间或显示就地消息所需的动态布局。 一次仅显示一个气球。 由于问题并不重要，因此不需要错误图标。 单击、解决问题或超时后，气球将消失。

    

    在此示例中，气球指示控件中仍存在输入问题。

• 使用就地错误进行延迟错误检测，通常是通过单击提交按钮找到的错误。 （不要对立即提交的设置使用就地错误。）一次可能存在多个就地错误。 使用普通文本和 16x16 像素错误图标，尽可能将它们直接放在问题旁边。 除非用户提交并且未找到其他错误，否则就地错误不会消失。

  

  在此示例中，就地错误用于通过单击提交按钮找到的错误。

• 对所有其他问题使用模式错误处理（任务对话框或消息框），包括涉及多个控件的错误，或者通过单击提交按钮找到的非上下文或非输入错误。

• 找到并报告输入问题时，使用不正确的数据将输入焦点设置为第一个控件。 如有必要，将控件滚动到视图中。

有关详细信息和示例，请参阅错误消息和气球。

帮助

• 提供用户帮助时，请考虑以下选项（按首选项顺序列出）：

  • 为交互式控件提供不言自明的标签。 与任何其他文本相比，用户更有可能阅读交互式控件上的标签。
  • 使用静态文本标签提供上下文中的说明。
  • 提供指向相关帮助主题的特定“帮助”链接。

• 找到对话框内容区域底部的“帮助”链接。 如果对话框具有脚注，并且“帮助”链接与其相关，请将“帮助”链接置于脚注中。

  

  在此示例中，“帮助”链接适用于整个对话框。

  • 例外：如果对话框有多个不同的设置组，这些设置具有单独的帮助主题（可能位于分组框中），请在组底部找到“帮助”链接。

• 不要使用常规或模糊的帮助主题链接或通用“帮助”按钮。 用户通常忽略通用“帮助”。

有关详细信息和示例，请参阅帮助。

默认值

• 在每个对话框中包括默认提交按钮。
• 对于问题对话框：
  • 默认情况下，选择最安全（为防止数据丢失和系统访问）和最可靠的响应为默认值。 如果安全和可靠不是考虑因素，选择最有可能或最方便的响应。
    • 例外：除非有一种简单、明显的方法来撤消命令，否则不要对默认值做出破坏性响应。
• 对于选择对话框：
  • 对于初始默认值为每个控件选择最安全（以防止数据丢失或系统访问）和最可靠的值。如果安全和可靠不是考虑因素，选择最有可能或最方便的选项。
  • 对于后续的默认值，如果这些值可能重复，重新选择以前选择的选项，这样做是安全可靠的。否则，请选择初始默认值。

在此示例中，用户最有可能选择与上次相同的打印设置。 但是，所需的副本数可能会更改，因此不会重新选择此设置。

建议的大小和间距

• 支持最低 Windows Vista 屏幕分辨率 800 x 600 像素。 可以使用屏幕分辨率为 1024 x 768 像素的可调整大小的窗口优化布局。
• 请随时使用可调整大小的窗口来避免滚动条和数据截断。 具有动态内容和列表的 Windows 从可调整大小的窗口受益最多。
• 固定大小的窗口必须完全可见，并调整大小以适应工作区域。
• 可调整大小的窗口可以针对更高的分辨率进行优化，但在显示时根据需要缩小到实际屏幕分辨率。
• 选择适合其内容的默认窗口大小。 如果可以有效地使用空间，请不要害怕使用更大的初始窗口大小。

文本

常规

• 删除冗余文本。 在标题、主要说明、补充说明、内容区域、命令链接和提交按钮中查找冗余文本。 通常，在说明和交互式控件中保留全文，并从其他地方删除任何冗余。
• 使用积极的措辞。 用户更容易理解积极的措辞。

更正：

是否要启用文件和打印机共享？

错误：

是否要禁用文件和打印机共享？

但是，即使命令是负面措辞，措辞必须与关联的命令匹配；因此，例如，使用禁用来确认“禁用”命令。

• 如有必要，请使用单词“窗口”来引用对话框本身。
• 使用第二人称（“你/你的”）在主要说明和内容区域中告知用户该怎么办。 通常暗示第二人称。

示例：

选择要打印的图片

选择帐户

• 在对应主要说明的内容区域的控件中，使用第一人称（“我/我的”），让用户告知程序要做什么。

示例：打印我的相机上的照片。

对话框标题

• 使用标题来标识对话框所在的命令、功能或程序。
  • 如果用户启动对话框，请使用命令或功能名称标识它。 异常：
    • 如果对话框由许多不同的命令显示，请考虑改用程序名称。
    • 如果该游戏与主要说明冗余，请改用程序名称。
  • 如果由程序或系统启动（因此脱离上下文），请使用程序或功能名称来为上下文标识它。
  • 不要使用标题来说明在对话框中执行的操作，这是主要说明的目的。
• 对基于命令的名称使用确切的命令名称，但如果存在省略号，则不要包含省略号。 如有必要，可以包含命令的菜单标题，以撰写良好的标题。 示例：对于“插入”菜单中的“对象……”命令，使用标题“插入对象”。
• 如果任务栏上出现无模式对话框，请先通过简洁地放置区分信息来优化任务栏上显示的标题。 示例：“66% 完成”和“3 条提醒”。
• 不要在标题中包含“对话框”或“进度”。 这是暗示的，省略它使用户更容易浏览。
• 使用标题样式大写，无需结尾的标点符号。

主要说明

• 使用主要说明简明地说明对话框中要执行的操作。 指令应是具体的语句、命令性方向或问题。 良好的说明通过对话框传达用户的目标，而不是纯粹专注于操作它的机制。
• 如果唯一可以说的话是显而易见的，请省略主要说明。 在这种情况下，对话框的内容是自我解释的。 例如，“文件打开”和“文件保存”常见对话框不需要主指令，因为它们的上下文和设计使其用途明显。
• 省略重述主指令的控件标签。 在这种情况下，主指令采用访问键。

可接受：

在此示例中，文本框标签只是主指令的重述。

更好的：

在此示例中，删除了冗余标签，因此主要说明采用访问键。

• 保持简洁，只使用单个完整句子。 将主要说明分析为基本信息。 如果必须解释更多内容，请使用补充说明。
• 尽可能使用具体动词。 特定动词（示例：连接、保存、安装）对用户来说比通用动词更有意义（示例：配置、管理、设置）。
• 使用句子样式的大写。
• 如果指令是语句，请不要包含最后的句点。 如果指令是问题，请包含最终的问号。
• 对于进度对话框，请使用动名词短语来简要说明正在进行的操作，以省略号结尾。 示例：正在打印图片……
• 提示：可以通过想象对朋友说什么来评估主要说明。 如果使用主要说明做出响应是非自然的、无用或尴尬的，请重新处理指令。

补充说明

• 如有必要，请使用可选的补充说明来提供有助于理解或使用页面的其他信息。 可以提供更详细的信息，并定义术语。
• 如果对话框的外观是程序或系统启动的（因此处于上下文之外），请使用补充说明解释对话框出现的原因。 对于此类对话框，上下文通常并不明显。
• 不要只是修改几个措词来重复主要说明。 相反，如果不添加更多内容，请省略补充说明。
• 使用完整的句子、句子样式大写和结尾的标点符号。

命令链接

• 选择简洁的链接文本，以清楚地传达和区分命令链接的作用。 它应该是自我解释的，并对应于主要说明。 用户不必弄清楚链接的真正含义或它与其他链接有何区别。
• 命令链接的开头始终使用动词。
• 使用句式单词首字母大写。
• 不要使用结尾的标点符号。
• 如有必要，请使用完整的句子和结尾的标点符号提供进一步的解释。 但是，仅当需要时才添加此类说明。不要仅因为一个命令链接需要说明，就向所有命令链接添加说明。

有关详细信息和示例，请参阅命令链接指南。

提交按钮

• 使用具体的提交按钮标签，这些标签本身有意义，并且是对主要说明的响应。 理想情况下，用户无需阅读其他任何内容即可了解标签。 比起静态文本，用户更有可能阅读命令按钮标签。
• 提交按钮标签的开头使用动词。 例外是“确定”、“是”和“否”。
• 使用句式单词首字母大写。
• 不要使用结尾的标点符号。
• 分配唯一的访问键。
  • 例外：不要将给“确定”和“取消”按钮分配访问键 Enter 和 Esc 是其访问键。 这样做会使其他访问键更易于分配。

文档

提及对话框时：

• 在编程和其他技术文档中，将对话框称为对话框。 在其他地方，按其标题提及对话框。 如果标题栏处于隐藏状态，请使用主要说明提及对话框。
• 如果一般情况下必须提及对话框，使用用户文档中的窗口。 可以将简单的问题对话框或确认作为消息。
• 使用确切的标题或主要说明文本，包括其大写。
• 如果可能，请使用加粗文本设置标题的格式。 否则，仅当需要防止混淆时，才将标题置于引号中。

示例：在 Windows 安全中，单击“更多选项”。