Win32 桌面应用程序用户体验清单

支持800×600像素的最小Windows有效分辨率。 对于必须在安全模式下工作的关键用户界面，支持640×480 像素的有效解决方法。请确保通过为任务栏中显示的 windows 保留48垂直相对像素来考虑任务栏使用的空间。
优化可调整大小的窗口布局，以有效分辨率1024×768 像素。 以仍正常运行的方式自动调整这些窗口的大小以降低屏幕分辨率。
请务必在 96 点/英寸 (dpi)（800×600 像素）、120 dpi（1024×768 像素）和 144 dpi（1200×900 像素）模式下测试您的窗口。 检查布局问题，如控件、文本和窗口的剪切，以及对图标和位图的拉伸。
对于具有触摸和移动使用场景的程序，优化为 120 dpi。高 dpi 屏幕目前在触控和移动 PC 上很流行。
如果是被拥有的窗口，最初将其显示在 “所有者” 窗口顶层的 “居中”位置。 永远不要在下方。对于后续显示，可以考虑在(相对于所有者窗口)的最后一个位置显示它，如果这样做能带来更多便利性。
如果窗口为上下文，则始终将其显示在从其启动的对象附近。 但是，请将其放在一边（最好向下和向右偏移），以便对象不会被窗口覆盖。

布局

调整窗口中控件和窗格的大小以匹配其典型内容。 避免截断文本及其关联的省略号。用户永远不需要与窗口进行交互即可查看其典型内容–为异常大的内容保留调整大小和滚动。特别要检查：
- 控件大小。 根据其典型内容调整控件大小，必要时使控件更宽、更高或多行。调整控件大小以消除或减少在 windows 中有充足可用空间的滚动。此外，在有足够可用空间的窗口中，永远不应有截断的标签或截断的文本。但是，为了使文本更易于阅读，请考虑将行宽限制为 65 个字符。
- 列宽。 确保列表视图列具有适当的默认值、最小值和最大值。列表视图的默认列宽不应导致文本被截断，尤其是在列表视图中有可用空间时。
- 布局平衡。 窗口的布局应该大致平衡。如果布局感觉左侧重，可以考虑使控件变得更宽，并将一些控件向右侧移动。
- 布局调整大小。 当一个窗口被调整尺寸且其中包含的数据是被截断的，请确保较大的窗口尺寸显示更多数据。当数据被截断时，用户希望调整窗口大小以显示更多信息。
设置最小窗口大小，如果低于该尺寸，内容不再可用。对于可调整大小的控件，将最小可调整元素大小设置为其最小功能尺寸，例如列表视图中的最小功能列宽度。

文本

尽可能使用普通的会话术语。关注用户目标，而不是技术。如果您正在解释复杂的技术概念或操作，这将特别有效。想象一下自己正面对用户，并解释如何完成任务。
礼貌、支持和鼓励。用户永远不应感到屈尊、责备或恐吓。
删除多余的文字。在窗口标题、主要说明、补充说明、内容区域、命令链接和提交按钮中查找冗余文本。通常，在主要说明和交互控件中保留全文，并删除其他地方的任何冗余。
标题使用标题样式大写，所有其他 UI 元素使用句子样式大写。这样做更适合 Windows 语气。
- 例外：对于遗留应用程序，如有必要，您可以对命令按钮、菜单和列标题使用标题样式大写，以避免混合大写样式。
对于特性和技术名称，大小写要保守。通常，只有主要组件应该大写（使用标题样式大写）。
对于特性和技术名称，大小写保持一致。如果该名称在 UI 屏幕上多次出现，则应始终以相同的方式显示。同样，在程序中的所有 UI 屏幕上，名称应该一致地呈现。
不要将通用用户界面元素的名称大写。 例如工具栏、菜单、滚动条、按钮和图标。
- 例外：地址栏、链接栏、功能区。
不要将所有大写字母用作键盘键。相反，请遵循标准键盘使用的大写字母，如果键盘上未标记该键，请使用小写字母。
省略号表示不完整。 在 UI 文本中使用省略号如下：
- 命令。指示命令需要附加信息。不要在操作显示另一个窗口时使用省略号——仅当需要附加信息时。隐式动词是显示另一个窗口的命令不带省略号，例如高级、帮助、选项、属性或设置。
- 数据。指示文本被截断。
- 标签。指示任务正在进行中（例如，“正在搜索…”）。

