用户界面文本

备注

此设计指南是为 Windows 7 创建的,尚未更新较新版本的 Windows。 大部分指南原则上仍适用,但演示和示例并不反映我们 当前的设计指南

用户界面文本显示在 UI 图面上。 此文本包括控件标签和静态文本:

  • 控件标签标识控件,并直接放置在控件旁边或旁边。
  • 静态文本是所谓的,因为它不是交互式控件的一部分,为用户提供详细说明或说明,以便他们可以做出明智的决策。

注意:样式和语气字体comon 控件 标签相关的指南显示在单独的文章中。

使用模式

UI 文本具有多种使用模式:

使用情况 说明
标题栏文本
使用标题栏文本标识对话框的窗口或源。
文件夹选项标题栏的屏幕截图
在此示例中,标题栏文本标识窗口。
主要说明
使用突出的主要说明来简明地说明在窗口或页面中执行的操作。
指令应该是特定的语句、命令性方向或问题。 良好的主指令传达用户的目标,而不是专注于操作 UI。
问题屏幕截图:是否想要最新帮助?
在此示例中,主说明文本直接向用户提供用户自己的权益或兴趣方面的问题。
补充说明
如有必要,请使用补充说明提供有助于理解或使用窗口或页面的其他信息。
可以提供更详细的信息、提供上下文和定义术语。 补充说明详细说明了主要指令,而无需简单地重新措辞。
切换到管理员帐户时的文本屏幕截图
在此示例中,补充说明提供了两种可能的操作过程,以响应主指令中提供的信息。
控件标签
直接位于控件或控件旁边的标签。
桌面时钟选项的屏幕截图
在此示例中,控件标签标识用户可以选择或修改的桌面时钟设置。
补充说明
(控件标签的详细说明通常用于命令链接、单选按钮和复选框) 。
显示“安全设置”对话框的屏幕截图。
在此示例中,补充说明阐明了选择。

设计概念

软件开发人员通常将文本视为降级到产品文档和技术支持。 “首先,我们将编写代码,然后我们将聘请某人来帮助我们解释我们开发的内容。然而,实际上,重要文本是在该过程的前面编写的,因为 UI 是设想和编码的。 毕竟,此文本比任何其他类型的技术写作更频繁和更多的人看到。

理解文本对于有效的 UI 至关重要。 专业编写者和编辑器应与 UI 文本上的软件开发人员合作,作为设计过程不可或缺的一部分。 让他们尽早处理文本,因为文本问题经常显示设计问题。 如果你的团队在解释设计时遇到问题,通常就是需要改进的设计,而不是解释。

UI 文本的设计模型

