Windows 7 功能区
注意
此设计指南是为 Windows 7 创建的,尚未针对较新版本的 Windows 进行更新。 大部分指南原则上仍然适用,但演示和示例并不反映我们 当前的设计指南。
功能区是一种新式方式,可帮助用户以最少的单击次数高效、直接地查找、理解和使用命令,并且无需参考帮助。
功能区是一个命令栏,用于将程序的功能组织到窗口顶部的一系列选项卡中。 使用功能区可提高特性和功能的可发现性,使用户能够更快地了解整个程序,并使用户感觉自己更能控制其使用程序的体验。 功能区可以同时替换传统的菜单栏和工具栏。
典型的功能区。
功能区选项卡由组组成,组是一组标记的密切相关的命令。 除了选项卡和组外,功能区还包含:
- “应用程序”按钮,其中显示了一个命令菜单,这些命令涉及对文档或工作区执行某些操作,例如与文件相关的命令。
- 快速访问工具栏,它是一个可自定义的小型工具栏,用于显示常用命令。
- 核心选项卡是始终显示的选项卡。
- 上下文选项卡,仅在选择特定对象类型时显示。 始终显示的选项卡称为核心选项卡。
- 选项卡集是单个对象类型的上下文选项卡的集合。 例如,由于对象可以有多个类型 (具有图片的表中的标题是三种类型) ,因此一次可以显示多个上下文选项卡集。
- 模式选项卡,是使用特定临时模式(如打印预览)显示的核心选项卡。
- 库,这些库是图形呈现的命令或选项的列表。 基于结果的库说明了命令或选项的效果,而不是命令本身。 功能区内库显示在功能区内,而不是弹出窗口。
- 增强的工具提示,可简洁地解释其关联的命令并提供快捷键。 它们可能还包括图形和对帮助的引用。 增强的工具提示减少了对命令相关帮助的需求。
- 对话框启动器,是某些组底部的按钮,用于打开包含与组相关的功能的对话框。
功能区最初是随 Microsoft Office 2007 一起引入的。 若要了解 Office 为何需要使用功能区以及使用功能区解决的许多问题,请参阅 功能区的故事。
这是正确的用户界面吗?
若要决定使用功能区,请考虑以下问题:
程序类型
- 你正在设计哪种类型的程序? 程序类型是功能区适当性的一个良好指标。 功能区适用于文档创建和创作程序,以及文档查看器和浏览器。 功能区可能适用于其他类型的程序,但其他形式的命令呈现可能更合适。 通常,轻量级程序应具有轻型命令表示形式。
可发现性和学习问题
- 用户是否在查找命令时遇到问题? 用户是否请求计划中已有的功能? 如果是这样,使用功能区可以通过具有一目了然的标签和相关命令的分组,使命令更易于查找。 使用功能区也比菜单栏和工具栏更适合将来的增长。
- 用户是否难以理解程序的命令? 他们是否经常使用“试验和错误”来选择正确的命令或确定命令的工作原理? 如果是这样,使用功能区与基于库和实时预览的面向结果的命令可使命令更易于理解。
命令特征
- 命令是否显示在多个位置? 如果程序已存在,则菜单栏、工具栏、任务窗格和工作区本身中是否显示命令? 如果是这样,使用功能区会将命令统一到单个位置,使其更易于查找。
- 命令是应用于整个窗口还是仅适用于特定窗格? 功能区最适合应用于整个窗口或特定对象的命令。 就地命令更适用于单个窗口窗格。
- 是否可以直接显示大多数命令? 也就是说,用户能否通过单击与用户交互? 如果从菜单和对话框访问常用命令,是否可以将其重构为直接命令? 虽然某些命令可以使用菜单和对话框呈现,但以这种方式呈现大多数命令会降低功能区的效率,从而可能使菜单栏成为更好的选择。
命令缩放
- 是否有少量的命令? 最常用的命令能否在单个简单的工具栏上轻松显示? 如果添加核心选项卡和上下文选项卡会产生一个简单的“开始”选项卡,该选项卡可以单独用于执行最常见的任务,则使用功能区是值得的。 如果不是,使用功能区的好处可能无法证明它对于少量命令的额外权重是合理的。
- 是否有大量命令? 使用功能区是否需要超过 7 个核心选项卡? 用户是否必须不断更改选项卡才能执行常见任务? 如果是这样,使用工具栏 (不需要更改选项卡) 和 调色板窗口 (这可能需要更改选项卡,但一次可以打开多个选项卡,) 可能是一个更有效的选择。
- 大多数情况下,用户是否倾向于使用少量命令? 如果是这样,他们可以通过在“开始”选项卡上放置此类命令来有效地使用功能区。不断更改选项卡会使功能区过于低效。
- 程序是否受益于使程序的内容区域尽可能大? 如果是这样,使用菜单栏和单个工具栏比功能区更节省空间。 但是,如果程序需要三行或更多行工具栏或使用任务窗格,则使用功能区的空间效率更高。
- 用户是否倾向于长时间在程序中的大窗口中的特定区域工作? 如果是这样,它们将受益于小型工具栏、调色板窗口和直接命令的邻近性。 从工作区到功能区的往返效率太低。
- 为了提高效率和灵活性,用户是否需要对命令呈现内容、位置或大小进行重大更改? 如果是这样,可自定义且可扩展的工具栏和调色板窗口是更好的选择。 请注意,某些类型的工具栏可以取消停靠成为调色板窗口,并且调色板窗口可以移动、调整大小和自定义。
最后,考虑一个最终的问题: 提高可发现性、易学习性、效率和工作效率是否值得额外空间和选项卡来组织命令的成本? 如果是这样,使用功能区是一个很好的选择。 如果不确定,请考虑对基于功能区的设计进行可用性测试,并将其与最佳替代项进行比较。
功能区是一种具有吸引力的全新命令演示形式,也是实现程序现代化的好方法。 但是,虽然它们具有吸引力,但它们并不是每个计划的正确选择。
不正确:
请不要这样做!
七件最重要的事情
- 选择适合程序类型的命令解决方案。 使用功能区应该使程序感觉更简单、更高效、更易于使用,绝不会相反。 如果不适合使用功能区,请考虑改用 rich 命令。
- 不要低估创建有效功能区的挑战。 不要指望它是现有菜单栏和工具栏的简单端口。 不要认为使用功能区会自动使程序变得更好。 愿意投入重新设计命令所需的时间和精力是决定使用功能区的重要因素。
- 使命令可发现。 选择一种选项卡设计,该设计在命令与它们所在的带描述性标签的选项卡之间具有清晰、明显、唯一的映射。 用户应该能够快速且自信地确定哪个选项卡具有他们要查找的命令,并且很少选择错误的选项卡。
- 使命令一目了然。 用户应从命令的标签、图标、工具提示和预览中了解命令的效果。 他们不必尝试或阅读帮助主题来了解命令的工作原理。
- 提高使用命令的效率:
- 用户应将大部分时间花在“主页”选项卡上。
- 在常见任务期间,用户应很少需要更改选项卡。
- 当窗口最大化并且用户位于正确的选项卡上时,最常用的命令具有最直观的重点,用户只需单击一下即可调用它们。 用户最多只需单击四次即可在选项卡上执行所有其他命令。
- 用户不必打开对话框来提供常见任务中的命令和更改属性。
- 帮助用户自信地选择命令和选项,并最大程度地减少试用和错误的需求。 在适当的时候,通常以库和实时预览的形式使用面向结果的命令。
- 确保功能区能够很好地从最大窗口大小扩展到最小窗口大小。
设计概念
在现有程序中调整功能区
虽然你可能只是将现有程序的传统菜单栏和工具栏设计重构为功能区格式,但这样做会错过使用功能区的大部分值。 当功能区用于显示面向结果的即时命令时,功能区具有最大的价值,通常以库和实时预览的形式显示。 面向结果的命令使命令更易于理解,用户更高效、更高效。 与其重构现有命令,不如完全重新设计在程序中执行命令的方式。
不要低估创建有效功能区的挑战。 不要理所当然地认为,使用功能区会自动使程序变得更好。 创建有效的功能区需要花费大量时间和精力。 愿意投入此类命令重新设计所需的时间和精力是决定使用功能区的一个重要因素。
功能区的性质
与传统菜单栏和工具栏相比,功能区具有以下特征:
- 单个用户界面 (所有命令的 UI) 。 菜单栏全面且易于学习,工具栏高效且直接,但为什么不多一点的屏幕空间来创建一个完成所有这些操作的命令 UI 呢? 只有一个 UI,功能区不需要用户确定哪个 UI 具有他们要查找的命令。
- 可见且一目了然。 菜单栏命令在其标签中是一目了然的,但大部分时间都隐藏在视图中。 为了节省屏幕空间,工具栏按钮主要由图标表示,而不是标签 (尽管某些工具栏按钮使用) ,并且当图标不一致时依赖于工具提示。 但是,用户通常只知道最常用的命令的图标。
- 通过提供带标记图标的大多数命令,功能区命令既可见又不言自明,并且仅使用工具提示来提供补充信息。 无需转到其他位置 ((例如帮助) )来了解命令。
- 标记分组。 虽然菜单类别已标记,但下拉菜单中的组不是,并且仅使用未标记的分隔符进行指示。 工具栏中的组也使用未标记的分隔符进行指示。
- 通过在带标签的组中组织命令,功能区可以更轻松地查找命令并确定其用途。
- 模式,但不分层。 菜单栏通过创建命令层次结构进行缩放。 包含多个项的菜单可以使用一个或多个级别的子菜单来提供更多命令。
- 功能区命令需要比工具栏命令更多的空间,因此它们使用选项卡进行缩放。 选项卡的这种使用使功能区模式化,要求用户偶尔更改模式来查找命令。 但是,在选项卡中,大多数命令都是直接的,或者使用单个拆分按钮或菜单按钮,而不是层次结构。
- 直接和即时。 如果通过单击 (调用命令,则命令是直接的,即,无需浏览菜单) ;如果立即生效 (则立即生效,则无需对话框来收集其他输入) 。 菜单栏命令始终是间接的,通常不是即时的。 与工具栏一样,大多数功能区命令设计为直接和即时的,只需单击一下即可调用最常用的命令,而无需对话框收集其他输入。
- 宽敞。 菜单栏和工具栏主要设计为节省空间。 为了提供其优势,功能区可能会消耗更多的垂直空间,大致相当于菜单栏加上三行工具栏。 因为很少有程序有三行或更多行工具栏,功能区通常比传统的 UI 占用更多的空间用于命令。
- 具有“应用程序”按钮和“快速访问工具栏”。 功能区始终显示“应用程序”按钮和“快速访问工具栏”。 这样,用户无需更改选项卡即可访问与文件相关的常用命令,并提升程序之间的一致性。
- 最少的自定义。 虽然菜单栏具有固定的演示文稿,但许多工具栏是可自定义的,允许用户设置位置、大小和内容。 功能区本身不可自定义,但快速访问工具栏提供有限的自定义。
- 改进了键盘辅助功能。 菜单栏具有出色的键盘辅助功能,因为按 Alt 键直接为菜单栏提供输入焦点。 但是,工具栏没有此类机制,因为它们与窗口的内容共享键盘导航。 因此,用户必须使用 Tab 键 (() 最后一个制表位)导航到工具栏,然后使用箭头键导航到特定命令。
相比之下,功能区通过 键提示提供增强的键盘辅助功能,通常由三个步骤完成:
按 Alt 进入键提示模式。
按字符选择选项卡、“应用程序”按钮或快速访问工具栏中的命令。
在选项卡中,按一两个字母以选择命令。
此方法高度直观。 它还更灵活,可以更好地缩放,并获得更多助记访问密钥分配。
不要将访问键与快捷键混淆。 虽然访问键和快捷键都提供对 UI 的键盘访问,但它们具有不同的用途和准则。 有关详细信息,请参阅 键盘。
丰富命令的性质
丰富命令是指功能区使用的命令的演示和交互,而无需使用功能区容器。 丰富的命令具有以下特征:
标记。 所有命令都提供一目了然的标签,但仅当图标非常已知且空间处于溢价状态时才例外。
正确:
这些命令非常广为人知,因此它们不需要标签。
不正确:
这些难以理解的图标需要用于丰富命令的标签。
施 胶。 命令的大小不是统一调整,而是根据其使用频率和重要性进行大小调整。 除了使最常用的命令更易于查找和单击外,它还使它们更易于 触摸。
在此示例中,最常用的按钮比其他按钮大。
动态大小调整。 丰富的命令控件调整自身大小以充分利用可用空间,而不是使用固定大小,在大小太小时截断或使用溢出。
在此示例中,命令按钮调整大小以在可用空间中正常工作。
拆分按钮。 拆分按钮是在需要时合并命令的一组变体的好方法,同时保持最常用的命令的直接性。
在此示例中,“另存为”命令使用拆分按钮,其中main按钮执行最常见的变体,菜单部分显示具有命令变体的菜单。
丰富的下拉菜单和库。 下拉菜单、下拉列表和库占用了沟通和区分选项效果所需的空间,通常使用图形和文本说明。 类别用于组织大型选项集。
在这些示例中,单击菜单按钮会显示显示其效果的选项列表。
实时预览。 每当用户将鼠标悬停在格式设置选项上时,程序都会使用实际内容显示该格式的结果。
实时预览显示悬停时应用格式设置选项的结果。
增强的工具提示。 这些简单明了地解释了其关联的命令,并提供了快捷键。 它们可能还包括帮助 (的图形和引用,尽管它们在很大程度上不需要与命令相关的帮助) 。
增强的工具提示简洁地说明其关联的命令。
虽然功能区可能不适合所有程序,但所有程序都可能受益于丰富的命令。
功能区始终具有“应用程序”按钮和“快速访问工具栏”
“应用程序”按钮和“快速访问工具栏”提供在任何上下文中都有用的命令,从而减少更改选项卡的需求。 虽然这三个组件在逻辑上是独立的,但功能区必须始终具有“应用程序”按钮和“快速访问工具栏”。 鉴于命令可以进入功能区或应用程序按钮,你可能想知道在何处放置命令。 选择不是任意的。
“应用程序”按钮用于显示一个命令菜单,这些命令涉及对文件执行某些操作或使用文件,例如传统上在“文件”菜单中用于创建、打开和保存文件、打印、发送和发布文档的命令。
相比之下,功能区本身适用于影响窗口内容的命令。 示例包括用于读取、修改或使用内容或更改视图的命令。
如果使用功能区,则即使程序不涉及文档或文件,也必须使用“应用程序”按钮。 在这种情况下,请使用“应用程序”菜单显示用于打印、程序选项和退出程序的命令。 虽然可以说,应用程序按钮对于此类程序来说并不需要,但使用它可以跨程序提供一致性。 用户无需搜寻保存和撤消命令或程序选项,因为它们始终位于同一位置。
即使功能区仅使用一个选项卡,也需要快速访问工具栏。同样,虽然此类程序不需要快速访问工具栏 (因为所有命令都已存在于单个选项卡) ,但具有可自定义的快速访问工具栏可跨程序提供一致性。 例如,如果用户习惯于单击“打印”命令,他们应该能够在使用功能区的任何程序中执行此操作。
组织和可发现性
通过提供选项卡和组,功能区允许你组织命令以帮助发现。 挑战在于,如果组织做得不好,可能会极大地损害可发现性。 命令与它们所在的描述性标签选项卡和组之间应有清晰、明显且独特的映射。
使用一段时间后,用户将形成功能区的心理模型。 如果这种心理模型对用户没有意义、效率低下或不正确,则会导致混淆和沮丧。 设计功能区的最重要目标是方便快速、自信地查找命令。 如果不完成此操作,功能区设计将失败。 要实现此目标,需要仔细设计、用户测试和迭代。 不要认为这很容易。
下面是一些需要避免的常见缺陷:
- 避免使用泛型选项卡和组名称。 良好的选项卡或组名称必须准确描述其特定内容,最好使用基于任务和目标的语言。 避免使用泛型选项卡和组名称,以及基于技术的名称。 例如,创建和创作程序的文档中几乎任何命令都可以属于标记为“编辑”、“格式”、“工具”、“选项”、“高级”和“更多”的选项卡。 依赖于特定的描述性标签,而不是记忆。
- 避免过度特定的选项卡和组名称。 虽然我们希望选项卡和组名称是具体的,但它们不应如此具体,以至于用户对其内容感到惊讶。 用户经常使用消除过程查找内容,因此防止他们忽略选项卡或组,因为名称具有误导性。
- 避免使用同一命令的多个路径,尤其是在路径意外或命令需要多次单击才能调用时。 通过多个路径查找命令似乎是一种方便。 但请记住,当用户找到他们要查找的内容时,他们就会停止查找。 用户很容易认为他们找到的第一条路径是唯一的路径,如果路径效率低下或意外,则这是一个严重的问题。 此外,具有重复的命令会使用户更难找到要扫描的其他命令。
在此示例中,你可以通过“页面边框”命令更改段落边框,即使“开始”选项卡上有一个更直接的路径。如果查找段落边框的用户偶然发现了此意外路径,他们可能很容易认为这是唯一的路径。
- 避免任意放置命令。 假设你认为选项卡和组设计良好,但发现多个命令不适合。 选项卡和组设计可能不如你想象的那么好,你需要继续优化它。 不要通过将这些命令放在它们不属于的位置来解决此问题。 如果这样做,用户可能必须检查每个选项卡才能找到它们,然后立即忘记他们的位置。
- 避免基于营销的放置。 假设你有新版本的程序,并且你的营销团队确实想要推广其新功能。 将它们放在“主页”选项卡上可能很诱人,但如果这样做会损害整体可发现性,则这是一个代价高昂的错误。 考虑产品的未来版本,以及不断变化的组织将带来多大的挫折感。
制表符
最好的第一步是查看 标准功能区选项卡。 如果程序的命令自然映射到标准选项卡,则选项卡组织基于这些标准。 另一方面,如果编程的命令不自然映射,请不要尝试强制它。 确定更自然的结构,并确保执行大量用户测试,以确保正确。
对于非标准选项卡,请考虑以下问题:
- 每个选项卡名称都应描述其内容。 选择有意义的名称,这些名称是特定的,但不是太具体。 用户不应对其内容感到惊讶。
- 每个选项卡名称都应反映其用途。 考虑与命令关联的目标或任务。
- 每个选项卡名称应明显不同于所有其他选项卡名称。
“开始”选项卡是这些注意事项的例外。 虽然你不必有“开始”选项卡,但大多数程序应该。 “开始”选项卡是第一个选项卡,包含最常用的命令。 如果常用命令不适合其他选项卡,则“开始”选项卡是适合它们的位置。
如果无法确定有意义的描述性选项卡名称,可能是因为选项卡设计不良好。 如果功能区组织无法正常工作,请重新考虑选项卡设计。
组
将命令划分为组结构,将命令划分为相关集。 组标签说明了其命令的共同用途。
在确定组及其呈现时,需要考虑多种因素:
- 标准分组。 虽然程序之间的命令存在显著差异,但标准 组 在许多程序中是通用的。 让这些命令以相同的名称和相似的位置显示可极大地提高可发现性。
正确 | 不正确 |
---|---|
编辑命令组包括所有编辑命令,但不包括 Zoom 命令。 |
Zoom 命令不是编辑命令,而是在编辑组中。 |
- 粒度。 某些结构很好,但过多的结构会使命令更难找到。 如果组名称是泛型的,则可能没有足够的粒度。 如果有每个组只有一个或两个命令,则你可能有太多的 (尽管在一个组中没有任何其他命令的功能区内库是可接受的) 。
正确 | 不正确 |
---|---|
编辑命令组包括所有编辑命令 |
编辑命令组已拆分为过于精细的部分。 避免只使用一两个命令的组。 |
- 名称。 良好的组名称说明了其命令的用途。 如果组名称没有,请重新考虑名称或分组。 如果无法确定有意义的描述性名称,可能是因为组设计不好。
正确 | 不正确 |
---|---|
使用足够具体的组名称来描述组中包含的命令。 |
此组名称过于模糊,无法提供帮助。 更好的方法是将这些命令重新组织到更具体的组中。 |
- 以。 人员从左到右的顺序阅读 (西方文化) ,因此你可能会认为最左边的群体是最明显的。 但是,突出显示的选项卡名称和窗口内容往往充当 焦点,因此选项卡中央的组通常比最左侧的组受到更多的关注。 将最常用的组放在最突出的位置,并确保整个选项卡中的组有逻辑流。
在此示例中,“字体”和“段落”组比剪贴板组更明显,因为它们是从文档上移时眼睛首先看到的。
在此示例中,跟踪组受到最多关注,部分原因是突出显示的“审阅”选项卡充当焦点。
- 均匀。 当命令演示文稿看起来都相同时,可能很难识别命令。 使用具有不同形状和颜色的图标、具有不同格式的组以及具有不同大小的命令,使用户能够更轻松地识别命令组。 仅当功能区缩小到较小的大小时,命令才应具有统一的大小。
正确 | 不正确 |
---|---|
使用各种图标大小来提高可识别性 |
这些命令看起来太相似了,因为它们的大小都相同。 |
预览版
可以使用各种类型的预览来显示命令的结果。 通过使用有用的预览,可以提高程序的效率,并减少对试错学习方法的需求。 实时预览还邀请试验并激发创造力。
下面是可以使用的一些不同类型的预览:
- 逼真的静态图标和图形。 提供命令效果的真实指示的静态图像。 这些可用于库、下拉菜单和增强的工具提示。
在此示例中,“字体”下拉列表使用字体本身显示每个字体名称。
在此示例中,使用逼真的缩略图来显示不同的水印。
- 动态图标和图形。 经过修改以反映当前状态的图标和图形。 此类图标对于库以及将默认效果更改为与上一个操作相同的拆分按钮特别有用。
在此示例中,Microsoft Word更改样式库以反映当前样式。
在此示例中,Word更改文本突出显示颜色和字体颜色命令以指示其当前效果。
- 实时预览。 当用户将鼠标悬停在格式设置选项上时,实时预览会显示该格式的结果。 实时预览可帮助用户根据用户的实际上下文更高效、更自信地进行选择。
在此示例中,“页面颜色”命令通过显示鼠标悬停时的颜色选项的效果来执行实时预览。
实时预览是一项功能强大的功能,可以真正提高用户的工作效率,但即使是简单的静态预览也有很大的帮助。
缩放功能区
缩放工具栏很简单:如果窗口太窄而无法显示工具栏,则工具栏会显示适合的内容,并通过溢出按钮访问其他所有内容。 丰富命令的目标是充分利用可用空间,因此缩放功能区需要更多的设计工作。 没有默认功能区大小,因此不应在设计功能区时考虑到特定的宽度。 你必须设计宽广的布局,并意识到其中任何一个都可以是大多数用户看到的布局。 缩放是功能区设计的基本部分,而不是最后一步。 设计选项卡时,请为每个组指定不同的布局, (最多三个) 以及可以一起使用的组合。 功能区将显示适合当前窗口大小的最大有效组合。
工具栏使用溢出按钮进行缩放。
没有默认功能区大小。 最小大小是单个弹出组图标。
准则
常规
- 不要将功能区与窗口中的菜单栏和工具栏组合在一起。 功能区必须用于代替菜单栏和工具栏。 但是,功能区可以与调色板窗口和导航元素(例如“后退”和“前进”按钮以及地址栏)结合使用。
- 始终将功能区与“应用程序”按钮和“快速访问工具栏”组合在一起。
- 启动程序时,选择最左侧的选项卡 (通常为“主页) ”。 不要使最后一个所选选项卡在程序实例之间持久化。
- 首次启动程序时,以正常状态显示功能区 (不会最小化) 。 用户通常保留默认设置不变,因此在程序启动时最小化功能区可能会导致所有命令的效率降低。 此外,最初显示功能区最小化可能迷失方向。
- 使功能区状态在程序实例之间持久化。 例如,如果用户最小化功能区,则应在下次运行程序时将其最小化。 但同样,不要以这种方式保留最后一个所选选项卡。
使用选项卡
通常,选项卡越少越好,因此请删除无助于实现这些目标的选项卡。
- 只要可行,请使用标准选项卡。 使用标准选项卡可极大地提高可发现性,尤其是跨程序。 请参阅本文后面的 标准功能区选项卡 。
- 标记第一个选项卡“主页”(如果适用)。 “开始”选项卡应包含最常用的命令。 如果常用命令不适合其他选项卡,则“开始”选项卡是适合它们的位置。
- 在以下的情况下添加新选项卡:
- 其命令与特定任务密切相关,可通过选项卡标签进行准确描述。 添加选项卡应有助于使其命令易于查找,而不是更难查找。
- 其命令大多与其他选项卡上的任务无关。 在通常执行的任务期间,添加选项卡不应需要更多选项卡切换。
- 选项卡有足够的命令来证明有一个额外的位置进行查找。 没有只包含几个命令的选项卡。 例外: 如果选项卡与特定任务密切相关,请考虑添加包含几个命令的选项卡,添加该选项卡可大大简化过于复杂的“开始”选项卡。
- 对于剩余的选项卡,首先放置最常用的选项卡,同时跨选项卡保持逻辑顺序。
- 优化选项卡设计,以便用户快速、自信地找到命令。 所有其他注意事项都是次要的。
- 不要提供“帮助”选项卡。 相反,请使用程序范围的帮助和增强的工具提示来提供帮助。
- 最多使用七个核心选项卡。 如果超过 7 个,则很难确定哪个选项卡具有命令。 虽然七个核心选项卡对于具有许多命令的应用程序是可以接受的,但大多数程序应针对四个或更少的选项卡。
上下文选项卡
- 使用上下文选项卡显示仅在用户选择特定对象类型时才相关的命令集合。 如果只有几个常用命令,则使用常规选项卡可能更方便、更稳定,只需在命令不适用时将其禁用。
禁用常见命令(如剪切和复制)比使用上下文选项卡更好。- 仅包含特定于特定对象类型的命令。 如果用户在未先选择对象的情况下可能需要命令,请不要仅将命令放在上下文选项卡上。
- 包括处理特定对象类型时经常使用的命令。 将常用常规上下文命令放在上下文菜单和微型工具栏上,以避免在经常执行的任务期间切换选项卡。 或者,如果这样做可以避免频繁切换选项卡,请考虑在上下文选项卡上冗余地放置常规命令。 但不要过分这样做 - 不要尝试包含用户在处理对象时可能需要的每个命令。
在此示例中,“设计”选项卡上包含 Borders 命令,以避免在经常执行的任务期间频繁切换选项卡。\- 选择与当前显示的上下文选项卡不同的上下文选项卡颜色。 为了达到此目的,以后可以使用不同的颜色显示同一选项卡集,但尽量尝试在调用之间使用一致的颜色分配。
- 选择上下文选项卡可自动 帮助发现,提高稳定性感知,并减少切换选项卡的需求。 在执行以下操作时自动选择上下文选项卡:
- 用户插入对象。 在这种情况下,请选择集中的第一个上下文选项卡。
- 用户双击对象。 在这种情况下,请选择集中的第一个上下文选项卡。
- 用户选择了上下文选项卡,单击对象,然后立即单击同一类型的对象。 在这种情况下,返回到以前选择的上下文选项卡。
- 删除活动选项卡的上下文选项卡时,将“开始”选项卡或第一个选项卡设为活动选项卡。 这样做似乎最稳定。
模式选项卡
- 使用模式选项卡可显示适用于特定临时模式且未应用任何核心选项卡的命令集合。 如果某些核心选项卡适用,请改用上下文选项卡,并禁用不适用的命令。 由于模式选项卡非常有限制,因此应仅在没有更好的替代方法时才使用它们。
打印预览是常用的模式选项卡。- 若要关闭模式选项卡,请将“关闭 <模式> ”命令作为选项卡上的最后一个命令。 使用“关闭”图标使命令易于查找。 在 命令中提供 模式,以防止混淆正在关闭的内容。
在此示例中,使用 模式显式标记 Close 命令可消除对关闭内容的任何疑问。- 若要关闭模式选项卡,还需重新定义窗口标题栏上的“关闭”按钮,以关闭模式而不是程序。 用户测试表明,许多用户期望此行为。
标准功能区选项卡
只要可行,请将程序的命令映射到这些标准选项卡,按其标准外观顺序给出。
常规选项卡
- 家。 包含最常用的命令。 如果使用,它始终是第一个选项卡。
- 插入。 包含用于将内容和对象插入文档中的命令。 如果使用,则始终为第二个选项卡。
- 页面布局。 包含影响页面布局的命令,包括主题、页面设置、页面背景、缩进、间距和定位。 (请注意,缩进和间距组可以位于“开始”选项卡上,如果有足够的空间,) 则它始终为第三个选项卡。
- 检讨。 包含用于添加注释、跟踪更改和比较版本的命令。
- 视图。 包含影响文档视图的命令,包括视图模式、显示/隐藏选项、缩放、窗口管理以及传统上在 Windows 菜单类别中找到的命令的宏。 如果使用,除非显示“开发工具”选项卡,否则它是最后一个常规选项卡。
- 开发人员。 包含仅由开发人员使用的命令。 如果使用,则默认隐藏该选项卡,并在显示时隐藏最后一个常规选项卡。
大多数程序不需要“审阅”和“开发人员”选项卡。
标准上下文选项卡
- 格式。 包含与更改所选对象类型的格式相关的命令。 通常适用于 对象的一部分。
- 设计。 包含用于将样式应用于所选对象类型的命令(通常位于库中)。 通常应用于整个 对象。
- 布局。 包含用于更改复杂对象(如表或图表)结构的命令。
如果具有与格式、设计和布局相关的上下文命令,但不足以用于多个选项卡,只需提供“格式”选项卡即可。
标准组
- 只要可行,请使用标准组。 使用相同名称和相似位置显示常见命令可极大地提高可发现性。 请参阅本文后面的 标准功能区组 。
- 在以下的情况下添加新组:
- 其命令关联性强,组标签可以准确描述。 添加组应有助于使其命令易于查找,而不是更难查找。
- 其命令与其他组中的命令的关系较弱。 虽然选项卡上的所有命令都应紧密相关,但某些命令关系比其他命令关系更强。
- 该组有足够的命令来证明有一个额外的位置进行查看。 针对大多数组使用 3-5 个命令。 避免使用只有 1-2 个命令的组,尽管在一个组中没有任何其他命令的功能区内库是可以接受的。 具有单个命令的许多组意味着结构过多或缺乏命令凝聚力。
- 不要通过添加不需要的组来过度组织。
- 在以下的情况下,请考虑拆分组:
该组有许多不同大小且需要组织的命令。
组的命令从具有额外标签中获益匪浅。
- 将最常用的组放在最突出的位置,并确保各选项卡的组有逻辑顺序。
- 优化组设计,使用户能够快速、自信地找到命令。 所有其他注意事项都是次要的。
- 不要将包含单个按钮的组缩放为弹出组图标。 纵向缩减时,请将其保留为单个按钮。
- 最多使用七个组。 如果组数超过 7 个,则确定哪个组具有命令会变得更加困难。
标准功能区组
只要可行,即可将程序的命令映射到这些标准组,这些组在其关联的选项卡中按其标准外观顺序提供。
主选项卡
- 剪贴板
- 字体
- Paragraph
- 编辑
“插入”选项卡
- 表
- 图示
“页面布局”选项卡
- 主题
- 页面设置
- 排列
“审阅”选项卡
- 校对
- 注释
“视图”选项卡
- 文档视图
- 显示/隐藏
- 缩放
- 窗口
命令
通过公开所有常用命令,充分利用功能区的可发现性和可伸缩性。 适当时,将常用命令从对话框移动到功能区,尤其是那些已知很难找到的命令。 理想情况下,用户应该能够在不使用任何对话框的情况下执行常见任务。不要使用功能区的可伸缩性来证明增加不必要的复杂性。 继续练习限制不要仅仅因为可以向功能区添加命令。 保持整体命令体验简单。 以下是简化演示文稿的方法:
的屏幕截图将上下文菜单和微型工具栏用于就地上下文命令。- 在对话框中移动 (或保留) 很少使用的命令。 使用对话框启动器访问这些命令。 你仍然可以将对话框与功能区配合使用! 只需尝试减少在常见任务期间使用它们的需求。
- 消除冗余的、很少使用的功能。
呈现
仅在一个选项卡上显示每个命令。避免使用同一命令的多个路径,尤其是当命令需要多次单击才能调用时。 通过多个路径查找命令似乎是一种方便。 但请记住,当用户找到他们要查找的内容时,他们就会停止查找。 用户很容易认为他们找到的第一条路径是唯一的路径,如果路径效率低下,这是一个严重的问题。 例外: 如果这样做会阻止更改常见上下文任务的选项卡,上下文选项卡可能会复制“开始”和“插入”选项卡中的一些命令。
在组中,按逻辑顺序放置命令,同时优先使用最常用的命令。 总体而言,命令应具有逻辑流,使其易于查找,同时仍然首先显示最常用的命令。 通常,具有 32x32 像素图标的命令显示在具有 16x16 像素图标的命令之前,以帮助跨组扫描。
避免在常用命令旁边放置破坏性命令。 如果命令的效果很普遍,并且无法轻易撤消或效果不立即明显,则命令被视为破坏性。
使用分隔符指示强相关的命令,例如一组互斥选项。
请考虑对不需要标签的强相关、已知命令集使用工具栏样式组。 这样,就可以在紧凑的空间中呈现许多命令,而不会影响可发现性和学习的便利性。 众所周知,此类命令经常使用,可立即识别,因此往往位于“主页”选项卡上。对最常用的和重要的标记命令使用 32x32 像素图标。 向下缩放组时,使这些命令成为最后一个可转换为 16x16 像素图标的命令。
避免任意放置命令。 仔细考虑选项卡和组设计,以确保用户不会浪费时间检查每个选项卡以找到所需的命令。
避免基于营销的放置。 围绕新功能推广的营销目标往往随着时间的推移而变化。 考虑产品的未来版本,以及不断变化的组织将带来多大的挫折感。
交互
禁用不适用于当前上下文或直接导致错误的命令。 如果有帮助,请使用 增强的工具提示 解释禁用命令的原因。 不要隐藏此类命令,因为这样做可能会导致功能区布局发生更改,使功能区演示文稿不稳定。
不要动态更新命令标签。 同样,这样做可能会导致选项卡布局发生更改,从而导致外观不稳定。 相反,应设计命令,使其使用常量标签。
正确 不正确
在命令不可用时禁用命令
请勿隐藏命令,即使命令不可用首选直接控件。 如果通过单击 (调用命令,则命令是直接的,也就是说,无需在菜单) 导航。 但是,除了功能区内库外,直接控件不支持实时预览,因此需要实时预览也是一个因素。
当命令属于一组相关的格式设置选项时,使用实时预览来指示选项的效果,而实时预览非常重要且实用,尤其是在用户可能选择错误的选项时。
- 如果频繁使用命令,请使用功能区内库来获得直接性。
- 如果命令不常使用,请使用下拉库。
按以下优先顺序使用以下控件公开直接命令
- 命令按钮、检查框、单选按钮和就地库。 这些始终是直接的。
- 拆分按钮。 直接表示最常见的命令,但间接表示命令变体。
- 菜单按钮。 这些是间接的,但提供了许多易于查找的命令。
- 带有旋转控件) (文本框。 文本输入通常比其他控件类型更费力。
的功能区的屏幕截图如果功能区在以完整大小显示时主要由菜单按钮组成,则不妨使用菜单栏。首选即时命令。
如果命令立即生效, (即,没有用于收集其他输入) 的对话框,则命令立即生效。 如果命令可能需要输入,请考虑使用拆分按钮(按钮部分包含即时命令)和需要子菜单输入的命令。
库
在以下的情况下使用库:
- 用户通常会从中选择一组定义完善的相关选项。 可能有无限数量的变体,但可能的选择应很好地包含。 如果这些选项没有很强的相关性,请考虑使用单独的库。
- 选项最好以视觉方式表示,例如格式设置功能。 使用缩略图可以更轻松地浏览、理解和做出选择。 虽然可以标记选项,但选择是直观地进行的,不应要求文本标签来理解这些选择。
- 这些选项显示单击即可立即实现的结果。 不应有任何后续对话框来进一步阐明用户的意图,也不应有一组步骤来实现指示的结果。 如果用户可能想要调整选择,请稍后让他们这样做。
在以下的情况下使用功能区内库:
- 这些选项经常使用。 选择需要空间,并且值得从其他命令中获取的空间。
- 对于典型用法,无需对所提供的选项进行分组或筛选。
- 选项可以在功能区的高度内有效显示, (为 48 像素) 。
库中的缩略图
选择能够很好地完成作业的最小标准库缩略图大小。
- 对于功能区内库,请使用 16x16、48x48 或 64x48 像素的缩略图。
- 对于下拉库,请使用 16x16、32x32、48x48、64x48、72x96、96x72、96x96 或 128x128 像素的缩略图。
- 所有库项的缩略图大小应相同。
对于功能区内库:
- 至少显示三个选项;如果有空间,则更多。 如果没有足够的空间来显示典型窗口大小中的至少三个选项,请改用下拉库。
- 展开功能区内库以利用可用空间。 使用额外的空间显示更多项目,并使它们更易于选择,只需单击一下。
对于下拉库:
- 通过组合框、下拉列表、拆分按钮或菜单按钮显示库。
- 如果用户单击main窗口关闭下拉库,只需关闭库,而不选择或修改main窗口的内容。
- 如果库有许多选项,但很少使用某些选项,请通过专注于常用选项来简化默认库。 对于剩余的命令,请在库下拉列表底部提供相应的命令。
- 如果命令显示更多变体的列表,请将其命名为“更多
singular feature name
选项...” - 如果命令显示允许用户创建自己的自定义选项的对话框,请将其命名为“自定义
feature name
...”
- 如果命令显示更多变体的列表,请将其命名为“更多
- 将选项组织成组,如果这样做可提高浏览效率。
如果库包含许多项,请考虑添加筛选器,以帮助用户更有效地查找选项。 为了避免混淆,最初显示未筛选的库。 但是,大多数库不应要求筛选器,因为它们不应有太多选择,并且使用组应该就足够了。
命令预览
- 使用预览显示命令的效果,用户无需先执行该命令。 通过使用有用的预览版,可以提高效率和轻松学习程序,并减少对试错的需求。 有关不同类型的命令预览,请参阅本文设计概念部分中的 预览 。
- 对于实时预览,请确保可以应用预览并在 500 毫秒内还原当前状态。 这样做需要能够以可中断的方式快速应用格式设置更改。 用户必须能够快速评估不同的选项,实时预览版才能获得其全部权益。
- 避免在预览中使用文本。 否则,预览图像必须本地化。
图标
为所有功能区控件提供图标,下拉列表、检查框和单选按钮除外。 大多数命令都需要 32x32 和 16x16 像素图标, (快速访问工具栏) 仅使用 16x16 像素图标。 库通常使用 16x16、48x48 或 64x48 像素图标。提供唯一的图标。 不要对不同的命令使用相同的图标。
确保功能区图标在功能区背景色上清晰可见。 始终在上下文和高对比度模式下评估功能区图标。
选择能清楚地传达其效果的图标设计, 尤其是对于最常用的命令。 设计良好的功能区具有一目了然的图标,可帮助用户有效地查找和理解命令。
选择可识别和可区分的图标, 尤其是对于最常用的命令。 确保图标具有独特的形状和颜色。 这样做可帮助用户快速找到命令,即使他们不记得图标符号也是如此。
正确 不正确
使用形状和颜色使图标易于区分。
颜色相同的图标很难区分
请考虑通过将组中最突出命令的 16x16 像素图标放置在 32x32 像素视觉对象容器内来创建弹出组图标。 无需为弹出组创建不同的图标。
如果有用,请更改图标以反映当前状态。 对于默认效果可能更改的拆分按钮,这样做特别有用。确保功能区图标符合 Aero 样式图标指南。 但是,功能区图标直接显示在 上,而不是以透视方式显示。
正确 | 不正确 |
---|---|
使用二维图标。 |
请勿使用三维图标。 |
增强的工具提示
所有功能区命令都应具有增强的工具提示 ,以提供命令名称、快捷键、说明和可选的补充信息。 避免使用只是重述标签的工具提示。
不正确:
在此示例中,工具提示只是重述命令标签。
如果可行,请使用简洁的说明完全描述命令。 仅当确实需要进一步解释时才链接到帮助。
不正确:
在此示例中, 命令不需要帮助。
如果有帮助,请使用预览演示命令的效果。
在此示例中,工具提示图像演示了命令的效果。
有关标记指南,请参阅 增强的工具提示标签。
访问密钥和快捷键提示
快捷键提示是用于显示直接显示在功能区上的命令的访问键的机制。
下拉菜单命令的访问键以带下划线的字符表示。 它们在以下方面不同于菜单访问键:
可以使用两个字符的访问键。 例如,FP 可用于访问格式刷命令。
访问键分配使用提示而不是下划线显示,因此字符宽度和降序不是进行分配的因素。
为所有功能区选项卡和命令分配访问键。 唯一可能的例外是来自旧版外接程序的命令。
对于“应用程序”按钮和“快速访问工具栏”:
- 将 F 分配给“应用程序”按钮。 之所以使用此分配,是因为“应用程序”按钮与传统的“文件”菜单相似。
对于“快速访问工具栏”和最近使用的文件列表,请以数字方式分配访问键。
对于选项卡:- 将 H 分配到主页。
- 从最常用的选项卡开始,分配标签的第一个字母。
- 对于无法分配给第一个字母的任何选项卡,请在标签中选择独特的辅音或元音。
- 对于用于支持菜单栏的程序,请尽量保持访问键兼容性。 避免为旧菜单类别中的访问键分配不同的含义。 例如,如果程序的旧菜单栏版本具有“编辑”菜单,请尽量使用 E 访问键访问等效选项卡。如果没有等效的选项卡,请不要向任何选项卡分配 E 访问密钥,以免混淆。
对于功能区命令、菜单和子菜单:- 在选项卡中分配唯一的访问键组合。可以在不同选项卡中重复使用访问键组合。
- 尽可能为常用命令分配标准访问密钥。 请参阅 标准访问密钥表。
- 对于其他命令:
- 对于最常用的命令,请选择标签第一个或第二个单词开头的字母,最好是第一个字母。
- 对于不太常用的命令,请选择标签中具有独特辅音或元音的字母,例如“退出”中的“x”。
- 对于最不常用的命令和对话框启动器,请根据需要使用两个字母。
- 对于菜单和子菜单,请使用单个字母来减少完整命令所需的击键次数。
- 请勿使用以 J、Y 或 Z 开头的访问密钥,因为它们用于上下文选项卡、未分配的密钥提示和弹出组。
对于弹出组:- 使用以 Z 开头的双字母访问密钥。
- 从最常用的组开始,将第二个访问键字母分配给标签的第一个字母。
- 对于剩余的任何组,请在标签中选择一个独特的辅音或元音。
有关快捷键指南,请参阅 键盘。
应用程序按钮
使用“应用程序”按钮显示命令菜单,这些命令涉及对文件执行某些操作或使用文件。 示例包括传统上在“文件”菜单中用于创建、打开和保存文件、打印、发送和发布文档的命令。
使用功能区时,始终提供“应用程序”按钮。 如果程序不使用文件,请使用“应用程序”按钮访问程序选项和“退出”命令。 应用程序按钮始终显示命令菜单,它们绝不是装饰性的。
如果适用,请使用以下标准应用程序菜单命令:
- 新建
- 打开
- 保存
- 另存为...
- 打印...
- 快速打印
- 打印预览
- 关闭
- 选项
- 退出
仅为该菜单保留属于“应用程序”菜单中的命令。 不要将它们冗余地放置在任何选项卡中。
对于每个菜单项,请提供:
- 具有命令名称的标签。
- 32x32 像素图标。
- 简要说明。 确保最多可以使用两行文本显示说明。
使用工具提示记录快捷键。 与普通菜单不同,应用程序菜单不使用标签记录快捷键。
快速访问工具栏
- 使用快速访问工具栏提供对常用命令的访问权限。 命令可以来自“应用程序”按钮或功能区。
- 使用功能区时,始终提供快速访问工具栏。 即使功能区有一个选项卡,也要这样做;这提供了程序之间的一致性。
- 使用“应用程序”菜单中常用命令预填充快速访问工具栏。 如果程序支持保存和撤消,则提供“保存和撤消”;如果支持且经常使用,则提供“打开和打印”。
- 对于“自定义快速访问工具栏”菜单,提供最多 12 个最常用的即时命令。 即时命令在生效之前不需要其他输入,因此非常适合快速访问工具栏。 虽然这些命令可以是任何即时命令,但首选不在“主页”选项卡上的命令,因为用户更有可能选择这些命令。
- 对于“自定义快速访问工具栏”菜单,如果有一对相关的命令,请同时提供这两个命令,而不考虑频率。 常见的对是“打开/关闭”、“后退/向前”和“撤消/恢复”。
- 对于“自定义快速访问工具栏”对话框,提供一种添加任何命令的方法。 提供显示最常用的命令的常用命令筛选器,并默认选择此筛选器。
对话框启动器
如果存在包含不常使用的命令和设置的相关对话框,请为组提供对话框启动器。 该对话框应包含组中的所有命令,以及其他命令,而不是与组完全不同的命令集或相同的命令。请勿使用对话框启动器直接执行命令。 对话框启动器必须显示对话框。
请勿使用对话框启动器访问常用命令和设置。 与直接在功能区上的命令相比,对话框命令和设置相对不可发现。
将对话框的名称与组的名称匹配。 它不必完全匹配,但名称应该足够相似,这样用户就不会对结果感到惊讶。
不正确:
虽然提醒声音是提醒选项,但使用对话框启动器设置提醒声音是意外的。
仅显示与组相关的命令和设置。 如果对话框显示其他内容,则用户可能会得出结论,此指向其他命令和设置的路径是唯一的路径。
不正确:
在此示例中,“字体”对话框显示“字符间距”设置,这些设置与关联的选项卡无关。
标签
选项卡标签
- 标记所有选项卡。
- 只要可行 ,请使用标准功能区选项卡。
- 首选简洁的单字标签。 虽然多字标签是可以接受的,但它们需要更多空间,并且更难本地化。
- 选择明确准确地描述其内容的有意义的选项卡名称。 名称应是具体的,但不能过于具体。 选项卡名称应具有足够的可预测性,以便用户不会对其内容感到惊讶。 请注意,“开始”选项卡一般命名,因为它用于最常用的命令。
- 请勿 使用“Basic”和“Advanced”等组名称。它们要求用户确定他们要查找的命令是基本命令还是高级命令。
- 选择反映其用途的选项卡名称。 考虑与选项卡关联的目标或任务。
- 选择明显不同于所有其他选项卡名称的选项卡名称。
- 对选项卡使用名词或谓词。 选项卡名称不需要并行措辞,因此请选择最佳标签,无论它是名词还是动词。
- 不要 ( 以“-ing”) 结尾的名称使用杂项。 请改用从中派生格朗德的谓词。 (例如,使用“Draw”而不是“Drawing”。)
- 避免具有相同首字母的制表符名称,尤其是相邻的制表符。 缩减功能区时,这些选项卡名称将具有相同的截断文本。
- 首选单数名称。 但是,如果单数名称很尴尬,则可以使用纯名称。
- 使用标题样式大写。
- 不要使用结束标点符号。
上下文选项卡和选项卡集标签
- 使用“工具”结束上下文选项卡集标签。 这样做有助于确定上下文选项卡的用途。
- 使用标题样式大写。
- 不要使用结束标点符号。
组标签
标记所有组 ,除非组具有单个命令,并且组和命令标签相同。
请随时使用标准功能区组。
首选简洁的单字标签。 虽然多字标签是可以接受的,但它们需要更多空间,并且更难本地化。
选择可清晰准确地描述其内容的有意义的组名称。 名称应是特定的,而不是泛型的。
选择反映其用途的组名称。 考虑与组中的命令关联的目标或任务。
避免使用 以“-ing”) 结尾 (名称。 但是,如果使用从中派生格子的谓词,则可以使用 gerund 会让人感到困惑。 例如,使用“编辑”和“校对”,而不是“编辑”和“证明”。
请勿使用与选项卡名称相同的组名称。 使用组所属的选项卡名称不提供任何信息,并且使用其他选项卡的名称会让人感到困惑。
首选单数名称。 但是,如果单数名称很尴尬,则可以使用纯名称。
使用句式大写。
不要使用结束标点符号。
命令标签
- 标记所有命令。 使用显式文本标签可帮助用户查找和理解命令。 例外: 如果命令的图标非常已知且空间非常出色,则可以取消标记该命令。 未标记的命令很可能位于“开始”选项卡上。在这种情况下,将其 Name 属性分配给相应的文本标签。 这使辅助技术产品(如屏幕阅读器)能够为用户提供有关图形的替代信息。
- 对于命令按钮,请使用简明易懂的标签。 如果可能,请使用单个单词:最多四个单词。
- 对于下拉列表,如果列表始终具有值,请使用当前值作为标签。
如果 可编辑的下拉列表 没有值,请使用 提示。- 不一目了然或不常使用的下拉列表需要显式标签。 在标签的末尾放置冒号。
- <Br。>对于文本框,请使用显式标签。 在标签的末尾放置冒号。
- 使用句式大写。 这样做更适合 Windows 语气。
- 使用命令性谓词启动标签。 除非它与选项卡或组名称或常用谓词(如 Show、Create、Insert 或 Format)相同。
- 不要使用结束标点符号。
- 为节省空间,请勿在功能区命令标签上放置省略号。 但是,省略号由“应用程序”按钮和下拉菜单中的命令使用。
增强的工具提示标签
- 使用标题提供命令名称及其快捷键(如果适用)。
- 对于标题,请勿使用结束标点。
- 使用谓词开始描述。 使用说明可帮助用户确定特定功能是否是他们要查找的功能。 应将说明用到短语中,以完成句子“如果想要的话,这是要使用的正确功能...”。
- 使说明保持简短。 直接了解这一点。 较长的文本不鼓励阅读。
对于拆分按钮,请使用其他工具提示来说明拆分按钮菜单。- 使用可选的补充说明来说明如何使用 控件。 此文本可以包含有关控件状态的信息 (包括禁用它的原因) 如果控件本身不指示状态。 使此文本保持简短,并使用帮助主题进行更详细的说明。
- 对于说明和补充说明,请使用带有结尾标点符号的完整句子。
- 使用句式大写。
应用程序按钮标签
已选择“快速打印”选项的屏幕截图
使用“快速”指示命令的即时版本。使用省略号指示命令需要更多信息。
使用句式大写。
文档
引用功能区时:
- 将功能区及其组件称为功能区、选项卡、组和控件。 这些术语未大写。
- 将圆形按钮称为“应用程序”按钮,将其包含的菜单称为“应用程序”菜单。
- 将工具栏称为“快速访问工具栏”。
- 按标签和单词“选项卡”来引用选项卡。使用确切的标签文本,包括其大写。
- 按命令标签引用命令。 按其工具提示名称引用未标记的命令。 使用确切的标签文本(包括其大写),但不要包含省略号。 不要包含单词按钮或命令。
- 若要描述用户交互,请单击选项卡和控件。 对于可编辑的下拉列表,请使用 Enter。 请勿使用选择、选择或选取。
- 将不可用项称为不可用,而不是灰显、禁用或灰色。 在编程文档中,使用 disabled。
- 如果可能,请使用加粗文本设置标签的格式。 否则,仅在需要时才将标签置于引号中以防止混淆。
示例:
- 在“ 开始 ”选项卡上,单击“ 选择性粘贴”。
- 在“ 开始 ”选项卡上的“ 字体 ”框中,输入“Segoe UI”。
- 在“ 审阅 ”选项卡上,单击“ 显示标记”,然后单击“ 审阅者”。
- 在“ 格式 ”选项卡上的“ 图片工具”中,单击“ 压缩图片”。
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