提示：窗口或页面中的截断文本后带有未使用空间表示布局不佳或默认窗口尺寸太小。争取消除或减少在默认布局和窗口中的截断文本。更多信息，请参阅布局。

不要使用不是链接的蓝色文本，因为用户可能会认为它是一个链接。使用粗体或灰色阴影，以免使用彩色文本。
谨慎使用粗体来吸引用户必须阅读的文本。
使用主要指令简洁地解释用户应该在窗口或页面中做什么。好的主要指令传达了用户的目标，而不是仅仅专注于操作 UI。
以命令式指示或特定问题的形式表达主要指令。
不要在控制标签或主要指令的末尾放置句点。
在句子之间使用一个空格。不是两个。

控件

常规
- 标记每个控件或控件组。例外：
  - 文本框和下拉列表可以使用提示性语言标记。
  - 从属控件使用其关联控件的标签。数值调节控件始终是从属控件。
- 对于所有控件，默认选择最安全（以防止丢失数据或系统访问）、最稳妥的值。如果安全和保障不是因素，请选择最可能或最方便的值。
- 首选受约束的控件。尽可能使用受约束的控件（如列表和滑块），而不是像文本框这样的不受约束的控件，以减少对文本输入的需求。
- 重新考虑禁用的控件。禁用的控件可能很难使用，因为用户必须从字面上推断他们被禁用的原因。如禁用某个控件，当用户希望应用该控件时，他们应当可以轻松推断出禁用该控件的原因。当用户无法启用它或他们不希望它应用时删除控件，或者保持启用状态，但在使用不当时提供错误消息。
  - 提示：如果您不确定是否应该禁用控件或提供错误消息，请首先编写您可能提供的错误消息。如果错误消息包含了目标用户不太可能快速推断的有用信息，请启用控件并提供错误。否则，可以禁用控件。
命令按钮
- 更喜欢特定标签而不是通用标签。理想情况下，用户无需阅读任何其他内容即可理解标签。与静态文本相比，用户更可能阅读命令按钮中标签文字。
  - 例外：如果“取消”的含义明确，请不要重命名“取消”按钮。用户不必阅读所有按钮来确定哪个按钮是取消操作。但是，如果不清楚要取消的操作（例如有多个未决操作时），请重命名“取消”。
- 提出问题时，请使用与问题匹配的标签。例如，对“是”或“否”问题提供“是”和“否”的回答。
- 不是属性表或控制面板项的对话框中不要使用“应用”按钮。“应用”按钮意味着应用挂起的更改，但让窗口保持打开状态。这样做允许用户在关闭窗口之前评估更改。但是，只有属性表和控制面板项有此需要。
- 如果取消将环境返回到以前的状态（不留下任何副作用），则将按钮标记为“取消”；否则，标记按钮为“关闭”（如果操作完成）或“停止”（如果操作正在进行）以表示它保持当前更改的状态不变。
命令链接
- 始终以一组两个或更多的形式显示命令链接。从逻辑上讲，没有理由问一个只有一个答案的问题。
- 提供一个明确的“取消”按钮。不要为此目的使用命令链接。很多时候，用户意识到他们不想执行任务。使用命令链接取消需要用户仔细阅读所有命令链接，以确定要取消的方法。具有明确的“取消”按钮允许用户有效地取消任务。
- 如果提供明确的“取消”按钮会留下单个命令链接，请同时提供要取消的命令链接和“取消”按钮。这样做可以清楚地表明用户有选择权。用它与第一个响应的不同之处来表达这个命令链接，而不仅仅是“取消”或一些变化。
“不再显示此项目”复选框
- 只有在没有更好的替代方法时，考虑使用“不再显示此项目”选项以允许用户取消重复出现的对话框。如果用户真的需要，最好总是显示对话框；如果用户不需要，就直接消除它。
- 将“项目”替换为特定项目名称。例如，“不再显示此提醒”。通常在引用对话框时，请使用“不再显示此消息”。
- 通过在选项下添加以下句子，明确指示何时将用户输入用于未来的默认值：您的选择将在未来默认使用。
- 默认情况下不要选择该选项。如果对话框真的应该只显示一次，请不要询问。不要将此选项用作惹恼用户的借口 – 确保默认行为不会令人讨厌。
- 如果用户选择该选项并单击“取消”，则该选项生效。此设置是一个元选项，因此它不遵循不留下任何副作用的标准“取消”行为。请注意，如果用户以后不想看到该对话框，他们很可能也想取消它。
链接
- 不要分配 访问键。使用 Tab 键访问链接。
- 不要在链接文本中添加“单击”或“单击此处”。这是没有必要的，因为链接意味着点击。
工具提示
- 使用工具提示为未标记的控件提供标签。您不必仅仅为了一致性而提供带标签的控件工具提示。
- 如果这样做有帮助，工具提示还可以为标记的工具栏按钮提供更多详细信息。不要只是重复或冗长地重述标签中已有的内容。
- 避免覆盖用户将要查看或与之交互的对象。始终将提示放在对象的一侧，即使这可能使指针和提示分开。只要对象与其提示之间的关系是明确的，这些距离就不是问题。
  - 例外：列表和树中使用的全名工具提示。
