002-Windows桌面应用程序设计指南(设计基础篇-桌面应用程序UX自查清单)

下面是一些用户体验指南中的重要准则集合。您可以将此作为自查表,以确保程序用户界面在相关要点上设计无误。

窗口

  • 支持最小Windows有效分辨率800x600像素。 对于必须在安全模式下工作的关键用户界面(ui) ,支持640x480像素的有效分辨率。对于有任务栏的窗口,确保在此分辨率中留出48个垂直相对像素供其占位显示。
  • 在有效分辨率为1024x768像素的基础上,优化可调整大小的窗口布局。在更低的屏幕分辨率下,自动调整优化不同大小窗口的效果。
  • 确保在每英寸96dpi(800x600像素)、120dpi (1024x768像素)和144dpi (1200x900像素)模式下测试窗口。 检查布局问题,例如控件、文本和窗口是否有超出,以及图标和位图是否有拉伸变形。
  • 对于触屏和有移动应用场景的程序,在120dpi下进行优化。 高分辨率屏幕目前在触摸屏和移动电脑上非常流行。
  • 如果一个窗口是一个从属窗口,初次出现应该"居中"于其主窗口上层。 永远不要在下层弹出。 对于后续的弹出显示,如果更方便的话,可以考虑将其显示在上一次操作时相对于所有者窗口的位置。
  • 如果一个窗口和上下文相关,那么总是在启动它的对象元素附近显示它。然而,让它展现在稍稍不同的位置(最好是向下偏移和向右偏移) ,这样启动对象就不会被窗口覆盖。

布局

  • 在窗口中设计用以调整主要内容显示的控件和操作面板。避免出现内容删节及其相关信息省略的情况。 用户永远不应该通过与整个窗口交互来查看其主要内容ー为异常大的内容保留大小调整控件和滚动条。具体检查以下项目:
  1. 控制大小的控件。 大小控件的典型内容,在需要的情况下,可以将控件设计得更宽、更高,或多行展示。有了控制内容展示大小的控件,就可以减少或杜绝在窗口仍有多余展示空间的情况下,仍需要滚动条控制才能阅读更多内容的情况。 此外,在有大量可用空间的窗口中,不应该出现被截断的标签或被截断的文本。 但是,为了使文本更易于阅读,可以考虑将行宽限制在65个字符内。

  2. 栏目宽度。 确保列表栏视图的默认大小、最小和最大尺寸合适。 特别在列表视图中还有可用的空间时,设计不会导致文本被截断的列表视图默认列宽。

  3. 布局平衡。 窗口的布局应该给人感觉大致平衡。 如果感觉布局左边重,可以考虑将控件加宽,并将一些控件向右移动。

  4. 布局大小调整。当窗口可调整大小并且数据被截断时,请确保较大的窗口能展示更多的数据。当数据被截断时,用户希望通过调整窗口大小来获取更多信息。

  • 如果在一定尺寸下内容将无法有效展示,记得设置最小窗口尺寸。 对于可调整大小的控件,将最小尺寸设置为其最小正常运作的尺寸,例如列表视图中的最小列宽度。

