出自UXGuide.net

用户界面文本

User Interface Text

目录 1 使用模式 2 设计理念 2.1 UI 文本的设计模型 2.2 去除重复 2.3 避免过度沟通 2.4 使用倒金字塔结构 3 设计规范 3.1 常规 3.2 文本字体、大小和颜色 3.3 其他文本特征 3.4 标点 3.5 大小写 3.6 全球化与本地化 3.7 标题栏文本 3.8 主标题说明 3.9 辅助说明 3.10 控件标签 3.11 补充说明 3.12 提交按钮标签

“用户界面文本”是显示在用户界面上的。这里的文本包括控件标签及静态文本：

• 控件标签用于标识控件，直接位于控件之上或旁边。
• 静态文本，顾名思义是指不属于交互控件部分的文本。它向用户提供详细的说明或解释，使他们能够更好地作出选择。

注：与风格与语气、字体和通用控件相关的设计规范请参考各自相应的章节。

使用模式

用户界面文本具有多种使用模式：

标题栏文本 标题栏文本用于标识窗口或对话框的出处。	在这个示例中，标题栏文本用于标识窗口。
主标题说明 使用显著的主标题说明来简要解释在窗口或页面中需要做的事情。	说明应当是明确的陈述句，祈使句式的指导，或是疑问句。好的主标题说明传达的是用户的目标，而不只是关注于操作用户界面。 在这个示例中，主标题说明文字以用户自己的利益和兴趣角度来直接向用户提问。
补充说明 必要时，可以使用补充说明来提供额外的有助于理解或使用窗口或页面的信息。	你可以提供更具体的信息，提供上下文，或是定义术语。补充说明用于详细解释主标题说明，而不是简单地换个说法。 在这个示例中，补充说明应对主标题说明中描述的信息提供了两种可能的操作途径。
控件标签 直接位于控件上或旁边的标签。	在这个示例中，控件标签用于标识那些用户可以选择或修改的桌面时钟设置。
补充解释 对控件标签（通常是命令链接、单选按钮和复选框）的详细说明。	在这个示例中，补充解释使各个选项的含义更加明确。

设计理念

软件开发人员往往会轻视文本，与产品文档和技术支持等同。“我们会先写程序，然后雇个人来帮我们解释一下我们开发的东西。”但事实上，重要的文本应当在更早的时候——在 UI 构思及编码完成之前——就写好了。毕竟，看到这些文本的人数和频率可能会比任何其他形式的技术文档都要多。

易于理解的文本是决定 UI 是否高效的关键。作为设计过程中不可或缺的部分，专业的作者与编辑应当与软件开发人员一起共同撰写 UI 文本。尽早设计文本，因为文本中的问题往往会暴露出设计上的问题。如果你的团队在解释某个设计时觉得困难，则需要改进的很可能是设计，而不是解释说明。

UI 文本的设计模型

当你在思考 UI 文本以及它在用户界面上的位置排列时，考虑如下因素：

• 人们在专心致志地阅读时，是沿着从左至右，从上至下的顺序（在西方文化中）进行的。
• 用户在使用软件时，不会沉浸在用户界面本身之中，而是他们的工作。因此，用户不会阅读 UI 文本——他们只会一扫而过。
• 用户在扫视窗口时，可能看起来像是在阅读文本但事实上却漏了过去。他们通常没有真正理解 UI 文本的内容，除非他们觉得确实有必要。
• 窗口中不同的 UI 元素被人们关注的程度也有所不同。用户一般会先看控件的标签，尤其是那些看起来像是很快能够完成任务的控件。相反，用户只会在他们认为需要的时候才会阅读静态文本。

作为一般的设计模型来说，不要假设用户会从左到右、从上到下地仔细阅读文本。而是要假定用户先是会快速地扫一眼整个窗口，然后大致会按下面的顺序来阅读 UI 文本：

1. 中间的交互控件
2. 提交按钮
3. 其他地方的交互控件
4. 主标题说明
5. 补充解释
6. 窗口标题
7. 正文区域的其他静态文本
8. 脚注

你还需要知道的是，一旦用户决定如何去做，他们就会立即停止阅读而转为执行。

去除重复

重复文本不仅占据了宝贵的屏幕空间，而且还降低了你试图对重要的概念或操作的传达效果。这同时也浪费了读者的时间，尤其是当人们通常只会一扫而过的时候。Windows Vista® 力求将用户需要做的事情解释一次——既好又简洁。