- 对于项目集合，避免覆盖用户可能查看或与之交互的下一个对象。对于水平排列的物品，避免将提示放在右侧；对于垂直排列的物品，请避免在下方放置提示。
渐进式披露
- 使用“更多/更少”渐进式显示按钮来隐藏用户通常不需要的、高级或很少使用的选项、命令和详细信息。不要隐藏常用项目，因为用户可能找不到它们。但要确保隐藏的东西有价值。
- 如果表面总是显示一些选项、命令或细节，请使用以下标签对：
  - 更多/更少选项。用于选项或选项、命令和详细信息的混合。
  - 更多/更少命令。仅用于命令。
  - 更多/更少细节。仅用于信息。
  - 更多/更少 <对象名称>。用于其他对象类型，例如文件夹。
- 除此以外：
  - 显示/隐藏选项。用于选项或选项、命令和详细信息的混合。
  - 显示/隐藏命令。仅用于命令。
  - 显示/隐藏细节。仅用于信息。
  - 显示/隐藏 <对象名称>。用于其他对象类型，例如文件夹。
进度条
- 对需要有限时间的操作使用确定的进度条，即使该时间无法准确预测。不确定的进度条显示正在取得进展，但不提供其他信息。不要仅根据可能缺乏准确性来选择不确定的进度条。
- 如果您可以准确地进行估计，请提供剩余时间估计值。准确的剩余时间估算很有用，但偏离目标或明显反弹的估算无济于事。您可能需要进行一些处理，然后才能给出准确的估计值。如果是这样，请不要在此初始期间显示可能不准确的估计值。
- 不要重新开始进度。进度条如果重新启动（可能是因为操作中的一个步骤完成）就会失去其价值，因为用户无法知道操作何时会完成。相反，让操作中的所有步骤共享一部分进度，并让进度条完成一次。
- 提供有用的进度详细信息。提供额外的进度信息，但前提是用户可以用它做一些事情。确保文本显示的时间足够长，以便用户能够阅读。
- 不要将进度条与忙指针结合使用。使用其中之一，但不要同时使用两者。
提示（比如文本框中占位字符）
- 当屏幕空间非常宝贵以至于不希望使用标签或指令时，请使用提示，例如在工具栏上。
- 提示主要用于以紧凑的方式识别文本框或组合框的用途。它不能是用户在使用控件时需要查看的重要信息。
- 提示文本不得与真实文本混淆。去做这个：
  - 以斜体灰色绘制提示文本，以罗马黑色绘制实际输入文本。
  - 提示文本不应是可编辑的，并且在用户单击或 Tab 进入文本框后应消失。
    - 例外：如果文本框具有默认输入焦点，则会显示提示，并在用户开始输入后消失。
- 不要使用结束标点或省略号。
通知
- 对与当前用户活动无关的事件使用通知，不需要立即用户操作，用户可以随意忽略。
- 不要滥用通知：
  - 仅在需要时使用通知。当您显示通知时，您可能会打扰用户甚至惹恼他们。确保中断是合理的。
  - 对不需要用户立即操作的非关键事件或情况使用通知。对于需要立即用户操作的关键事件或情况，请使用替代 UI 元素（例如模态对话框）。
  - 不要将通知用于功能广告！