考虑 UI 文本及其在 UI 图面上的位置时,请考虑以下事实:

  • 在集中的沉浸式阅读中,人们在西方文化) (从左到右、从上到下的顺序阅读。
  • 使用软件时,用户不会沉浸于 UI 本身,而是沉浸于其工作中。 因此,用户不会读取其扫描的 UI 文本。
  • 扫描窗口时,当用户在现实中筛选文本时,用户可能正在阅读文本。 除非他们意识到需要,否则它们通常不会真正理解 UI 文本。
  • 在窗口中,不同的 UI 元素接收不同级别的关注。 用户倾向于先阅读控件标签,尤其是那些与完成手头任务相关的控件标签。 相比之下,用户往往仅在认为需要时读取静态文本。

对于常规设计模型,不要假定用户仔细阅读从左到右、从上到下的顺序的文本。 相反,假设用户首先快速扫描整个窗口,然后大致按以下顺序读取 UI 文本:

  • 中心内的交互式控件
  • 提交按钮
  • 在其他地方找到的交互式控件
  • 主指令
  • 补充说明
  • 窗口标题
  • 正文中的其他静态文本
  • 脚注

你还应该假设,一旦用户决定该做什么,他们就会立即停止阅读并执行此操作。

消除冗余

冗余文本不仅占用宝贵的屏幕空间,而且削弱了您试图传达的重要想法或操作的有效性。 这也是读者时间的浪费,在扫描是常态的上下文中,更是如此。 Windows 努力解释用户需要很好地简洁地执行哪些操作。

查看每个窗口,并消除控件内和跨控件重复的单词和语句。 不要避免重要文本;在必要的情况下明确,但不要冗余,不解释显而易见的。

避免过度通信

即使文本不是冗余的,它可能只是太字化,以解释每个细节。 太多文本不鼓励阅读:眼睛往往跳过它讽刺地导致沟通较少,而不是更多。 在 UI 文本中,简洁地传达基本信息。 如果某些用户或某些方案需要更多信息,请提供指向更详细的 帮助内容的链接,或者可能指向术语表条目,以说明术语。

不正确:

包含 6 段的对话框的屏幕截图

在此示例中,文本过多,无法轻松扫描。 虽然设计者不打算使用,但用户很可能单击“下一步”,而不会阅读任何内容。

为了避免不鼓励阅读的文本,请制作文本以使每一个字计数。 不加减的内容,因此请使用简单简洁的文本。

使用倒棱锥图

学术写作通常使用一种“金字塔”结构风格,它奠定了事实的基础,与这些事实合作,并形成一个形成金字塔状结构的结论。 相比之下,记者们使用以结论开始的“倒棱锥”风格作为读者必须拥有的基本“外卖”。 然后,它填充了读者可能感兴趣的可能只是扫描的更多详细信息。 这种样式的优点是,它是正确的点,并允许读者停止阅读任何他们选择的点,仍然理解基本信息。

应将反棱锥结构应用于 UI 文本。 使用基本信息直接访问该点,让用户随时停止阅读,并使用帮助链接显示金字塔的其余部分。

加入 Windows 程序的消息屏幕截图

在此示例中,基本信息位于主指令文本的查询中,其他有用信息位于补充说明中,可通过单击“帮助”链接获取详细信息。

如果你只做五件事...

  1. 早期处理文本,因为文本问题经常显示设计问题。
  2. 设计文本进行扫描。
  3. 消除冗余文本。
  4. 使用易于理解的文本;不要过度沟通。
  5. 如有必要,请提供指向帮助内容的链接以获取更详细的信息。

准则

常规

  • 删除冗余文本。 在窗口标题、主要说明、补充说明、内容区域、命令链接和提交按钮中查找冗余文本。 通常,在主指令和交互式控件中保留全文,并从其他位置删除任何冗余。

  • 避免大量 UI 文本块。 执行此操作的方法包括:

    • 将文本分块为较短的句子和段落。
    • 如有必要,请提供 “帮助”链接 来提供有用的信息,但并非基本信息。
  • 选择明确传达和区分对象用途的对象名称和标签。 用户不必弄清楚对象的真正含义或它与其他对象有何不同。

    不正确:

    未命名监视器列表的屏幕截图

    良好:

    特定网络适配器列表的屏幕截图

    在不正确的示例中,对象名称根本不区分;更好的示例显示了产品名称的强区别。

  • 如果要确保用户读取与操作相关的特定文本,请将其置于交互式控件上。

    • 可以接受:
    • 使用“确定”按钮设置格式警告的屏幕截图
    • 在此示例中,用户可能无法阅读解释他们正在确认的内容的文本。
    • 更好:
    • 设置警告和格式按钮的屏幕截图
    • 在此示例中,可以确保至少用户了解他们即将格式化磁盘。
  • 在句子之间使用一个空格。 不是两个。

文本字体、大小和颜色

  • 仅对链接和主要说明使用蓝色文本。
  • 仅对搜索结果中的 URL 使用绿色文本。

以下字体和颜色是 Windows 的默认值。

模式 主题符号 字体、颜色
第一列:标题栏文本
CaptionFont
9 pt. black (#000000) Segoe UI
第一列:主要说明
MainInstruction
12 pt. blue (#003399) Segoe UI
第一列:辅助指令
指令
9 pt. black (#000000) Segoe UI
第一列:普通文本
BodyText
9 pt. black (#000000) Segoe UI
第一列:强调的文本
BodyText
9 pt. black (#000000) Segoe UI,粗体或斜体
第一列:可编辑的文本
BodyText
9 pt. black (#000000) Segoe UI,在框中
第一列:禁用的文本
已禁用
9 pt. 深灰色 (#323232) Segoe UI
第一列:链接
HyperLinkText
9 pt. blue (#0066CC) Segoe UI
第一列:链接 (悬停)

9 pt. 浅蓝色 (#3399FF) Segoe UI
第一列:组标题

11 pt. blue (#003399) Segoe UI
第一列:内容视图中的文件名 ()

11 pt. black (#000000) Segoe UI
第一列:文档文本
(无)
9 pt. black (#0000000) Calibri
第一列:文档标题
(无)
17 pt. black (#0000000) Calibri

有关详细信息和示例,请参阅 字体颜色

其他文本特征

加粗

  • 请谨慎使用粗体吸引用户对文本用户必须阅读的注意。 例如,扫描单选按钮选项列表的用户可能会欣赏以粗体显示标签,以从添加有关每个选项的补充信息的文本中脱颖而出。 请注意,使用太多大胆会降低其影响。

  • 使用带标签的数据,使用粗体来强调整体数据更重要。

    • 对于大多数泛型数据 (,没有标签的数据几乎没有意义,与数字或日期) 一样,请使用粗体标签和纯数据,以便用户可以更轻松地扫描和了解数据类型。

    • 对于大多数自我解释的数据,请使用纯标签和粗体数据,以便用户可以专注于数据本身。

    • 或者,可以使用深灰色文本来取消强调不太重要的信息,而不是使用粗体来强调更重要的信息。

      Windows 资源管理器缩略图视图的屏幕截图

      在此示例中,标签不使用粗体强调数据,而是使用深灰色取消强调。

  • 并非所有字体都支持粗体,因此理解文本不应该至关重要。

斜体

  • 用于以文字方式引用文本。 请勿为此使用引号。

    正确:

    术语文档和文件通常可互换使用。

  • 用于文本框可编辑下拉列表中的提示

    搜索文本框的屏幕截图

    在此示例中,搜索框中的提示格式为斜体文本。

  • 请谨慎地强调特定字词,以帮助理解。

  • 并非所有字体都支持斜体,因此理解文本绝不应该至关重要。

粗体斜体

  • 不要在 UI 文本中使用。

下划线

  • 请勿使用,链接除外。
  • 不要用于强调。 请改用斜体。

标点

周期

  • 请勿在控件标签、主要说明或帮助链接的末尾放置。
  • 放在补充说明、补充说明或任何其他构成完整句子的静态文本的末尾。

问号

  • 放在所有问题结束时。 与句点不同,问号用于所有类型的文本。

感叹号

  • 在业务应用程序中,请避免。
    • 异常: 感叹号有时在下载完成上下文中使用 (“完成!”) 并注意 Web 内容 (“新建!”) 。

逗号

  • 在三个或多个项列表中,始终在列表中的下一项后面放置一个逗号。

冒号

  • 使用外部控件标签末尾的冒号。 对于辅助功能来说,这尤其重要,因为一些辅助技术查找冒号来标识控件标签。
  • 使用冒号引入项列表。

椭圆

  • 省略号表示不完整。 在 UI 文本中使用省略号,如下所示:

    • 命令: 指示命令需要其他信息。 每当操作仅当需要其他信息时才显示另一个窗口时,请勿使用省略号。 有关详细信息,请参阅 命令按钮

    • 数据: 指示文本被截断。

    • 标签: 指示任务正在进行 (,例如“搜索...”) 。

      提示: 窗口或页面中未使用空间的截断文本表示布局不佳或默认窗口大小过小。 努力查找消除或减少截断文本量的布局和默认窗口大小。 请参阅布局以了解详细信息。

  • 不要使省略号交互。 若要显示截断的文本,允许用户调整控件的大小以查看更多文本或使用 渐进式披露控件

引号和撇号

  • 若要从字面上引用文本,请使用斜体格式而不是引号。

  • 仅当需要防止混淆且不能改用粗体设置格式时,才将窗口标题和控件标签置于引号中。

  • 对于引号,首选双引号 (“ ”) ;避免单引号。

    正确:

    是否确实要删除“Sparky 的 cat 文件夹”?

    不正确:

    是否确实要删除“Sparky 的 cat 文件夹” ?

大写

  • 对标题使用标题样式大写,对所有其他 UI 元素使用句子样式大写。 这样做更适合 Windows 音调

    • 例外: 对于旧版应用程序,可以根据需要对命令按钮、菜单和列标题使用标题样式大写,以避免混合大写样式。

      泛型属性表的屏幕截图

    此泛型示例显示属性表的正确大写和标点。

    泛型对话框的屏幕截图

    此泛型示例显示了对话的正确大写和标点。

  • 对于功能和技术名称,在大写方面是保守的。 通常,应仅使用游戏样式大写) 将主要组件大写化 (大写。

    正确:

    Analysis Services、多维数据集、维度

    Analysis Services 是SQL Server的主要组成部分,因此游戏样式大写是适当的;多维数据集和维度是数据库分析软件的常见元素,因此没有必要大写它们。

  • 对于功能和技术名称,在大写方面保持一致。 如果名称多次出现在 UI 屏幕上,应始终以相同的方式显示。 同样,在程序中的所有 UI 屏幕上,名称应一致显示。

  • 不要大写通用用户界面元素的名称,例如工具栏、菜单、滚动条、按钮和图标。

    • 异常: 地址栏、链接栏。
  • 不要将所有大写字母用于键盘键。 相反,如果键盘上未标记键,请遵循标准键盘使用的大写,或小写。

    正确:

    空格键、Tab、Enter、向上翻页、Ctrl+Alt+Del

    不正确:

    空格键、TAB、Enter、PG UP、CTRL+ALT+DEL

  • 不要将所有大写字母用于强调。 研究表明,这是很难阅读的,用户倾向于将其视为“尖叫”。对于警告,请使用警告图标和情况的明文说明。 无需在所有大写字母中添加术语 WARNING。

有关详细信息,请参阅特定 UI 组件指南中的“文本”或“标签”部分。

日期和时间

  • 不要硬编码日期和时间的格式。 尊重用户选择日期和时间格式的区域设置和自定义选项。 用户在“区域”和“语言”控制面板项中选择这些选项。

    日期格式的屏幕截图:2009 年 7 月 6 日星期一、2009 年 7 月 6 日日期格式的屏幕截图:2009 年 7 月 6

    在 Microsoft Outlook 的这些示例中,长日期的这两种格式都是正确的。 它们反映了用户在“区域”和“语言”控制面板项中所做的不同选择。

  • 对于受益于其他信息的方案,请使用长日期格式。 对于没有足够空间的长格式的上下文,请使用短日期格式。 虽然用户选择要包含在长格式和短格式中的信息,但设计人员根据方案和上下文选择要在程序中显示的格式。

    带开始日期和截止日期的格式的屏幕截图

    在此示例中,长日期格式可帮助用户组织任务和截止时间。

全球化和本地化

全球化意味着创建在任何国家/地区或区域性中可用的文档或产品。 本地化意味着调整文档或产品,以便在原始国家/地区以外的区域设置中使用。 编写 UI 文本时,请考虑全球化和本地化。 你的程序可能翻译成其他语言,并用于文化中,这与你自己的语言大相径庭。

  • 对于具有变量内容的控件 ((如列表视图和树视图) ), 请选择适合最长有效数据的宽度。

  • 在 UI 图面中包含足够的空间,以增加 30% (最多 200%, 对于任何文本 (的较短文本) ,但不会本地化为数字) 。 从一种语言翻译到另一种语言通常更改文本的行长度。

  • 不要在运行时从子字符串撰写字符串。 请改用完整的句子,以便翻译器没有歧义性。

  • 请勿使用从属控件、它包含的值或其单位标签来创建句子或短语。 这种设计不可本地化,因为句子结构因语言而异。

    不正确:

    复选框标签中的文本框的屏幕截图

    正确:

    复选框标签后面的文本框的屏幕截图

    在不正确的示例中,文本框放置在复选框标签内。

  • 不要只将句子的一部分作为链接的一部分,因为翻译后,该文本可能不会一起保留。 因此,链接文本本身应形成完整的句子。

    • 例外: 术语表链接可以插入内联,作为句子的一部分。

有关详细信息,请参阅 Go Global Developer Center

标题栏文本

  • 根据窗口类型选择标题栏文本:
    • 以文档为中心的顶级程序窗口: 使用“文档名称程序名称”格式。 首先显示以文档为中心的文档名称。
    • 非以文档为中心的顶级程序窗口: 仅显示程序名称。
    • 对话框: 显示对话框所在的命令、功能或程序。 请勿使用标题来说明对话框的用途,这是主要说明的目的。 有关更多指南,请参阅 对话框
    • 向导: 显示向导名称。 请注意,“向导”一词不应包含在向导名称中。 有关更多指南,请参阅 向导
  • 对于顶级程序窗口,如果标题栏标题和图标显示在窗口顶部附近,则可以隐藏标题栏标题和图标以避免冗余。 但是,你仍然需要在内部设置合适的游戏以供 Windows 使用。
  • 对于对话框,不要在标题中包含单词“dialog”或“progress”。 这些概念是默示的,离开这些单词会使用户更容易扫描游戏。

主要说明

  • 使用主要说明简明地说明用户在给定的窗口或页面中应执行的操作。 良好的主指令传达用户的目标,而不是专注于操作 UI。

  • 以命令性方向或特定问题的形式表达主要指令。

    不正确:

    程序名称作为主指令的屏幕截图

    在此示例中,主指令只是说明程序的名称;它不会显式邀请用户采取的操作过程。

    异常: 错误消息、警告消息和确认可能在其主要指令中使用不同的句子结构。

  • 尽可能使用特定谓词。 特定谓词 (示例:连接、保存、安装) 对用户更有意义, (示例:配置、管理、设置) 。

    • 对于控制面板页和向导页,如果无法使用特定谓词,则可能需要完全省略该谓词。

      可以接受:

      输入区域设置、区域和语言

      更好:

      区域设置、区域和语言

    • 对于对话框(如错误消息和警告),请不要省略谓词。

  • 如果添加它只是从 UI 上下文中冗余或明显,请不要觉得必须使用主指令文本。

    另存为对话框的屏幕截图

    在此示例中,UI 的上下文已经非常清晰;无需添加主指令文本。

  • 简洁使用一个完整句子。 将主要指令分析为基本信息。 如果必须解释更多内容,请考虑使用补充说明。

  • 使用句式大写。

  • 如果指令是语句,请不要包含最终句点。 如果指令是问题,请包含最终问号。

  • 对于进度对话,请使用一个格子短语,简要说明正在进行的操作, 以省略号结尾。 示例:“打印图片...”

  • 提示: 通过想象你在解释对窗口或页面执行的操作时,可以想象对朋友说什么来评估主指令。 如果使用主指令做出响应将是非自然的、无帮助或尴尬的,请重新处理指令。

有关详细信息,请参阅特定 UI 组件指南中的“主指令”部分。

补充说明

  • 如有必要, 请使用补充说明提供有助于理解或使用窗口或页面的其他信息, 例如:
    • 提供上下文来说明窗口在程序或系统启动时显示的原因。
    • 限定信息可帮助用户决定如何执行主指令。
    • 定义重要术语。
  • 如果不需要补充说明,请不要使用补充说明。 如果可以简洁地执行此操作,最好与主要指令进行通信。
  • 不要用略有不同的措辞重复主指令。 相反,如果添加其他内容,请省略补充说明。
  • 使用完整的句子和句子样式大写。

控件标签

  • 标记每个控件或控件组。 异常:

    • 文本框和下拉列表可以使用提示标记。

    • 渐进式披露控制通常未标记。

    • 从属控件使用其关联控件的标签。 旋转控件始终是从属控件。

    • 省略重述主指令的控件标签。 在这种情况下,主指令采用访问密钥。

      可以接受:

      带有说明和标签的文本框的屏幕截图

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

      更好:

      仅带有说明的文本框的屏幕截图

      在此示例中,将删除冗余标签,因此主指令采用访问密钥。

  • 标签放置:

    • 气球、复选框、命令按钮、组框、链接、选项卡和提示由控件本身直接标记。
    • 下拉列表、列表框、列表视图、进度条、滑块、文本框和树视图都标在上方、左刷新或左侧。
    • 渐进式披露控制通常未标记。 雪佛龙按钮标记为右侧。
  • 为每个交互式控件分配唯一的访问键 ,但链接除外。 有关详细信息,请参阅 键盘

  • 让标签保持简短。 但是,请注意,向标签添加一两个单词有助于明确,有时无需补充说明。

  • 首选特定标签而不是泛型标签。 理想情况下,用户不必阅读其他任何内容才能理解标签。

    不正确:

    “确定”命令按钮的屏幕截图

    正确:

    “发布命令”按钮的屏幕截图

    在正确的示例中,特定标签用于提交按钮。

  • 对于标签列表(如单选按钮),请使用并行措辞, 并尝试为所有标签保留大致相同的长度。

  • 对于标签列表,请将标签文本集中在选项之间的差异上。 如果所有选项具有相同的介绍性文本,请将该文本移动到组标签。

    不正确:

    带有重复第一个短语的标签的屏幕截图

    正确:

    移动到组标签的第一个短语的屏幕截图

    正确的示例将相同的介绍性措辞移到标签上,因此这两个选项更清晰地区分。

  • 一般情况下,更喜欢积极的措辞。 例如,使用操作而不是不通知,而不是通知。

    • 例外: 复选框标签“不要再次显示此消息”被广泛使用。
  • 省略应用于给定类型的所有控件的指令谓词。 相反,将标签放在控件的独特之处上。 例如,无需说明用户需要键入文本框控件或用户需要单击链接。

    不正确:

    标签的屏幕截图:“键入名称”

    正确:

    标签的屏幕截图:“你的名字”

    在不正确的示例中,控件标签具有适用于其类型的所有控件的指令谓词。

  • 在某些情况下,用于控制标签的以下括号批注可能很有用:

    • 如果某个选项是可选的,请考虑将“ (可选) ”添加到标签。
    • 如果强烈建议使用某个选项,请将“ (推荐) ”添加到标签。 这样做意味着设置是可选的,但无论如何都应该设置。
    • 如果某个选项仅适用于高级用户,请考虑将“ (高级) ”添加到标签。
  • 可以在标签后 (秒、连接等) 指定单位。

    标签的屏幕截图:初始大小 (mb)

    此示例显示度量单位为 MB (MB) 。

有关详细信息,请参阅特定 UI 组件指南中的“文本”或“标签”部分。

补充说明

  • 当控件需要的信息比标签可以传达更多的信息时,请使用补充说明。 但是,如果没有必要使用补充说明,如果你能够简洁地执行此操作,则不要使用补充说明来与控件标签通信所有内容。 通常,补充说明用于命令链接、单选按钮和复选框。

  • 如有必要, 在控件标签中使用加粗,使文本更易于在 有补充说明时进行扫描。

    “安全设置”对话框的屏幕截图

    在此示例中,单选按钮标签加粗,使其更易于扫描。

  • 向组中的一个控件添加补充说明并不意味着你必须为组中所有其他控件提供说明。 如果只能在必要的情况下使用说明,请提供标签中的相关信息。 不要有补充性解释,只是重述标签的一致性。

    三个单选按钮的屏幕截图

    在此示例中,组中的两个控件包括补充说明,但第三个控件不包含。

  • 如果补充说明遵循命令链接,请在第二人中编写补充文本。

    例子: 命令链接:创建无线网络设置并保存到 USB 闪存驱动器

    补充说明:这将创建可以使用 USB 闪存驱动器传输到路由器的设置。 仅当有支持 USB 闪存驱动器配置的无线路由器时,才执行此操作。

  • 使用完整的句子和结束标点符号。

提交按钮标签

下表显示了最常见的提交按钮标签及其用法。

按钮标签 何时使用
正常
  • 在对话框中:将更改或提交应用到任务并关闭窗口。
  • 在所有者属性窗口中:应用自打开窗口或上次应用) 并关闭窗口以来 (挂起的更改。
  • 在拥有的属性窗口中:保留更改,关闭窗口,并在应用所有者窗口的更改时应用更改。
  • 与不特定于任务的窗口一起使用,例如属性表。
  • 对于用于执行一个特定任务的窗口,请使用以谓词 (示例开头的特定标签:打印) 。
  • 对于用户无法进行更改的窗口,请使用 Close。
  • Enter

Yes/No
是的是对是或否的肯定回应,而“否”是负面回应。
  • 使用“是”和“否”按钮仅响应“是”或“否”问题。 切勿对是或否使用“确定”和“取消”。
  • 首选特定响应而不是“是”和“否”按钮。 虽然使用“是”和“否”没有任何问题,但可以更快地理解特定响应,从而产生高效的决策。
  • 但是,如果特定响应的措辞被证明是长或尴尬的,请考虑使用“是”和“否”响应。
  • 如果“无响应”的含义不清楚,请不要使用“是”和“否”按钮。 如果是,请改用特定的响应。
  • 是且不能始终用作对。
  • Y 和 N
  • 取消
  • 在对话框中:放弃所有更改或正在进行的工作,还原到上一状态 () 留下明显的副作用,然后关闭窗口。
  • 在属性表中:放弃自打开窗口或上次应用) 并关闭窗口以来 (所做的所有挂起更改。
  • 在控制面板项中:放弃所有更改或正在进行的工作,还原到以前的状态,并返回到启动任务的中心页面。 如果没有此类中心页面,请改为关闭控制面板项窗口。
  • 当可以放弃所有挂起的更改或操作并且可以撤消任何副作用时使用。
  • 对于无法放弃的更改,请使用 Close。 对于可停止的正在进行的操作,请使用 Stop。 如果最初可以放弃更改或操作,则可以最初使用“取消”,然后在无法撤消后更改为“关闭”或“停止”。
  • Esc
  • 关闭
    关闭窗口。 不会放弃任何更改或副作用。
  • 当无法放弃更改或副作用时使用。 对主窗口使用 Close 而不是 Cancel。
  • 用于用户无法进行更改的窗口。
  • Alt+F4、Ctrl+F4
  • 停止
    停止当前正在运行的任务并关闭窗口。 不会放弃正在进行的任何工作或副作用。
  • 在进行中工作时使用,并且任何副作用都不能或不会被丢弃,通常使用进度条或动画。
  • Esc
  • 应用
    在所有者属性表中:应用自打开窗口或上次应用) 以来 (进行的挂起更改,但将窗口保持打开状态。 这样做允许用户在关闭属性表之前评估更改。 在拥有的属性表中:不使用。
  • 仅在属性表中使用。
  • 仅当属性表具有设置 (至少一个) 且用户可以以有意义的方式评估的效果时,才提供“应用”按钮。 通常,当设置进行可见更改时,使用“应用”按钮。 用户应能够应用更改、评估更改,并根据该评估进行进一步更改。 否则,请删除“应用”按钮,而不是禁用它。
  • A
  • 下一页
    在向导和多步骤任务中:在不提交任务的情况下转到下一步。
  • 仅在向导和多步骤任务中使用,无需承诺即可前进到下一步。
  • 单击“后退”,始终可以撤消“下一步”按钮的效果。
  • N
  • “完成”
    在向导和多步骤任务中:关闭窗口。 如果任务尚未执行,请执行该任务。 如果已执行该任务,则不会放弃任何更改或副作用。
  • 仅在向导和多步骤任务中使用。 但是,不建议使用“完成”,因为通常有更好的更具体的提交按钮:
    • 如果单击按钮提交到任务 (以便任务尚未) 执行,请使用以谓词开头的特定标签 (示例:打印、连接、开始) ,这是对主指令的响应。
    • 如果已在向导中执行任务,请改用 Close。
  • 但是,可以在以下情况下使用“完成”:
    • 特定标签仍是通用标签,例如“保存”、“选择”、“选择”或“获取”。
    • 该任务涉及更改设置或设置集合。
  • Enter
  • 已完成
    不适用。
  • 请不要使用。 作为命令完成的语法不正确。
  • 不适用。