文本

  • 尽可能使用日常、通用的术语。 关注点应在于用户目标,而不是技术。 如果你正在解释一个复杂的技术概念或行动,这尤其有效。 想象一下你就站在用户面前,向他解释如何完成这个任务。

  • 传达礼貌、支持和鼓励的态度。 用户永远不应该感到屈尊俯就、被责备或者担惊受怕。

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

  • 对标题使用标题样式的大写规则,所有其他 UI 元素上的文本则使用句子的大写规则。 这样做更贴合 Windows 的风格。
    例外情况: 对于传统应用程序,如果需要,可以对命令按钮、菜单和列标题使用标题样式的大小写,以避免混合大小写样式。

  • 对于功能和技术名称,在大写规则上要保守。 通常,只有主要组件应该大写(使用标题样式大写规则)。

  • 对于功能和技术名称,大写规则要保持一致。 如果名称在同一界面中出现多次,则应保持显示一致。 同样,在同一程序中的所有界面中,名称应该始终一致。

  • 不要将通用用户界面元素(如工具栏、菜单、滚动条、按钮和图标)的名称大写。
    例外情况: 地址栏,链接栏,功能区。

  • 键盘按键不要全部使用大写字母。 遵循标准键盘使用的大写字母规则,或者如果键盘上没有标记,则按小写字母。

  • 省略号意味着信息不完整。 使用省略号UI文本中有以下情况:
    1.命令。省略号表明执行命令需要额外的信息。某个操作会弹出新窗口时,UI文本不一定要使用省略号ー只有在需要展示额外信息时才使用。 当一个命令隐含有打开新窗口的动作倾向时,UI文本不应加省略号,如"高级"、"帮助"、"选项"、"属性"或"设置"。
    2.数据。 暗示文本被截断,显示不完整。
    3.标签。 暗示任务正在进行(例如,"搜索中...")。

  • 提示: 如果窗口中仍有未使用的空间,而页面中却有被截断的文本,说明布局设计得不合理或默认窗口尺寸过小。 尽量设计合适的布局和默认窗口大小,以消除或减少截断文本的情况。有关更多信息,请参见布局相关章节说明。

  • 如果不是链接,不要设置蓝色文本,以免用户产生误解。 使用字体加粗或灰度字体来代替彩色文字。

  • 节制地对用户必读内容使用加粗文字以吸引注意力。

  • 使用主指令简明地向用户解释清楚,在给定窗口或页面中应该做什么。 好的主说明能够与用户沟通以完成用户的目的,而不仅仅是指导用户操作界面。

  • 以祈使句或特定问句的形式表达主要指令。

  • 不要在控制标签或主说明的末尾放置句号。

  • 在句子之间空一格。

控件

  • 通用
  1. 为每个控件或控件组设置文本标签。 以下情况例外:
    1.文本框和下拉列表可以使用prompt进行说明。
    2.下级控件使用其主控件的标签。可旋转控件都是从属控件。

  2. 对于所有控件,选择最安全的(以防止数据丢失或系统访问) ,最保险的默认值。 如果安全性和保险性不是因素,就设置最可能或最方便的值。

  3. 尽量选择操作有限的控件。 尽可能这种约束性的控件,如列表和滑块,而不是无约束的控件,如文本框,以减少内容的输入。

  4. 慎用禁用控件。 禁用控件可能很难使用,因为用户得明白禁用的原因。 当用户认为某个控件可点击、并且如果该控件不能使用时他们可以很容易地明白发生了什么,这种情况下可以使用禁用控件。当用户不可能启用、或他们不想让控件可用、或他们用不到该控件,这时应该直接删掉这个控件,或者在其没有被正确使用的时候显示错误信息提示。

(提示: 如果您不确定是该禁用控件还是应该显示错误提示,那么可以从列出可能提供的错误信息内容开始。 如果错误消息包含有用信息,而这些信息目标用户不太可能仅凭自己的理解迅速得出,那么请保持控件处于启用状态并提供错误提示。 否则,禁用该控件。)

  • 命令按钮
  1. 直接使用具体标签文字,不要使用附属文本进行说明。 理想情况下,用户不必通过阅读其他内容来理解标签。 用户更愿意直接阅读命令按钮标签而不是静态文本。(特例: 如果某操作的取消含义明确,那就直接叫"取消"按钮。 用户不必阅读所有的按钮来思考哪个按钮能取消操作。 但是,如果不清楚正在取消哪些操作,比如有几个挂起的操作时,则为“取消”按钮重新命名。)

  2. 问问题时,使用与问题相匹配的标签文字。 例如,对一个是或否的问题提供是或否的选择按钮。

  3. 不要在非属性列表或控制面板项的对话框中使用"应用"按钮。 "应用"按钮意味着应用挂起中的更改内容,但保持窗口打开状态。 这样做允许用户在关闭窗口之前评估更改。但是,只有属性表和控制面板项具有此需要。

  4. 如果要取消使环境操作,以恢复到以前的状态(不产生任何其他影响) ,则标签名称为"取消"; 当操纵已完成时,标记按钮为"关闭";如果操作正在进行中,使用"停止"以表明它保持当前更改的状态不变。

  • 命令链接