键盘

将初始输入焦点分配给用户最有可能首先与之交互的控件，**这通常是第一个交互控件。如果第一个交互式控件不是一个好的选择，请考虑更改窗口的布局。
为所有交互式控件分配制表位，包括只读编辑框。例外：
- 一组作为单个控件的相关控件，例如单选按钮。此类组具有单个制表位。
- 正确包含组，以便箭头键在组内向前和向后循环并留在组内。
Tab 键顺序应该从左到右，从上到下。通常，选项卡顺序应遵循阅读顺序。考虑通过将常用控件放在 Tab 键顺序中的较早位置来为常用控件设置例外。Tab 应该在两个方向上循环遍历所有制表位而不停止。在一个组内，Tab 键顺序应该是按顺序排列的，无一例外。
在制表位内，箭头键顺序应该从左到右，从上到下，无一例外。箭头键应该在两个方向上循环浏览所有项目而不会停止。
按以下顺序显示提交按钮：
- OK/[Do it]/Yes — 好/做/是
- [Don’t do it]/No — 不要这样做/不
- Cancel — 取消
- Apply (if present) — 申请（如果有）

其中 [Do it] 和 [Don’t do it] 是对主要指令的具体回应。

不要将访问键与快捷键混淆。虽然访问键和快捷键都提供对 UI 的键盘访问，但它们具有不同的目的和指导原则。
尽可能为所有交互式控件或其标签分配唯一的访问键。只读文本框是交互式控件（因为用户可以滚动它们并复制文本），因此它们可以从访问键中受益。不要将访问键分配给：
- 确定、取消和关闭按钮。Enter 和 Esc 用于它们的访问键。但是，始终将访问键分配给一个表示“确定”或“取消”含义、但具有不同标签名称的控件。
为最常用的命令分配快捷键。不常用的程序和功能不需要快捷键，因为用户可以使用访问键。
不要让快捷键成为执行任务的唯一方法。用户还应该能够使用带有 Tab、箭头和访问键的鼠标或键盘。
不要给众所周知的快捷键赋予不同的含义。因为它们被记住，众所周知的快捷方式的不一致含义令人沮丧且容易出错。
不要尝试分配系统范围的程序快捷键。只有当您的程序具有输入焦点时，您程序的快捷键才有效。

鼠标

永远不要要求用户单击对象来确定它是否可单击。用户必须能够仅通过目视检查来确定可点击性。
- 主 UI（例如提交按钮）必须具有静态点击功能。用户不必悬停即可发现主 UI。
- 辅助 UI（例如辅助命令或渐进式显示控件）可以在悬停时显示它们的点击可供性。
- 文本链接应该静态地建议链接文本，然后在悬停时显示它们可点击（下划线或其他演示更改，使用手形指针）。
- 图形链接仅在悬停时显示手形指针。
仅将手形（或“链接选择”）指针用于文本和图形链接。否则，用户将不得不单击对象来确定它们是否是链接。

对话框

模态对话框需要交互，因此将它们用于用户在继续执行任务之前必须响应的事情。确保中断是合理的，例如对于需要完成的关键或不频繁的一次性任务。否则，请考虑使用非模态替代。
非模态对话框不需要交互，因此当用户需要在对话框和所有者窗口之间切换时使用它们。它们最适合用于频繁、重复或持续的任务。但是，功能区、工具栏和调色板窗口（palette windows）通常是更好的替代选择。

属性表