重新检查每个窗口，去除重复的字词和描述，包括控件内和控件外的。对于那些应当尽可能进行详细描述的重要文本也不能略过，不要重复也不要解释那些显而易见的事。

避免过度沟通

即使文本并没有冗余，也很有可能过于拖沓地进行详尽解释。太多的文本会影响阅读——人眼会直接跳过它——反而会导致沟通不足，而不是更丰富。在 UI 文本中，应当简要地表达最基本的信息。如果某些用户或情况下需要更多信息的话，可以通过链接来提供更详细的帮助内容，或者是转到词汇表的相关条目以提供术语的解释。

错误：

在这个示例中，文本太多难以扫视。尽管这不是设计师的本意，但是面对这么长的文本，用户最有可能的是什么也不看直接单击下一步。

要避免出现影响阅读的文本，应力求做到简明扼要。减去那些可有可无的内容之后，即是使用了简单、简洁的文本。

使用倒金字塔结构

学术写作通常会使用“金字塔”结构，首先给出奠定事实的基础，然后通过这些事实，构建出结论——形成金字塔结构。相反，新闻记者使用的是“倒金字塔”结构，先从结论开始——读者可以获取的最基本的信息。然后才是慢慢补充读者可能会感兴趣的细节——也有可能只是一扫而过。这种方式的好处在于迅速抓住要点，让读者可以在任何位置停止阅读，且仍然能够理解基本的信息。

你应当在 UI 文本上使用倒金字塔结构。迅速抓住基本信息，让用户可以在任何位置停止阅读，然后使用帮助链接来呈现金字塔的剩余部分。

在这个示例中，基本信息已经包含在主标题说明的问题中，额外的帮助信息则在辅助说明中，详细信息则可以通过单击帮助链接获取。

最重要的五点：

1. 尽早进行文本方面的工作，因为文本问题往往反映出设计上的问题。
2. 为扫视设计你的文本。
3. 去除重复的文本。
4. 使用易于理解的文本，不要过度沟通。
5. 必要时，通过链接提供包含更多详细信息的帮助内容。

设计规范

常规

• 移去重复的文本。在窗口标题、主标题说明、辅助说明、内容区域、命令链接及提交按钮中寻找重复文本。通常，保留主标题说明和交互性控件中的文本，移除其他地方的所有重复内容。
• 避免使用大段的 UI 文本。方法包括：
  • 将文本截成较短的句子和段落。
  • 必要时，通过帮助链接提供有用但非基本的信息。
• 选择能够清晰表现和区分对象作用的名称和标签。不应当让用户来研究对象真正表示什么或者与其他的对象有什么不同。

错误：

较好：

在错误的示例中，对象名称完全没有区分性。而较好的示例则通过产品名称给出了明显的区别。

• 如果你希望用户一定要阅读与操作相关某个特定文本的话，将其放在交互控件上。

可以接受：

在这个示例中，用户可能不会阅读这段解释他们正在确认什么的文本。

较好：

在这个示例中，你可以肯定用户至少明白他们打算格式化磁盘。

• 在两个句子之间空一个空格。而不是两个。

文本字体、大小和颜色