一个典型的命令链接
  1. 一组命令链接中一定有两个或者更多命令链接。 从逻辑上讲,没有理由问一个只有唯一答案的问题。

  2. 设计一个明确的取消按钮。不要为“取消“设计命令链接。 很多时候,用户会意识到他们不想把任务执行下去。若使用命令链接完成取消操作,需要用户仔细阅读所有命令链接,以确定取消是哪一个。 有一个明确的取消按钮允许用户高效地取消任务。

  3. 如果除了提供一个Cancel按钮以外,只留下了一个命令链接,那就同时提供一个要取消的命令链接和一个Cancel按钮。 这样能清楚地表明,用户有得选择。在表述上,该命令链接必须得重新组织,要和单纯的“取消”含义有所不同,而不仅仅是"取消"或其他变体。

  • “不再显示”选择框
  1. 在没有更好的方案时,考虑设置"不要再显示此内容"选项,以允许用户禁用重复出现的对话框。 如果用户真的需要,最好总是显示对话框,如果不需要,就简单地删除它。

  2. 用特定语言表述此类选项。 例如“不再显示该提醒” 。在一般情况下引用对话框时,使用"不再显示此消息"。

  3. 清楚地告知用户输入值将用作未来的默认值。使用这样的语句告知: 您的选择将在未来默认使用。

  4. 不要默认勾选“不再显示”选项。 如果对话框确实应该只显示一次,请不要询问用户(给用户“不再选择”的选项),就直接只显示一次。 “不再显示”选项的存在是为了方便用户而不是为用户造成困扰ーー确保默认行为不会惹恼用户。

  5. 如果用户勾选了该选项又单击了对话框的"取消",选项将仍会生效。这个设置是一个元选项,所以它不会遵循标准的取消行为(标准的取消行为会让对话框中的所有指令无效)。这样设计的内在逻辑是,如果用户将来不想再看到这个对话框,他们很可能也会点去击取消按钮。

  • 链接
  1. 不要为链接分配存取键。 使用 Tab 键访问链接。
  2. 不要在链接文字中加入「点一下」或「点这里」。这没必要,因为链接就意味着需要点击。
  • 工具提示
  1. 工具提示是为未标记的控件提供标签文字说明。 你不必仅仅为了一致性而给本身有标签的控件设置工具提示。

  2. 在必要情况下,工具提示可以为带标签的工具栏按钮提供更多细节说明。但不要只是重复或者冗长地重复标签上已经写好的内容。

  3. 要避免工具提示遮挡用户将要查看或交互的对象。 始终将提示放在对象的另一侧,即使这会使提示和鼠标指针不同侧显示。 只要物体和它的提示之间的关系是清楚的,一些距离上的分割也没关系。(特例: 列表和树中使用的全名提示。)

  4. 对于多个项的集合,避免遮盖用户可能查看或与之交互的下一个对象。 对于水平排列的对象,避免将提示放在右边; 对于垂直排列的物品,避免将提示放在下方。

  • 渐进展示
  1. 使用“展开/收起”渐进按钮组,来隐藏高级或用户很少使用的选项、命令和细节。 不要隐藏常用的项目,防止用户可能找不到它们。但也得确保隐藏起来的选项是有必要存在的。

  2. 如果界面需要显示一些选项、命令或细节,请使用以下标签文字对:
    (1)更多 / 收起选项。 用于选项或选项、命令和详细信息的混合。
    (2)更多 / 收起命令。 仅用于命令。
    (3)更多 / 收起细节。 仅用于信息展示。
    (4)更多 / 收起。 用于其他对象类型,如文件夹。

  3. 或者是:
    (1)显示 / 隐藏选项。 用于选项或选项、命令和详细信息的混合。
    (2)显示 / 隐藏命令。 仅用于命令。
    (3)显示 / 隐藏细节。 仅用于信息展示。
    (4)显示 / 隐藏。 用于其他对象类型,如文件夹。

  • 进度条
  1. 对于需要有限时间的操作,使用确定的进度条,即使该时间量无法准确预测。不确定的进度条显示正在取得进展,但不提供其他信息。 不要仅仅因为可能缺乏准确性而选择不确定的进度条。
  2. 如果可以做到准确的话,提供一个时间剩余的估计。 精确的剩余时间估计很好,但是不准确估计或者有明显时间反弹的估计毫无作用。 您可能需要执行一些程序处理,然后才能给出准确的估计。 如果是这样的话,不要在一开始就匆忙显示可能不准确的估计。
  3. 不要重启进程。 如果进度条重新启动(可能是因为操作中的一个步骤已经完成) ,它将失去其价值,因为用户无法知道操作何时将完成。 相反,让操作中的所有步骤共享一部分进度,并让进度条报告一次部分完成状态。
  4. 提供有用的进度细节。 提供额外的进度信息,但前提这些信息对用户有用。 确保文本显示的时间足够长,以便用户能够读完。
  5. **不要将进度条和忙指针(转圈圈指针)组合使用。 ** 可以使用前者或者后者,但不要同时使用两个。
  • 提示
  1. 当屏幕空间非常宝贵,使用标签文字或使用说明都不合适的时候,使用提示符。比如在工具栏上。
  2. 提示主要用于以紧凑的方式说明文本框或组合框的用途。它不该是用户在使用控件时需要查看的关键信息。
  3. 提示文本不能与实际文本混淆。要做到这一点:
    (1)提示文本使用灰色斜体,实际输入文本使用黑色罗马体。
    (2)提示文本不可编辑,一旦用户点击或开始在文本框内输入,提示文本应该消失。
    (特例: 如果文本框具有默认输入焦点,则会默认显示提示,一旦用户开始输入,提示就会消失。)
  4. 不要在结尾使用标点符号或省略号。
  • 通知
  1. 对与当前用户活动无关、不需要用户立即操作且用户可以自忽略的事件使用通知。
  2. 不要滥用通知:
    (1)只在有必要的时候使用通知。 当您显示一个通知时,您可能会打断用户,甚至会惹恼他们。 要确保这种中断是合理的。
    (2)对不需要用户立即操作的非关键事件或情况,使用通知。 对于需要立即执行用户操作的关键事件或情况,请使用其他的UI元素(例如模态对话框)。
    (3)不要使用通知作为功能广告!