确保这些属性是必需的。不要仅仅为了逃避做出艰难的设计决定，而让不必要的属性弄乱您的属性页。
根据用户目标而不是技术来呈现属性。属性配置了特定技术，并不意味着您必须根据该技术来呈现该属性。
- 如果您必须提供技术方面的设置（可能是因为您的用户认识该技术的名称），请添加一段对用户利益的简要说明。
使用特定的、有意义的标签标签。避免可应用于任何选项卡的通用选项卡标签，例如“常规”、“高级”或“设置”。
避免“常规”页面。您不需要拥有“常规”页面。仅在以下情况下使用“常规”页面：
- 这些属性适用于多个任务并且对大多数用户有意义。不要在“常规”页面上放置特殊或高级属性，但您可以通过“常规”页面上的命令按钮访问它们。
- 这些属性不适合更具体的类别。如果适用更具体的类别，请更改该页面名称。
避免“高级”页面。仅在以下情况下使用“高级”页面：
- 这些属性适用于不常见的任务，主要对高级用户有意义。
- 这些属性不适合更具体的类别。如果适用更具体的类别，请更改该页面名称。
如果属性窗口只有一个选项卡且不可扩展，则不要使用选项卡。改用带有“确定”、“取消”和可选“应用”按钮的常规对话框。但是，可扩展的属性窗口（可能由第三方扩展）必须使用选项卡。

向导

首先考虑轻量级替代方案，例如对话框、任务窗格或单个页面。向导是一个繁重的 UI，最适合用于多步骤、不经常执行的任务。您不必使用向导——您可以在任何 UI 中提供有用的信息和帮助。
仅在无提交前进到下一页时才使用“下一页”。如果单击“返回”或“取消”无法撤消其效果时，将前进到下一页视为提交。
仅使用“返回”来纠正错误。除了纠正错误之外，用户不应该单击“返回”以在任务中取得进展。
当用户提交任务时，使用提交按钮作为对主要指令（例如，打印、连接或开始）的特定响应。不要使用像“下一页”（这并不意味着提交）或 “完成”（这不是特定的）这样的通用标签来提交任务。这些提交按钮上的标签本身应该是有意义的。始终以动词开头提交按钮标签。例外：
- 当特定响应仍然是通用的（例如保存、选择、选择或获取）时，请使用完成。
- 使用完成更改特定设置或设置集合。
仅将命令链接用于选择，而非提交。特定的提交按钮比向导中的命令链接更好地指示提交。
使用命令链接时，隐藏下一步按钮，但保留取消按钮。
对后续和完成页面使用关闭。不要使用取消，因为关闭窗口不会放弃此时所做的任何更改或操作。不要使用 “Done”，因为它不是祈使动词。
不要在向导名称中使用“向导”。例如，使用“连接到网络”而不是“网络设置向导”。但是，将向导称为向导是可以接受的。例如：“如果您是第一次设置网络，您可以使用连接到网络向导获得帮助。”
通过导航保留用户选择。例如，如果用户进行更改，单击“上一步”，然后单击“下一步”，则应保留这些更改。用户不希望必须重新输入更改，除非他们明确选择清除它们。

向导页面

专注于高效决策。减少页面数量以专注于要点。整合相关页面，将可选页面从主流程中剔除。让用户通过您的向导完全单击“下一步”一开始似乎是一种很好的体验，但如果用户从不需要更改默认设置，则这些页面可能是不必要的。
不要使用欢迎页面——尽可能让第一页发挥作用。仅在以下情况下使用可选的入门页面：
- 该向导具有成功完成向导所需的先决条件。
- 用户可能无法根据向导的第一个“选择”页面理解其用途，并且没有进一步解释的余地。
- 入门页面的主要说明“开始之前：”应该做的事。
在要求用户做出选择的页面上，针对最可能的情况进行优化。这些类型的页面应该提供实际的选择，而不仅仅是说明。
- 如果您不使用“入门”页面，请在第一页选项的顶部解释向导的用途。
使用“提交”页面明确用户何时提交任务。通常提交页面是选择的最后一页，下一步按钮被重新标记以指示正在提交的任务。
- 在摘要页面上，不要使用仅总结用户之前选择的，除非任务有风险（涉及安全，或者时间或金钱的损失），或者用户很可能不理解他们的选择并需要查看它们。
不要使用祝贺页面，页面里除了结束向导以外再没有其他任何作用。如果向导结果对用户来说很明显，只需在最终提交按钮上关闭向导即可。
- 当存在用户可能会执行的相关任务作为后续操作时，请使用后续页面。避免熟悉的后续任务，例如“发送电子邮件”。
- 仅当结果不可见并且没有更好的方法来为任务完成提供反馈时才使用完成页面。
- 具有进度页面的向导必须使用完成页面或后续页面来指示任务完成。对于长时间运行的任务，请关闭“提交”页面上的向导并使用通知提供反馈。

