Microsoft交互设计规范.docx
《Microsoft交互设计规范.docx》由会员分享,可在线阅读,更多相关《Microsoft交互设计规范.docx(33页珍藏版)》请在冰豆网上搜索。
Microsoft交互设计规范
Documentserialnumber【NL89WT-NY98YT-NC8CB-NNUUT-NUT108】
Microsoft交互设计规范
Windows用户体验交互设计规范
此官方Windows用户体验交互设计规范(简称“UX规范”)的目标在于:
为所有基于Windows的应用程序划定高品质与一致性的基准。
回答关于用户体验的问题。
使你的工作更为轻松!
设计原则
%)
%)
控件
命令
o(34%)
o
o
o
o
o
o
o%)
o%)
o%)
o
o%)
o%)
文本
消息
o
o
o%)
o%)
o
o%)
o
o
o
o
o%)
o
o%)
o
o
交互
o(0%)
%)
%)
%)
窗口
%)
o%)
o%)
%)
o%)
o%)
%)
o%)
视觉
o
%)
NEW
o%)
o%)
o%)
o(0%)
%)
%)
体验
NEW(0%)
%)
%)
Windows环境
%)
%)
%)
%)
%)
%)
%)
其他
注释与引用
1.这里“官方”是原文的直接翻译,并不表示此中文译本经过微软官方任何形式的授权或认证。
布局Layout
[]
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
“布局”是指窗口或页面内各内容的尺寸、间距及位置。
有效的布局对于帮助用户快速找到他们想要的东西至关重要,并可产生具有吸引力的视觉外观。
有效的布局可以使有的设计用户立即就可以理解,而有的设计却使用户觉得困惑而不知所措。
注:
与相关的设计规范请参考各自相应的章节。
特定控件的推荐尺寸与间距则请参考相应的设计规范章节。
设计理念
视觉层次
当窗口或页面的外观能够表明各个元素之间的关系和重要性时,即可认为是具有清晰的视觉层次。
如果缺少视觉层次,用户就得靠他们自己来分辨它们之间的关系与重要性。
视觉层次是通过巧妙结合下列属性来实现的:
焦点。
该布局指出用户首先要看的位置。
流。
当目光顺畅自然地沿着清晰的路径在界面上移动时,看到的用户界面(UI)元素即是适合其使用的顺序排列的。
分组。
在逻辑上相关的UI元素之间具有清晰的视觉关系。
相关的项被组合在一起,不相关的项则被分开。
强调。
根据UI元素的相对重要程度进行强调。
对齐。
UI元素并列排放,使其便于扫视并依次呈现。
另外,有效的布局还具有下列特性:
设备无关性。
布局的呈现应当与字型、字体大小、分辨率(DPI)、显示器或显卡无关。
易于扫视。
用户可以只扫一眼就找到他们要的内容。
高效性。
那些尺寸较大的UI元素就应该这么大,而小的元素也能照样很好地使用。
尺寸可缩放性。
如果有用的话,窗口尺寸可以缩放,而无论界面的尺寸多大或者多小,其内容的布局都能够保持有效。
平衡。
内容匀称地分布在界面上。
视觉简洁性。
这是说布局不要比它所应有的更复杂。
用户不会觉得布局的外观复杂得让人头晕。
一致性。
类似的窗口或页面应当使用类似的布局,这样用户总能熟悉自己所处的环境。
虽然尺寸、间距和位置等概念非常简单,但在布局中正确混合使用这些属性却不是一件容易的事情。
在MicrosoftWindows中,布局是用对话框单位(DLU)这样的设备无关度量单位和相对像素来描述的。
关于布局度量单位、测量及换算的更多信息,请参考。
阅读设计模型
用户是通过内容的外观和组织形式来选择要阅读的内容的。
要创建有效的布局,你需要理解什么是用户经常阅读的以及为什么如此。
你可以在决定如何布局时参考阅读设计模型:
人们以从左向右、自上而下的顺序阅读的(在西方文化中)。
阅读分为两种模式:
沉浸式阅读(immersivereading)和浏览(scanning)。
沉浸式阅读的目的在于理解。
该图所示的是沉浸式阅读模式。
相反,浏览的目标则是定位。
一般的浏览路径看起来像是:
该图所示的是浏览模式。
如果文本排列在页面的左侧,则用户会先浏览左侧。
使用软件时,用户不会沉浸于UI本身,而是沉浸于他们的工作中。
因此,用户不会真正阅读界面上的文本——他们只会浏览。
他们只会在确信必要的时候才会仔细阅读大量文本。
用户通常会跳过页面左侧或右侧的导航部分。
用户能够认出它们在那里,但仅当他们想进行导航时才去看导航部分。
用户通常会跳过大块无格式的文本而完全不去阅读。
用户在浏览时通常会跳过大块文本及导航部分。
一切都等价时,用户首先从窗口的左上角看起,扫过整个页面,到右下角结束。
他们通常会忽略左下角。
一切都等价时,用户会以1、2、4、3的顺序阅读这些数字。
但在交互式UI中,并非所有的一切都是等价的,因此不同的UI元素所受到的关注程度也是不同的。
用户通常会首先看交互式控件——尤其是出现在窗口左上角和中间的控件——以及显着的文本。
用户关注于主要的交互式控件及显着的主标题说明,其他东西只有在他们需要的时候才会去看。
用户倾向于阅读交互式控件标签,尤其是那些看起来和完成手头任务相关的。
相反,用户仅在他们认为需要的时候才有可能去阅读静态文本。
看上去不同的内容容易吸引注意力。
粗体文本和大号文本能够从普通文本中突显出来。
彩色的或者是位于彩色背景上的用户界面元素较为突出。
有图标比没有图标更加突出。
除非确实需要,否则用户不会进行滚动。
如果没有理由来滚动的内容,用户则不会。
一旦用户决定要做什么,他们会立即停止扫视文本转而做事。
由于用户会在他们认为结束的时候停止扫视,因此他们可能会忽略所有在完成点之后出现的东西。
用户会在他们认为结束的时候停止扫视。
当然,常规模式也存在例外。
眼动仪实验指出,真实用户的行为很没有规律。
此模式的目的在于帮助你做出好的决定,而不是精确地描述用户的行为。
但既然你已经阅读了该列表,希望你也能辩别出许多你自己的阅读模式。
为扫视进行设计
用户并不阅读,他们只是扫视——因此你应当为视扫来设计用户界面。
不要假设用户会像书写那样从左至右、从上到下地阅读文本,事实上他们会看那些吸引他们注意的UI元素。
要为扫视进行设计:
假设用户先是会快速地扫一眼整个窗口,然后大致会按下面的顺序来阅读UI文本:
1.中间的交互控件
2.提交按钮
3.其他地方的交互控件
4.主标题说明
5.补充解释
6.带有警告图标的文本
7.窗口标题
8.正文区域的其他静态文本
9.脚注
将用于触发任务的UI元素放在左上角或上方中间。
将用于完成任务的UI元素放在右下角。
尽可能将重要的文本放在交互性控件上,而非使用静态文本。
避免将重要信息放在左下角或是需要滚动很多的控件或页面底端。
不要展示大段文本。
去除不必要的文本。
使用的呈现方式。
如果想吸引用户的注意,确保其理由充分。
尽可能使用这个模式而不要进行改变,但有时你可能需要强调或弱化某些UI元素。
要强调主要的UI元素:
将主UI元素放在上。
将任何触发任务的UI放在左上角或上方中间。
将提交按钮放在右下角。
将其他主要的UI放在中间。
使用控件来引起注意,比如命令按钮、命令链接和图标。
使用显着的文本,包括大字体和粗体。
将用户必须阅读的文本放在交互式控件上,或者附加图标,或者放在上。
使用位于浅色背景上的深色文本。
在元素周围留有足够的空白。
不需要任何操作就应当可以看到你要强调的元素,比如指向或悬停。
该示例显示了强调主要UI元素的多种方式。
要弱化次要的UI元素:
将次要的UI元素放在扫视路径之外。
将任何用户并不经常需要看到的内容放在窗口左下角或底部。
使用不会吸引注意力的控件,比如用任务链接代替命令按钮。
使用正常或灰色的文本。
使用位于深色背景上的浅色文本。
深灰或蓝色背景上的白色文本也可以。
在元素周围使用最小间距。
考虑使用方式来隐藏次要的UI元素。
该示例显示了多种弱化次要UI元素的方式。
有效利用屏幕空间
要有效利用屏幕空间,需要对多种因素进行平衡:
占用太多空间使窗口显得臃肿且浪费,以及基于来说甚至会难以使用。
错误:
在这个示例中,窗口相对于其内容来说太大了。
另一方面,使用太少空间会使窗口显得狭小、不适、有压迫感,而且难以使用——如果需要滚动或其他操作才能使用的话。
错误:
在这个示例中,窗口相对于其内容来说太小了。
虽然关键UI必须适合最小支持的屏幕分辨率,但不要认为有效利用屏幕空间就意味着窗口应该越小越好——事实上不是这样。
高效的布局也顾及空白,并不是说把所有东西都塞到尽可能小的空间中去。
现代显示器拥有足够的屏幕空间,应当尽可能有效地加以利用。
因此,宁可占用过多屏幕空间,也不要使用太少。
这么做可以使你的窗口感到更加轻便好用。
下列情况可以表明某布局确实有效地利用了屏幕空间:
不必调整窗口、面板及控件的尺寸即可使用。
如果用户首先做的事就是调整窗口、面板及控件的尺寸的话,该尺寸则是错误的。
数据没有被截断。
列表视图和树形视图中的大部分数据应当没有省略号,且其他控件中的数据不会被截断,除非数据特别的长。
完成任务所必须阅读的数据则不应当被截断。
窗口和控件的尺寸恰当,没有不必要的滚动。
仅有很少的水平滚动条,没有不必要的垂直滚动条。
控件基本使用其标准尺寸。
尽可能减少控件不同尺寸的数量,比如,在某个界面上只使用一两种按钮宽度。
该用户界面平衡良好,没有大量未使用的屏幕空间。
选择恰好能够很好地适合其用途的窗口尺寸。
(如果窗口是可缩放的,该条则应用于其默认尺寸。
)被截断的数据或滚动条与大量可用屏幕空间的情况同时存在则是布局不当的明显标志。
控件尺寸
充分利用屏幕空间的第一步往往是决定各种UI元素的合适尺寸。
参见及各控件设计规范中的推荐尺寸部分。
费茨法则指出,目标越小,鼠标指向其所需的时间就越长。
因此,对于那些使用WindowsTablet及触摸技术的计算机来说,这里所谓的“鼠标”事实上可能是手写笔或是用户的手指,因此你在为小控件确定尺寸的时候需要考虑其他输入设备。
16x16像素对于任何输入设备来说都是合适的最小控件尺寸。
相反,15x9像素的标准微调控件按钮对于手写笔来说则太小了一些。
间距
留出充足(但不过分)的间距会使布局看起来更加舒服并易于理解。
有效的空间并不只是未被使用的空间——它扮演了非常重要的角色,使用户更容易进行扫视、且给你的设计增添了视觉吸引力。
关于设计规范,参见。
再次说明,对于使用WindowsTablet和触摸技术的计算机来说,“鼠标”事实上可能是手写笔或是用户的手指。
当使用手写笔或手指作为定点设备时,定位会较为困难,以导致用户会点触到目标位置之外。
当交互控件彼此靠得很近但并没有直接接触的话,用户可能会点击在控件之间的非交互区域。
由于在非交互区域内点击不会产生任何结果或视觉反馈,用户往往无法确定哪里出了问题。
如果小控件靠得过近,用户则需要非常精确地点触以避免误按其他对象。
要解决这类问题,交互控件的目标区域要么彼此相接,要么之间留有至少3DLU(5像素)。
具有良好间距的布局是指:
整体上来说,用户界面看起来舒适,没有束缚感。
间距均匀且平衡。
相关元素彼此靠近,无关元素则分开。
对于如何可以称为靠近是没有固定的值的,比如工具栏按钮。
可缩放窗口
可缩放窗口也是有效使用屏幕空间的一个因素。
虽然这对于那些由固定内容组成的窗口来说没有什么帮助,但包含可缩放内容的窗口应当也是可缩放的。
显然,用户缩放窗口的原因是可以利用额外的屏幕空间,因此窗口内容也应当相应地扩展,为需要的UI元素提供更多空间。
可缩放窗口最适用于那些包含动态内容、文档、图像、列表及树的窗口。
在这个示例中,缩放窗口的同时会缩放列表视图控件。
这也意味着窗口可能被拉得太宽。
例如,许多控制面板页在宽度超过600相对像素时会显得笨拙。
在这种情况下,最好不要将内容区域缩放到超过最大宽度,或者是随着窗口的扩大而改变内容的原点位置。
相反,应当保持宽度的最大值并固定左上角的原点位置。
当行宽不断增加时,文本会变得难以阅读。
对于文本文档来说,考虑每行不超过80个字符以易于阅读。
(字符包括字母、标点和空格。
)
错误:
在这个示例中,文本太宽难以阅读。
最后,可缩放窗口在缩小时也需要有效使用屏幕空间,比如通过缩小可缩放的内容或是移除那些即使不存在也可以有效使用的UI元素。
有时,窗口或其UI元素可能会太小而无法使用,则应指定最小尺寸或者有些元素应当完全移去。
在这个示例中,该面板具有最小尺寸。
对于有些程序来说,更好的方法是使用完全不同的呈现方式以使其内容在较小尺寸下仍保持可用。
在这个示例中,WindowsMediaPlayer在其窗口太小,无法使用其标准模式时,进行了改变。
焦点
当某种布局中存在一个明显会被最先看到的地方时即称为具有“焦点(focus)”。
焦点非常重要,它告诉用户从何处开始扫视你的窗口或页面。
如果没有清晰的焦点,用户的目光则会漫无目的地游荡。
焦点应当位于那些用户需要快速找到并理解的重要内容处,且应当在视觉上予以强调。
左上角是大多数窗口的自然焦点。
应当只存在一个焦点。
在真实生活中,人眼一次只能聚焦在一件物体上,用户无法同时聚焦至多个位置。
要使某个UI元素成为焦点,可通过下列方式进行视觉加强:
置于界面上部的左侧或居中位置。
使用重要且易于理解的交互控件。
使用显着的文本,如主标题说明。
默认选中该控件并赋予输入焦点。
将控件置于不同的背景颜色上。
考虑一下Windows搜索。
Windows搜索的焦点应当在搜索框上,因为这是任务的起点。
然而,为了与标准搜索框的位置保持一致,它被放在了右上角。
虽然搜索框具有输入焦点,但是鉴于其在扫视路径上的位置,单单这样线索是不够的。
为了解决这个问题,窗口上方中部用一个显着的说明文字将用户引导至正确的位置。
可以接受:
在这个示例中,窗口上方中部的显着说明文字将用户引导至搜索框。
如果没有说明文字,该窗口将没有明显的焦点。
错误:
这个示例没有明显的焦点。
用户不知道应当从何处开始。
如果你对某个UI元素进行了视觉加强,应当确保这种注意力是合适的。
在之前那则错误的Windows搜索示示例中,高亮的All按钮位于左上角且是最为醒目的,然而它却并不是所期望的焦点。
用户可能会停在这个按钮处,试图弄清应该怎么做。
错误:
失去了显着的说明作为焦点,高亮的All按钮意外地成了焦点。
流程
当用户能够顺着界面上清晰的路径而流畅自然地按合适的顺序找到他们想要的UI元素时,该布局即称为具有好的“流程(flow)”。
一旦用户认出了焦点,他们就需要确定如何完成任务。
UI元素的位置传达了它们之间的关系,且应当反映出完成任务的步骤。
通常来说,这意味着任务的各个步骤应当自然地从左至右、从上至下(在西方文化中)排列。
具有好的流程的布局应满足下列条件:
UI元素的位置反映出用户完成该任务需要的步骤。
触发任务的UI元素位于左上角或上方中部。
完成任务的UI元素位于右下角。
相关的UI元素相互靠近,无关的元素则分离。
必须步骤应在主流程中。
可选步骤应在主流程之外,可以使用合适的背景或渐进展开的方式进行弱化。
经常使用的元素比不常使用的元素出现在扫视路径上的位置更靠前。
用户始终知道下一步要做什么。
任务流程中不存在出人意料的跳转或停止。
错误:
在这个示例中,用户不知道下一步该做什么。
任务流程中存在出人意料的跳转和停止。
正确:
在这个示例中,UI元素的呈现方式反映了完成任务所需的步骤。
分组
当那些在逻辑上相关的UI元素具有清晰地视觉联系时,该布局即可称为具有好的“分组(grouping)”。
分组非常重要,因为这使得用户能够更加容易地理解并专注于一组相关而非单独的条目。
分组可使布局显得更加简洁、易于理解。
你可以以下列方式进行分组(按分组程度由低到高排列):
布局。
你可以将相关的控件相互靠拢,并在无关的控件之间保留较大的间距。
在这个示例中,仅仅使用布局显示控件之间的关系。
分隔符。
分隔符是用于划分控件分组的水平或垂直线条。
分隔符提供了更加简洁的外观。
不过,与分组框不同,它们在横跨整个界面时最为合适。
在这个示例中,带标签的分隔符用于显示控件之间的关系。
聚合器。
聚合器是在强烈相关的控件间建立视觉联系的图形。
在这个示例中,边界聚合器用于强调控件之间的关系,使其看起来像是单个控件,而不是八个。
分组框。
分组框是环绕在一组相关控件外的带标签的矩形框。
在这个示例中,分组框用于圈出并标注一组相关的控件。
背景。
你可以使用背景来强调或弱化不同的内容。
在这个示例中,控制面板任务窗格用于对相关的任务和控制面板项进行分组。
要避免视觉混乱,能够达到效果的最轻量级的分组方式即是最好的选择。
更多信息,参见、、及。
无论使用何种分组方式,你都可以用缩进的方式在分组内部展示控件的关系。
互相平行的控件应当垂直对齐,相互依赖的控件则应当缩进12DLU或18像素。
有依赖关系的控件缩进了12DLU或18像素,在设计上,这是复选框及单选按钮到其标签之间的距离。
分组良好的布局满足以下条件:
窗口或页面中最多包含7个分组。
每个分组的用途很明显。
各组控件之间的关系显而易见,尤其是控件间的依赖关系。
分组是对内容的简化,而不是使其更为复杂。
对齐
对齐是UI元素按照基准而排列的方式。
对齐非常重要,因为这使内容更加易于扫视,并会降低用户所感受到的视觉复杂度。
当决定如何对齐时应当考虑下列目标:
易于水平扫视。
用户能够水平阅读并依次找到相关的条目,没有任何不适当的间隙。
易于垂直扫视。
用户可以扫视成列的相关条目并立即找到需要的内容,且只需最小的水平目光移动。
最小的视觉复杂度。
如果某个布局在垂直方向上存在不必要的对齐网格线的话,用户会觉得它在视觉上较为复杂。
水平对齐
左对齐
由于从左至右的阅读顺序,使得左对齐适用于绝大部分内容。
左对齐使得列数据易于垂直扫视。
右对齐
右对齐最适用于数值数据,尤其是。
右对齐也适用于以及与窗口右边缘对齐的控件。
在这个示例中,高级搜索渐进展开控件是向右对齐的,因为它是对着窗口右边侧而放置的。
居中对齐
居中对齐最适用于那些左对齐和右对齐都不合适或显得不平衡的情况。
在这个示例中,媒体播放器控件是居中的,以保持外观平衡。
不要仅仅为了填充空间而将窗口内容居中。
错误:
在这个示例中,内容为了填充空间而错误地在可缩放窗口中居中。
垂直居中
元素顶端
由于自上而下的阅读顺序,使得顶端对齐适用于绝大部分内容。
顶端对齐使得UI元素易于水平扫视。
文本基线
当控件与文本垂直对齐时,应当按照文本基线对齐以保持水平阅读流畅。
正确:
错误:
在正确的示例中,控件和其标签是按照各自的文本基线垂直对齐的。
对齐良好的布局应当满足下列条件:
水平和垂直方向都易于扫视。
简洁的视觉外观。
标签对齐
常规对齐规则适用于控件标签,但这也是值得特别注意的常见问题。
标签对齐包含以下目的:
易于垂直扫视以找到相应控件。
易于水平扫视以将标签及其控件联系起来。
易于本地化,处理在不同语言中长度不同的标签。
适用于不同标签长度混合的情况。
避免截断文本的同时,尽可能有效利用可用空间。
总体目标在于当寻找用户可能需要的内容时减少必须的视线移动,但控件的特性以及用户需要的内容则取决于上下文环境。
以下是四种常见的标签摆放和对齐样式,以及各自的特点:
标签在控件上方左对齐
标签在控件左侧左对齐
标签在控件左侧左对齐,控件的左侧错开排列
标签在控件左侧右对齐
标签在控件上方左对齐
该样式最易于本地化,因为该布局不依赖于标签的长度,但这是在垂直方向最占空间的样式。
该样式在垂直方向最占空间但易于本地化。
适用于标注绝大部分交互控件。
适用情形:
要标注的控件是可交互的(不仅仅是文本)。
该UI需要本地化。
该样式通常有足够的空间来容纳双倍甚至三倍长度的标签。
该UI使用固定布局技术(比如Win32)。
控件数量不超过10个。
当控件数量更多时,扫视标签将变得困难。
垂直方向上有足够的空间放置标签。
布局需要是自由表单,而不仅仅是按列排列。
标签在控件左侧左对齐
该样式是纵向扫视时最为方便的,且当标签长度不一时也能够适用,但在将标签与控件关联起来方面较为困难。
如果需要,该样式也可使用多行标签。
该样式很好用。
不过,这里的两列看上去像是四列——数据看起来更加复杂。
适用情形:
用户需要纵向扫视以寻找特定的标签。
用户不太需要以从左至右、从上至下的方式阅读标签和控件。
水平方向上有足够的空间放置标签。
标签在长度上有巨大差别。
控件很多,比如在表单中。
列数较少。
在视觉上,标签和控件像是两个独立的列。
标签在控件左侧左对齐,控件的左侧错开排列
该样式使得在纵向扫视标签以及横时同时扫视标签和控件时较为方便,而且空间利用率很高,但纵向扫视控件较为困难。
控件右侧对齐以充分利用空间。
该样式布局紧凑,易于阅读,但对控件的纵向扫视较为困难。
适用情形:
该UI使用可变布局技术(比如WindowsPresentationFoundation)。
用户需要纵向扫视以寻找特定标签。
用户需要以从左至右,从上至下的方式阅读标签和控件。
用户不太可能需要纵向扫视控件。
控件文本的长度差别很大,如果使用其他样式可能会被截断。
控件是只读的,比如只读文本框。
对于其他控件,这种对齐方式看起来有些糟糕。
不过,控件可以在单击时变为可编辑状态。