键盘

  • 将初始输入焦点分配给用户最可能首先与之交互的控件,这通常是第一个交互控件。 如果第一个交互式控件并不是这种情况,考虑更改窗口的布局设计。

  • 为所有交互控件分配焦点切换,包括只读编辑框。特例:
    (1)组成单个控件(如多选按钮)的相关控件集。 这样的组只有一个焦点切换。
    (2)正确地设置组,以便箭头键在组中向前和向后循环,并保持在组中。

  • 制表顺序应该从左到右,从上到下。 一般来说,制表顺序应该遵循阅读顺序。对于常用的控件,可以考虑特别将它们放在前面的tab键制表顺序中。焦点切换应不停循环,在两个方向上通过所有制表位。在一个组中,制表符应该是按顺序的,没有例外。

  • 在制表位内,箭头键顺序应该从左到右,从上到下,没有例外。 箭头键应该在两个方向上循环遍历所有项目,不要停止。

  • 按以下顺序显示提交按钮:
    (1)好的 / [做] / 是的
    (2)[不要做] / 不
    (3)取消
    (4)应用(如有)
    其中[做](1)和[不要做](2)是对主要指示任务的具体回应。

  • 不要混淆存取键和快捷键。 虽然存取键和快捷键都提供对 UI 的键盘访问,但它们有不同的用途和指导原则。

  • 只要有可能,为所有交互控件或其标签分配唯一存取键。 只读文本框是交互式控件(因为用户可以滚动它们并复制文本) ,所以它们也可以使用存取键。 不要将存取键分配给:
    (1)确定,取消,和关闭按钮。 Enter键 和 Esc键 专用于它们的存取访问。 但是,始终为表示"确定"或"取消"但具有不同标签文字的控件分配存取键。

  • 为最常用的命令分配快捷键。 不经常使用的程序和功能不需要快捷键,因为用户可以使用存取键。

  • 不要使用快捷键作为执行任务的唯一方式。 用户还应该能够使用鼠标或带有 Tab、箭头和存取键的键盘。

  • 不要为众所周知的快捷键赋予不同的含义。 因为它们已经为人熟知,如果突然有了不同的含义,容易让用户受挫、产生误操作。

  • 不要尝试分配系统层面的程序快捷键。 只有当程序具有输入焦点时,程序的快捷键才会生效。