错误信息

当用户不太可能因为消息而执行操作或改变他们的行为时，不要给出错误消息。如果没有用户可以采取的操作，或者问题不严重，则禁止显示错误消息。
只要有可能，提出一个解决方案，以便用户可以解决问题。但是，请确保建议的解决方案可能会解决问题。不要暗示用户可能，但实际不可能的解决方案来浪费用户的时间。
请明确点。避免含糊不清的措辞，例如语法错误和非法操作。提供所涉及对象的特定名称、位置和值。
不要使用指责用户或暗示用户错误的措辞。避免在措辞中使用“你”和“你的”。虽然通常首选主动语态，但当用户是主体，并且如果使用主动语态可能会感到错误时，请使用被动语态。
不要对错误消息使用 OK。用户不会将错误视为正常。如果错误消息没有直接操作，请改用关闭。
不要使用以下词语：
- 错误，失败（改用“问题”替代） –Error, failure (use problem instead)
- 失败（使用“无法”代替）–Failed to (use unable to instead)
- 非法、无效、错误（改用“不正确”或“无效”）–Illegal, invalid, bad (use incorrect or not valid instead)
- 禁止、强制关闭、终止（使用“停止”代替）–Abort, kill, terminate (use stop instead)
- 灾难性的，致命的（用“严重”代替）–Catastrophic, fatal (use serious instead)

这些术语是不必要的，与 Windows 的鼓励语气相反。相反，错误图标，如果使用得当，足以表明存在问题。

不要在错误信息中添加声音效果。这样做很刺耳，也没有必要。

警告信息

警告描述了将来可能会导致问题的情况。警告不是错误或问题，因此不要将常规问题表述为警告。
当用户不太可能因为消息而执行操作或改变他们的行为时，不要给出警告消息。如果用户无法执行任何操作，或者情况不重要，则禁止显示警告消息。

确认

不要使用不必要的确认。仅在以下情况下使用确认：
- 有明确的理由不继续，有时用户也有合理的机会不继续。
- 该操作具有重大后果或无法轻易撤消。
- 该操作具有用户可能不知道的后果。
- 继续操作需要用户做出没有合适默认值的选择。
- 鉴于当前上下文，用户很可能错误地执行了某个操作。
短语确认为“是”或“否”问题，并提供“是”或“否”答案。与其他类型的对话框不同，确认旨在防止用户快速做出决定。如果用户不考虑他们的回应，确认就没有价值。

图标

所有图标都应遵守 Aero 风格的图标指南。替换所有 Windows XP 样式的图标。
根据消息类型而不是潜在问题的严重性选择标准图标：
- 错误。发生的错误或问题。
- 警告。将来可能会导致问题的条件。
- 信息。有用的信息。

如果一个问题结合了不同的消息类型，请关注用户需要采取行动的最重要方面。

图标必须始终与主要说明或其他相应文本相匹配。
非关键用户输入问题不需要错误图标。然而，在位编辑的错误需要图标，否则这种上下文反馈很容易被忽视。
不要使用警告图标来“软化”非关键错误。错误不是警告；改为应用错误图标指南。
对于问题对话框，仅对具有重大后果的问题使用警告图标。不要在常规问题中使用警告图标。

帮助

链接到特定的相关帮助主题。
- 不要链接到帮助主页、目录、搜索结果列表或仅链接到其他页面的页面。
- 避免链接到结构化为大量常见问题列表的页面，因为这会迫使用户搜索与他们单击的链接匹配的页面。
- 不要链接到与手头任务不相关且无帮助的特定帮助主题。
- 永远不要链接到空页面。
为了一致性，不要在每个窗口或页面上放置帮助链接。在一处提供帮助链接并不意味着您必须在任何地方都提供它们。
在可能的情况下，帮助链接文本的措辞应该以主要问题的帮助内容为主。不要使用“了解更多信息”或“获得有关此方面的帮助”的措辞。
将整个帮助链接用于链接文本，而不仅仅是关键字。
使用完整的句子。
不要使用结束标点或省略号，问号除外。
如果帮助内容是线上的，请使用链接样式。这样做有助于使链接的结果可预测。

原文链接