• 下列字体和颜色是 Windows Vista 的默认设置。

  模式	主题符号	字体、颜色
  	CaptionFont	9 pt. 黑色 (#000000) Segoe UI
  	MainInstruction	12 pt. 蓝色 (#003399) Segoe UI
  	Instruction	9 pt. 黑色 (#000000) Segoe UI
  	（无）	12 pt. 白色 (#FFFFFF) Segoe UI
  	（无）	17 pt. 白色 (#FFFFFF) Segoe UI
  	BodyText	9 pt. 黑色 (#000000) Segoe UI
  	BodyText	9 pt. 黑色 (#000000) Segoe UI，粗体或斜体
  	BodyText	9 pt. 黑色 (#000000) Segoe UI，在框内
  	Disabled	9 pt. 深灰 (#323232) Segoe UI
  	HyperLinkText	9 pt. 蓝色 (#0066CC) Segoe UI
  	Hot	9 pt. 浅蓝色 (#3399FF) Segoe UI
  	（无）	9 pt. 黑色 (#000000) Calibri
  	（无）	17 pt. 黑色 (#000000) Calibri

更多信息和示例，参见字体和颜色。

其他文本特征

粗体

• 谨慎使用粗体来吸引用户注意那些必须阅读的文本。例如，当用户一眼扫过一排带选项按钮的选项时，可能更容易看到粗体的标签，这比给每个选项添加辅助信息要显眼得多。但要注意，粗体使用过多会降低其效果。
• 对于带标签的数据，用粗体来强调哪个对整体数据来说更加重要。
  • 对于比较常规数据来说（没有标签的话数据就失去了意义的情况，比如数值和日期），使用粗体标签和普通数据，使用户能够更加容易地扫视并理解数据的类型。
  • 对于自描述性比较强的数据来说，使用普通标签和粗体数据，使用户能够专注于数据本身。
  • 另外，你可以使用深灰色文本来弱化不重要的信息，而不要用粗体来强调重要的信息。

在这个示例中，并没有用粗体来强调数据，而是用深灰色来弱化标签。

• 非并所有字体都支持粗体，因此这应当不会影响对文本的理解。

斜体

• 用于文本的字面引用。不要在此种情况下使用双引号。（但中文仍然应当使用双引号。——译者注）

正确：

The terms document and file are often used interchangeably.（“文档”和“文件”这两个词往往会互换使用。）

• 用于文本框和可编辑下拉列表中的提示文本（prompt）。

在这个示例中，搜索框中的提示文本被设为斜体。

• 谨慎地强调特定的字词来加强理解。
• 非并所有字体都支持斜体，因此这应当不会影响对文本的理解。

粗斜体

• 不要在 UI 文本中使用。

下划线

• 除链接外不要使用。
• 不要用于强调，应当改用斜体。

标点

句点

• 不要在控件标签或主标题说明后使用。
• 应在辅助说明、辅助解释、或其他包含完整句子的静态文本后使用。

问号

• 在所有的问句后使用。与句点不同，问号应用于所有类型的文本。

感叹号

• 在商业应用程序中，避免使用。
  • 例外：感叹号有时用在下载完成的情况（“Done!（完成！）”）或 Web 内容中引起人们注意时（“New!（新产品！）”）。

逗号

• 用于三个或三个以上的列表项，应始终在列表倒数第二项之后加一个逗号。

冒号

• 在外部控件标签的末尾使用冒号。这对于无障碍访问特性来说尤为重要，因为一些辅助技术是通过查找冒号来识别控件标签的。
• 用冒号来引导一组并列项。

省略号

• 省略号表示不完整。应当以下列方式在用户界面文本中使用省略号：
  • 命令。表示该命令需要额外的信息。不要凡是显示其他窗口的操作就都加上省略号——应当只是那些需要额外的信息来完成操作的情况。更多信息，参见命令按钮。
  • 数据。表示文本被截断。
  • 标签。表示任务正在进行中（如“正在搜索...”）。

提示：在那些还有未使用的空间的窗口或页面中出现被截断的文本意味着不好的布局或默认窗口尺寸太小。努力调整布局和默认窗口尺寸，以消除或减少文本截断的数量。更多信息，参见布局。

引号和省文撇

• 要对文本进行字面引用，应优先使用斜体格式，而非双引号。
• 仅在需要避免混淆且你无法使用粗体来代替时才将窗口标题和控件标签置于引号内。
• 尽可能使用弯引号和弯省文撇，而非直的。
• 对于引号来说，尽量使用双引号（“ ”），避免使用单引号（‘ ’）。

正确：

Are you sure you want to delete "Sparky's cat folder"?

错误：

Are you sure you want to delete 'Sparky's cat folder'?

对于中文 UI 来说，应当使用相应的中文标点符号。但对于用于位于标签末尾引导控件的冒号和在命令、数据、标签中表示不完整的省略号来说，仍然应使用英文标点。这将有助于提高无障碍访问特性。——译者注

大小写

• 为标题使用标题大写样式，其他所有 UI 元素则使用句子大写样式。这 为标题使用标题大写风格，并为所有其他 UI 元素使用句子大写风格。这么做更加贴合 Windows Vista 语气并在文本使用上更具描述性。
  • 例外：对于遗留的应用程序，如果需要，你可以使用标题大写样式来避免混合的大小写样式。

该常规示例显示了用于属性表的正确的大小写和标点符号。

该常规示例显示了用于对话框的正确的大小写的标点符号。

• 对于功能特性和技术名称，应当保持其原有的大小写。通常来说，只有主要组件应当大写（使用标题大写样式）。

正确：

Analysis Services, cubes, dimensions

Analysis Services 是 SQL Server 中的一个主要组件，因此使用标题大写样式是合适的。cubes 和 dimensions 是数据库分析软件中常见的元素，因此不必大写。

• 对于功能特性和技术名称，应当统一其大小写。如果该名称在某界面上出现多次，应当始终以相同的方式呈现。同样，该名称在此程序的不同界面之间也应当保持统一的呈现。
• 不要大写那些常规用户界面元素的名称，如“toolbar（工具栏）”、“menu（菜单）”、“scroll bar（滚动栏）”、“button（按钮）”和“icon（图标）”。
  • 例外：Address bar（地址栏）、Links bar（链接栏）。
• 不要为键盘按钮使用全大写字母。而是应当遵循标准键盘上使用的大小写方式，如果键盘上没有标出键名，就小写。（对于中文来说，如果标准键盘上有标注，则严格使用原文，如果键盘上没有标注，则使用其通行的中文名称。——译者注）

正确：

spacebar（空格键）, Tab, Enter, Page Up, Ctrl+Alt+Del

错误：

SPACEBAR, TAB（制表）, ENTER（回车）, PG UP（上一页）, CTRL+ALT+DEL

• 不要用全大写的方式来进行强制。用户会觉得这像是在“喊叫”，从而觉得厌恶。要警告用户关于某选项或设置可能出现的严重后果，应使用警告图标和对此种情况的清晰解释。没有必要添加类似“WARNING（警告）”这样的全大写词。

更多信息，参见具体 UI 组件设计规范中的“文本”或“标签”部分。

全球化与本地化

全球化是指创建能够在任何国家、区域或文化下使用的文档或产品。本地化是指使文档或产品适合于原国家/地区之外的某个地域使用。应当在撰写 UI 文本时考虑全球化和本地化。你的程序可能会被翻译成其他语言，在与你身处环境完全不同的文化下使用。

• 对于包含动态内容的控件（如列表视图和树形视图），应当根据最长有效数据选择合适的宽度。
• 在 UI 上预留足够的空间，额外空出 30% 的长度（对于较短的文本来说，最多 200%）用于需要被本地化的任何文本（但不包括数字）。从一种语言翻译至另一种语言后往往文本的行数会发生改变。
• 不要在运行时通过子字符串进行拼接。相反，应当使用完整的句子，不会对翻译人员产生歧义。
• 不要通过附属控件、其包含的值、或是其单位标签来组成句子或短语。这种设计无法被本地化，因为句子结构在不同的语言中会发生变化。

错误：

正确：

在错误的示例中，文本框错误地被放置在复选框的标签内部。

• 不要将句子的一部分作为链接，因为当翻译时，这段文字可能会被分散。链接文本本身应当就是完整的句子。
  • 例外：词汇表链接可以作为句子的一部分内联插入。

更多信息，参见 Microsoft Global Development and Computing Portal（英文）。

标题栏文本

• 根据窗口类型选择标题栏文本：
  • 顶层、以文档为中心的程序窗口：使用“文档名称 - 程序名称”格式。文档名称显示在前以给人以文档为中心的感觉。
  • 不是以文档为中心的顶层程序窗口：仅显示程序名称。
  • 对话框：显示该对话框所来自的命令、功能或程序。不要用标题来解释对话框的用途——这是主标题说明的用途。更多设计规范，参见对话框。
• 对于顶层程序窗口，如果标题栏文本和图标已经显示在靠近窗口顶端的位置的话，你可以隐藏标题栏文本和图标来避免重复。不过，你仍然要设置恰当的内部标题为 Windows 所用。
• 对于对话框，不要在标题中包含“dialog（对话框）”或“progress（进度）”的字样。这些概念已经隐含了，去掉这些字词可以使用户更容易扫视标题。

主标题说明

• 使用主标题说明来简要地解释一个页面或对话框用来做什么。好的主标题说明传达的是用户的目标，而不只是关注于操作用户界面。
• 以祈使句式的指导或明确的疑问句的形式表述主标题说明。

错误：

在这个示例中，主标题说明简单地给出了程序的名称，但它并没有明确说明用户应当怎么做。

• • 例外：错误信息、警告信息和确认信息可能会在其主标题说明中使用不同的句式。
• 尽可能使用明确的动词。对于用户来说，明确的动词（如：链接、保存、安装）比常规动词（如：配置、管理、设置）更加有意义。
  • 对于控制面板及向导页面，如果你无法使用明确的动词的话，你可以干脆将动词完全省略。

可以接受：

Enter your locale, region, and language

更好：

Locale, region, and language

• • 对于对话框来说，比如错误信息和警告信息，不要省略动词。
• 如果主标题说明只会导致重复或者在上下文中显而易见的话，则不要硬是加上主标题说明。

在这个示例中，UI 的上下文已经非常清晰，没有必要再添加主标题说明。

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

更多信息，参见具体 UI 组件设计规范中的“主标题说明”部分。

辅助说明

• 必要时，使用辅助说明来呈现有助于理解和使用该窗口或页面的附加信息，比如：
  • 如果该窗口是由程序或系统触发的话，则提供上下文以解释为何显示该窗口。
  • 进一步明确的信息以帮助用户决定针对主标题说明的内容应当如何应对。
  • 定义重要的术语。
• 如果辅助说明并非必要，则不要使用。如果你能够简洁的话，优先考虑用主标题说明来表达所有的意思。
• 不要在其他地方以相似的措辞重复主标题说明。相反，如果没有什么需要补充的话，就省略辅助说明。
• 使用带句末标点的完整句子，并使用句子大写样式。（原文中无“带句末标点”，参照对应章节补充。——译者注）

控件标签

• 为每个控件或控件组添加标签。例外：
  • 文本框和下拉列表可以用提示文字（prompt）来标注。
  • 渐进展开控件通常不带标注。
  • 附属控件使用其相应控件的标签。微调控件只能作为附属控件存在。
  • 省略与主标题说明相重复的控件标签。这种情况下，主标题说明具有访问键。

可以接受：

在这个示例中，文本框标签只是对主标题说明的重复。

更好：

在这个示例中，去除了重复的标签，主标题说明具有访问键。

• 标签位置：
  • 气球状提示、复选框、命令按钮、分组框、链接、选项卡和提示直接由控件自身进行标注。
  • 下拉列表、列表框、列表视图、进度条、滑块、文本框和树形视图在上方标注，左侧对齐，或者在左侧标注。
  • 渐进展开控件通常不带标注。V 形按钮则在右侧标注。
• 为每个交互控件分配唯一的访问键，链接除外。更多信息，参见键盘。
• 保持标签简洁。不过要记注，给标签加上一两个字词有助于更明确地进行表达，有时可以无须再使用补充说明。
• 尽可能使用明确的标签，而非常规标签。理想情况下，用户应当不需要为了理解标签而阅读其他任何内容。

错误：

正确：

在正确的示例中，提交按钮使用了明确的标签。

• 对于成排的标签来说，比如选项按钮，应使用平行的措辞方式，尝试着让所有标签的长度大致相同。
• 对于成排的标签来说，标签文本应当专注于各选项的差异上。如果所有的选项都有相同的说明文本，则应将此文本移至分组标签中。

错误：

正确：

正确的示例将相同的说明文本移到了标签中，使两个选项之间的区别更加清晰。

• 通常来说，最好使用肯定的表述方式。例如，使用“做”代替“不要做”、“通知”代替“不要通知”。
  • 例外：复选框标签“不要再显示此信息”已被广泛使用。
• 省略那些适用于所有给定类型控件的命令动词。相反，应当将标签专注于控件独特的地方。例如，用户需要在文本框控件中“键入”或者用户需要“单击”链接是不言自明的。

错误：

正确：

在错误的示例中，控件标签中的命令动词适用于所有该类型的控件。

• 有些情况下，在控件标签中包含下列带括号的附注可能会有帮助：
  • 如果一个选项是选填的，考虑在标签中添加“(optional)（可选）”字样。
  • 如果一个选项是强烈推荐的，应当在标签中添加“(recommended)”/“（推荐）”字样。
  • 如果一个选项是仅为高级用户设计的，应当在标签中添加“(advanced)”/“（高级）”字样。
• 你可以在标签之后的括号中指定单位（如“秒”或“连接”）。

该示例显示度量单位为兆字节（MB）。

更多信息，参见具体 UI 组件设计规范中的“文本”或“标签”部分。

补充说明

• 当控件标签无法传达更多信息时，可使用补充说明。但不要使用不必要的补充说明——如果可以的话，最好是在控件标签里简要地完整地进行表达。通常来说，补充说明会与命令链接、选项按钮和复选框一起使用。
• 当使用了补充说明时，尽可能加粗控件标签使其文本更易于扫视。

在这个示例中，选项按钮的标签被加粗以使其文本更易于扫视。

• 为一个控件提供补充说明并不代表这一组中其他所有的控件都需要。如果可以的话，应当在标签中提供相关信息，仅在必要时才使用解释说明。不要为了保持统一而使用仅仅在字面上将标签重复表述的补充说明。

在这个示例中，该组中有两个控件包含补充说明，而第三个则没有。

• 如果补充说明是跟在命令链接后的话，则该说明文本应以第二人称书写。
  • 例：命令链接：创建无线网络设置并保存至 USB 闪存盘

补充说明：这将在 USB 闪存盘上创建可以转送到路由器上的设置。仅当你拥有支持 USB 闪存盘配置的无线路由器时才这么做。

• 使用带有句末标点的完整句子。

提交按钮标签

下列显示了最常用的提交按钮标签和用法。

按钮标签	含义	何时使用	访问键
OK（确定）	在对话框中：应用更改或提交任务并关闭窗口。 在父属性窗口中：应用未进行的更改（从窗口打开或上次应用后）并关闭窗口。 在子属性窗口中：保留更改、关闭窗口，然后在父窗口的更改应用之时再应用这些更改。	用于与特定任务并不相关的窗口，如属性表。 对于用于完成某特定任务的窗口，应改用明确的以动词开头的标签（例如：打印）。 对于用户无法进行更改的窗口，应使用 Close（关闭）。	Enter
Yes（是）/No（否）	“是”是对于是否判断问题的肯定回答，而“否”则是否定回答。	仅用“是”和“否”按钮来回答是否判断问题。不要使用“确定”和“取消”来回答是否判断问题。 最好是使用有针对性的回答，而不是“是”“否”按钮。虽然使用“是”和“否”并没有什么问题，但有针对性的回答理解起来更快，做决定的效率也更高。 但是，如果明确回答的措辞会太长或者显得古怪的话，可以考虑使用“是”和“否”。 如果回答“否”的含义不明确的话，则不要使用“是”“否”按钮。此时应当改用明确的回答。 “是”和“否”必须始终成对使用。	Y 和 N
Cancel（取消）	在对话框中：放弃所有更改或者正在进行的工作，回到先前的状态并关闭窗口。 在属性表中：放弃所有未进行的更改（从窗口打开或上次应用后）并关闭窗口。 在控制面板项中：放弃所有更改或者正在进行的工作，回到先前的状态，并回到启动任务所在的中心页面。如果没有此中心页面，则关闭控制面板项窗口。	用于当所有未进行的更改或操作都可以丢弃，且副作用可以被撤销时。 对于无法丢弃的更改，应使用 Close（关闭）。对于可以停止的正在进行的操作，应使用 Stop（停止）。如果在开始的时候，更改或操作可以被丢弃，你可以先使用“取消”，等到无法撤销时再改为“关闭”或“停止”。	Esc
Close（关闭）	关闭窗口。所有更改或副作用都不会被丢弃。	用于当更改或副作用无法丢弃时。 用于用户无法进行更改的窗口。	Esc
Stop（停止）	停止当前正在运行的任务并关闭窗口。任何正在进行的工作或其副作用不会被丢弃。	用于当正在进行的工作或其副作用无法丢弃时，通常与进度条或动画一起使用。	Esc
Apply（应用）	在父属性表中：应用未进行的更改（从窗口打开或上次应用后），但保持窗口打开。这么做使用户能够在关闭属性表之前评价更改的效果。在子属性表中：不要使用。	仅用于属性表。 仅当属性表包含（至少一个）用户能够以有效的方式进行效果评价的设置时才提供“应用”按钮。通常，“应用”按钮用于可以直接看出更改的设置。用户应当能够应用更改、评价更改、再基于评价进行进一步的更改。如果不能，则移去“应用”按钮，而不要禁用。	A
Next（下一步）	在向导和多步骤任务中：前进至下一步，但并不提交任务。	仅用于向导和多步骤任务，以前进至下一步但不提交。 “下一步”按钮的效果应当始终可以通过单击“后退”来撤销。	N
Finish（完成）	在向导和多步骤任务中：关闭窗口。如果任务还没有被执行，则执行该任务。如果任务已经执行完成，则任何更改或副作用都不会被丢弃。	仅用于向导和多步骤任务。不过，并不建议使用“完成”，因为通常都存在更好、更加明确的提交按钮： 如果单击按钮将提交任务的话（即任务还未执行），应使用以回应主标题说明的动词开头的明确的标签（例如：打印、连接、开始）。 如果任务已经在向导中执行完成，则应改用 Close（关闭）。 然而，你可以在下列情况下使用“完成”： 即使使用了明确的动词也仍然是常规标签，如“保存”、“选择”或“获取”。 该任务包含对一个或一组设置的更改。	Enter
Done（完成）	不适用	不要使用。“完成”作为命令来说存在语法错误。	不适用