鼠标指针

  • 别让用户用鼠标去点击测试对象是否可点击。 必须保证用户通过视觉观察就能明确对象的可点击性。
    1.主UI控件 (如提交按钮)必须具有静态的可点击示能。 用户不需要通过鼠标悬停来探索这一点。
    2.辅助UI控件(如辅助命令或渐进公开控件)可以在鼠标悬停时显示点击示能。
    3.文本链接应该静态地展示链接文本内容,然后在鼠标悬停时显示它们的点击示(手型指针附带下划线或其他表现形式的变化)。
    4.图形链接只在鼠标悬停时显示手型指针。
  • 只对带有链接的文本和图形使用手型指针(或"链接选择")。 否则,用户将不得不点击对象来确定它们是否是链接。

对话框

  • 模态对话框需要交互动作,所以在继续执行任务之前,用它们展示用户必须响应的事情。 确保中断是合理的,例如对于重要的或不经常的、需要完成的一次性任务。 否则,考虑非模态的其他展示形式。

  • 非模态对话框不需要交互,因此当用户需要在对话框和其主窗口之间切换时使用它们。 它们最适用于频繁、重复或正在进行的任务。但是,彩条、工具栏和调色板窗口通常是更好的选择。

属性表单

  • 确保这些属性有设置的必要。 不要为了避免设计取舍而在属性页面中放置不必要的属性。

  • 根据用户目标而不是技术水平来呈现属性。 一个属性可以配置一个特定的技术,并不意味着您必须通过该技术来展示该属性。

-如果您必须根据技术(可能是因为您的用户认识该技术的名称)显示设置,请包含用户受益的简要描述。

3.使用特定的,有意义的标签。 避免可以应用于任何选项卡(如常规、高级或设置)的通用选项卡标签。

4.避免通用页面。 通用页面并不是必备的。 只有在下列情况下才使用通用页面:
(1)这些属性适用于多个任务,对大多数用户都有意义。 不要在通用页面上放置专用或高级属性,但可以通过通用页面上的命令按钮来访问它们。
(2)这些属性不适合更具体的类别。 如果有更具体的类别,使用那个类别来命名页面。

5.避免高级页面。 只有在以下情况下才使用高级页面:
(1)这些属性适用于不常见的任务,主要对高级用户有意义。
(2)这些属性不适合更具体的类别。 如果有更具体的类别,使用那个类别来命名页面。

  • 如果属性窗口只有一个选项卡且不可扩展,则不要使用选项卡。 使用一个常规的对话框,包括“确定”、“取消”和一个可选的“应用”按钮。 但可扩展的属性窗口(可由第三方扩展)必须使用选项卡。

向导程序

  • 首先考虑轻量级替代方案,如对话框、任务窗格或单页等。 向导是一套很重的用户界面,最好用于多步骤、不经常执行的任务。 可以用其他UI控件提供有用的信息和帮助,不是一定要使用向导。

  • 只有在没有任何信息变动提交的情况下进入下一页时才使用“下一步”。如果无法通过单击"上一步"或"取消"来撤销效果,则进入下一页将被视为确定的承诺。

  • 只在更正错误时使用“上一步”。 除了纠正错误之外,用户不应该必须单击 “上一步”才能将任务进行下去-。

  • 当用户提交任务时,使用一个提交按钮作为对主指令的特定响应(例如,“打印”、 “连接” 或 “开始”)。 不要使用类似“下一步”(这并不意味着承诺能保存改动和信息)或“完成”(这并不具体)这样的通用标签来提交任务。 这些提交按钮上的标签本身就应该有意义。 提交按钮标签要用动词描述。特例:
    (1)当响应仍然是通用动作的时候使用“完成”,例如 Save、 Select、 Choose 或 Get。
    (2)使用"完成"来更改特定设置或设置集合。

  • 使用命令链接只是为了选择,而不是承诺。 特定的提交按钮能比向导中的命令链接更好地表示承诺。

  • 使用命令链接时,去掉"下一步"按钮,但保留"取消"按钮。

  • 操作完成或者要进行后续操作时,使用“关闭”按钮。 不要使用"取消",因为关闭窗口不会放弃此时所做的任何更改或操作。也不要使用“完成”,因为它不是命令动词。

  • 不要在向导名称中使用"向导"。 例如,将"网络安装向导"改为"连接到网络" 但是,在提到它时,可以称其为向导。 例如:"如果您是第一次设置网络,可以通过使用连接到网络向导来获得帮助。"

  • 在浏览过程中保留用户的选择项。 例如,如果用户进行了更改,单击"上一步",然后单击"下一步",则应该保留这些更改项。 用户并不期望必须重新输入更改,除非他们明确选择清除更改。

向导页面

  • 致力于让用户进行有效率的决策。 减少页面数量,专注于要点。 合并相关页面,并从主要流程页面中删除可选页面。让用户完全只通过单击“下一步”完成向导,乍一看似乎是个不错的体验,但如果用户从不需要更改默认设置,那么这些向导页面可能就没有必要了。

  • 不要使用欢迎页面ーー尽可能使第一页具有功能性。只有在以下情况下才使用可选的入门页面:
    (1)入门页面具有成功完成向导流程所必需的先决条件。
    (2)仅根据向导的第一个选择页面,因为没有进一步解释的空间,用户可能无法理解向导的用途。
    (3)入门页面的主指令是"在开始之前:"。

  • 在用户被要求做出选择的页面上,针对用户最可能选择的项进行优化展示。 这种类型的页面应该提供实际的选择,而不仅仅是说明文字。
    如果您不使用入门页面,请在向导页面的第一页顶部解释向导的用途。

  • 当用户提交任务时,使用 "提交" 页面可以使其更明确。通常, "提交" 页面是向导页面的最后一页,“下一步”按钮被重新命名,以指示正在提交的任务。
    (1)不要使用仅仅汇总用户之前所有选择的摘要页面,除非任务有风险(涉及安全、时间或金钱损失) ,或者用户很可能不理解他们的选择,需要查看它们。

  • 不要使用"祝贺"页面,因为它会结束向导。 如果向导的结果很明确,用户只需点击最终提交按钮以关闭向导。
    (1)如果有用户可能会执行的相关任务,请使用后续页面。 避免提供太常规的后续任务,比如"发送电子邮件"
    (2)只有当结果不可见、且没有更好的方法为任务完成提供反馈时,才使用完成页面。
    (3)具有"进度"页的向导必须使用"完成"页或"后续"页来表明该阶段任务完成。对于长时间运行的任务,在确认页面上关闭向导并使用通知提供反馈。

报错信息

  • 当用户不太会因为错误信息提示而执行某个操作,或改变他们的行为时,不要报错。 如果没有用户可以采取的操作,或者问题不严重,则禁止显示错误消息。

  • 只要有可能,就应提出解决方案以便用户修复问题。 但是,要确保提出的解决方案能真正解决问题。 不要提出可行但不保证成功的解决方案,浪费用户的时间。

  • 措辞要具体。 避免使用含糊的文字,如语法错误和非法操作。给出所涉及对象的具体名称、位置和值。

  • 不要使用责怪用户或暗示用户错误的措辞。 避免使用“你”和“你的”。 虽然主动语态通常是首选,但当用户承受错误时,使用被动语态。如果使用主动语态,会让用户感觉自己对错误负有责任。

  • 不要对错误消息使用 OK按钮。 用户不认为错误是 OK 的。 如果错误消息没有直接操作,则改为使用“关闭”。

  • 不要使用下面的词语:
    (1)错误,失败(使用 问题 代替)
    (2)未能 (使用 无法执行 替代)
    (3)非法的,无效的,坏(使用 不正确 或 无效的 代替)
    (4)中止,杀死,终止(使用 停止 代替)
    (5)灾难性的,致命的(用 严重的 代替)
    以上这些术语并非必要,它们与 Windows 鼓舞人心的基调相反。当正确使用一个错误图标的时候,也足以表达出现的问题。

  • 不要将错误消息附加声音效果。 这样不和谐,也没必要。

警告信息

  • 警告用来描述将来可能导致问题的某种情况。 警告不是提示错误或问题,所以不要把例行问题提醒用警告表示。

  • 当用户不太可能执行某个操作或者因为消息而改变他们的行为时,不要发出警告消息。 如果没有用户可以采取的操作,或者如果情况并不紧急,则禁止显示警告消息。

确认消息

  • 不要使用不必要的确认消息提示。 仅在以下情况下使用确认对话框:
    (1)有一个明确的理由不继续进行,并且有一个合理的机会,有时用户不会继续。
    (2)该行为会产生重要后果或不能轻易被撤销。
    (3)该操作的结果可能是用户没有意识到的。
    (4)继续执行操作需要用户作出选择,这个选项没有默认值。
    (5)在当前上下文中,用户很可能执行了错误的操作。

  • 确认描述文字是一个是或否的问题,并提供是或否的答案。 与其他类型的对话框不同,确认对话框的设计目的是防止用户过快决策。 如果用户不仔细斯卡,一个确认没有价值。

图标

  • 所有图标都应该遵循 aero 风格的icon规范。 替换所有 Windows xp 样式的图标。

  • 基于"消息类型"选择图标,不要基于"问题的严重程度"选择图标:
    (1)错误。 已发生的错误或问题。
    (2)警告。 一种可能在未来出现的情况。
    (2)消息。 有用的信息。
    如果一个问题包含了不同的消息类型,那么请立足于用户需要采取行动的最重要方面来选择图标。

  • 图标必须始终与主指令或其他相应的文本匹配。

  • 报告不紧要的用户输入问题,不需要使用错误图标。 然而,对于输入错误,需要使用图标立即提示,因为否则这样的情况很容易被忽略。

  • 不要使用警告图标来"软化"非关键性错误。 错误不是警告,要应用错误图标准则。

  • 对于问题对话框,只对会产生严重后果的问题使用警告图标。 不要在日常问题中使用警告图标。

帮助

  • 帮助应该链接到特定的具体相关帮助主题。 不要链接到帮助主页、目录、搜索结果列表或者只链接到其他页面的页面。 避免链接到由大量常见问题组成的页面,因为这会迫使用户搜索与他们点击的链接相匹配的页面。 不要链接到与手头任务不相关和有帮助的特定帮助主题。 不要链接到空白页面。

  • 不要为了保持一致性,在每个窗口或页面上都放置帮助链接。 在一个地方提供帮助链接并不意味着你必须在所有地方都提供帮助。

  • 只要有可能,直接使用短语"帮助"作为主要问题链接文本。 不要使用"了解更多关于"或"得到这方面的帮助"这样的措辞。

  • 对整个链接文本设置帮助链接,而不仅仅是关键字。

  • 使用完整的句子。

  • 除了问号外,在结尾不要使用标点符号或省略号。

  • 如果帮助内容是在线的,请在链接文本中明确说明。这样做有助于使链接的结果可预测。

你可能感兴趣的:(002-Windows桌面应用程序设计指南(设计基础篇-桌面应用程序UX自查清单))