以用户为中心的设计 |
|||
最近在做一些测试,为产品的顺利公测做部分支持。 以下为Desktop端的测试。 第一部分: Windows程序UI设计初步 1.背景介绍 UI就是用户界面( user interface ) ,就是人和工具之间的界面。在人和机器的互动过程中,必须经由界面。这个界面实际上是体现在我们生活中的每一个环节的,例如我们开车时候方向盘和仪表盘就是这个界面,看电视的时候遥控器和屏幕就是这个界面,用电脑的时候键盘和显示器就是这个界面,到了使用软件的时候,用户能够通过视觉看到的都是界面。这个界面包括硬件和软件。我们这里讲的UI设计特指Windows操作系统下的软件界面。 用户界面设计有三个基本的原则:a. 置界面于用户的控制之下;b. 减少用户的负担;c. 保持界面的一致性。 从程序设计开发的角度来看,界面设计可以分为结构设计、交互设计、视觉设计三个部分。 结构设计也称概念设计 (Conceptual Design),是界面设计的骨架,通过对用户研究和任务分析,制定出产品的整体架构。基于纸质的的低保真原型(Paper Prototype)可提供用户测试并进行完善。在结构设计中,目录体系的逻辑分类和语词定义是用户易于理解和操作的重要前提。 交互设计是程序的神经,使用户与软件处理部分进行沟通,最终目的是使产品让用户能简单使用。 任何产品功能的实现都是通过人和机器的交互来完成的。因此,人的因素应作为设计的核心被体现出来。 1)有清楚的错误提示。错误操作后,系统提供有针对性的提示。 2)让用户控制界面。“下一步”、“完成”,面对不同层次提供多种选择,给不同层次的用户提供多种可能性。 3)允许兼用鼠标和键盘。同一种功能,同时可以用鼠标和键盘。提供多种可能性。 4)允许工作中断。例如用手机写新短信的时候,收到短信或电话,完成后回来仍能够找到刚才正写的新短信。 5)使用用户的语言,而非技术的语言。 6)提供快速反馈。给用户心理上的暗示,避免用户焦急。 7)方便退出,如手机的退出,是按一个键完全退出,还是一层一层的退出。提供两种可能性。 8)导航功能。随时转移功能,很容易从一个功能跳到另外一个功能。 视觉设计是在结构设计的基础上,参照目标群体的心理模型和任务达成的,是程序的脸面,要达到使用户愉悦的目的,包括色彩、字体、页面等。视觉设计的原则如下: 1)界面清晰明了。允许用户定制界面。 2)减少短期记忆的负担。让计算机帮助记忆,例:User Name,、Password、IE进入界面地址可以让机器记住。 3) 依赖认知而非记忆。如打印图标的记忆、下拉菜单列表中的选择。 4)提供视觉线索。图形符号的视觉的刺激;GUI(图形界面设计):Where, What, Next Step。 5)提供默认(default)、撤销(undo)、恢复(redo)的功能 6)提供界面的快捷方式。 7)尽量使用真实世界的比喻。如:电话、打印机的图标设计,尊重用户以往的使用经验。 8)完善视觉的清晰度。条理清晰;图片、文字的布局和隐喻不要让用户去猜。 9)界面的协调一致。如手机界面按钮排放,左键肯定;右键否定;或按内容摆放。 10)同样功能用同样的图形。 11)色彩与内容。整体软件不超过5个色系,尽量少用红色、绿色。近似的颜色表示近似的意思。 2. UI设计的一些原则。 对于Windows用户来说,用户认识到的就是所看到的。必须看到的现实就是:界面是面向用户的,用户需要的是开发者开发的应用软件满足其需求,并且易于使用。好的用户界面使得用户不用阅读用户手册或接受培训就能使用应用软件。 2.1 交互设计的一些原则: 2.1.5在操作焦点处打开窗口。当用户双击一个对象显示其编辑/详情屏幕,用户的注意力亦集中于此。因而在此处而不是其它地方打开窗口才有意义。 2.1.7提供标准的常用功能 ,提供界面的快捷方式。如,常用的按钮、菜单应该有和其它同类软件相同的快捷键,一般 打开放在文件菜单下。如果一个菜单项,按下去会弹出一个窗口,那么这个菜单项的文字末尾应该有一个省略号来暗示用户,例如 “打开…” 2.1.8要考虑各种层次的用户的操作水平的不均衡。 2.2视觉设计的一些原则: 2.2.1一致性。保证界面的协调一致。对于列表框来说,如果双击其中的项,使得某些事件发生,那么双击任何其它列表框中的项,都应该有同样的事件发生。所有窗口按钮的位置要一致,标签和讯息的措辞要一致,颜色方案要一致。 2.2.2 界面布局很重要。人们是自左而右,从上而下阅读,基于人们的习惯,屏幕的组织也应当是自左而右,从上而下。界面清晰明了,屏幕不能拥挤,拥挤的屏幕让人难以使用。实验结果(Mayhew,1992年)显示屏幕总体盖度不应超过40%,而分组中屏幕盖度不应超过62%。如果要表达的信息比较多,最好分屏显示。 区域排列。当屏幕有多个编辑区域,要以视觉效果和效率来组织这些区域。区域左对齐是最好的方法。与之相应的标签则应右对齐,置于编辑区域旁。这是屏幕上组织区域的一个整洁有效的方式。 数据对齐要适当。对一列列的数据,通常的作法是整浮点数右对齐,字符串左对齐。 有效组合。逻辑上关联的项目在屏幕上应当加以组合,以显示其关联性。反之,任何相互之间毫不相关的项目应当分隔开。在项目集合间用间隔对其进行分组/或用方框也同样可做到这一点。 2.2.3界面间切换很重要。如果从一个屏幕转换到另一屏幕很困难,用户会很快灰心并放弃。当屏幕流程与用户想完成的工作流程相符,此软件对用户才有意义。由于不同用户工作方式不同,应用软件需要有足够的灵活以支持他们不同的方式。尽可能的提供给用户一个相对容易、自由的操作界面; 2.2.6豪华界面,不适合所有的软件。华而不实的感觉往往来自界面。一般来讲,游戏类、播放器类,需要美丽的界面。 3. 用户的操作 对于用户来说,操作越简单越好,程序的使用思路越清晰越好。下面结合环境简单说明一下常用控件该如何合理使用。 3.1对于较长时间的运算: 建议使用进度条(progress bar)比如要进行数据库操作,需要时间长的情况。使用进度条可以让用户有个等待的时间,否则用户不知道你的程序在干什么,用户对于不明不白花费的时间一般容易恼火。设计的时候,对自己的操作运算时间进行估算,确定是否需要使用。如果只有5秒钟,用户一般是可以忍受的,加入进度条反而会产生画蛇添足的效果。 在使用进度条的同时,可以配合使用状态栏。StatusBar经常被放置在窗体的下面,建议使用dock。可以在状态栏中提供多个面板(pane)来提供不同的信息。 状态栏中,通常都会有一个面板来提示程序运行的信息,例如显示进度,时间等。需要扩展的话,需要owerndrawn属性支持。可以添加按钮等,如取消。一般,在长时间的后台运算开始时,在状态栏中设置开始的状态信息,在计算结束之后,清除状态信息或将状态信息设置为停止状态,在后台运行期间通过状态栏来显示必要的错误信息,提示用户当前的状态。比如,进行一个计算时,开始显示:正在计算,请耐心等待。当运算结束时显示:可以结束,正确退出。 等待指针的使用,在进行计算的时候,尤其在很难计算出这些操作的进度的情况下,设置前台鼠标指针为wait cursor是对用户一个很好的提示。如果有些操作必须是阻塞的,这时需要使用等待指针(wait cursor)也是对用户很好的交代。同样,光标的形状是非常灵活的,合理的使用能够给用户恰当的提示。 总之,使用上面的控件,能通过可视化的方式通知用户有一些程序正在执行过程中,可能需要等待一定的时间。 在程序中合理使用try…finally语句可以达到很好的效果。保证无论遇到什么情况,是正常也还,是异常也好,反正最后都会执行到finally。 3.2操作开始之后,在适当的时候提供必要的程序开关。 用户应当能够通过界面操作取消或终止较长时间的运算。不管你在做什么,都要给用户一个机会,因为用户是程序的使用着。当然,不能让用户,任何时间都可以插手程序的操作,比方,一个数据保存的界面,保存,关闭,取消三个按钮,当正在保存数据的时候,如果强行关闭的话,会导致数据的异常,在这种情况下就需要适当的启用,禁用控件。对于该界面来说,“保存”点击后,禁用“关闭按钮”。在保存处理完毕后,再启用“保存按钮”。 3.3适时合理禁用一些菜单 通过可视化的方式提示用户在运行某些程序的时候某些功能是被禁用的,程序结束后,重新启用一些被禁止的菜单和控件,并通过适当的方式提示用户操作已完成。同时,适当的启用禁用菜单可以使用户更清晰的理解应用程序的工作流程,理解应用程序执行的逻辑。比如用户,一般先要看你界面上什么功能可以使用,什么需要达到一定的前提才能使用。在执行某功能的时候,通过禁用启用,可以知道这个不能执行。当执行完毕后,用户发现,哦,那个按钮亮了,可以执行了。 3.4验证用户的输入,使用validation control。 避免因为用户的失误,导致程序的失败,意外。使用界面友好的MessageBox,注意要在提示对话框中使用适当的按钮和图标,它的重载比较多,根据具体的情况选择不同的图标和按钮。比方说,如果用户强行退出,可以弹出警告,这个时候就应该告诫用户可能产生的不良后果。 3.6使用适当的控件 使用TreeView控件来显示有层次的数据,使用ListView来显示一组具有多个列的数据,使用DataGrid控件可以让用户改变每一个单元格中的数据,使用TabControl可以将窗体中的控件按照使用逻辑进行分类,根据具体的需要开发复合控件,扩展控件,自定义控件。 3.7 合理使用Splitters Docking与Anchoring属性 当窗体放大时,你的窗体上的各种元素是否能够按照比例放大,并且填充区域呢。 用Splitter控件来分离用户区域,使用Dock属性的Fill选项使控件能够填充屏幕的一部分,设置Anchor可以在窗口大小变化时,保证窗体中的控件与窗体的相对位置不发生变化。通过设置 3.8不同分辨率下显示效果的自动调整。 考虑到用户的使用环境,程序在高分辨率下,字体,图片,显示需要随着分辨率自动调整,以满足用户的视觉效果。 3.9通过使用Common Dialog可以让用户通过熟悉的界面来实行标准的操作 ColorDialog,FontDialog,OpenFileDialog等等 3.10对于较长时间的操作,不要阻塞主线程,也就是UI线程 如果时间长的话,建议使用多线程。可以使用ThreadPool.QueueUserWorkItem()来进行异步调用。在该类中,管理线程,QueueUserWorkItem:将方法变成代理,将代理交给QueueUserWorkItem,如果没有其他线程,则立即计算,否则需要等待,给用户提供 取消/停止 的功能。从其它线程中更新用户界面中的控件,需要使用BeginInvoke和delegate。Hook,当前线程中调用的方法,获得另外线程中的方法,在另外的线程中操作。不是用来创建线程,只是让线程去执行想执行的方法。代理 函数指针的封装,自己作为对象 在程序中传递,实现callback机制。在NF2中,使用辅助线程Backgroundworker 3.11关闭确认原则。关闭需要激活原则,使权限不够的用户不能关闭程序。对实时软件尤其重要。 第二部分:UI测试要点 一. UI测试概念 UI测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等。 用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化,易操作性测试。UI测试比较主观,与测试人员的喜好有关,比如:页面基调颜色刺眼;用户登入页面比较难于找到,文字中出现错别字,页面图片范围太广等都属于UI测试中的缺陷,但是这些缺陷都不太严重。 二. UI测试要点 1. 按功能将界面划分局域块,完成相同或相近功能的按钮框起来, 并要有功能说明 2. 界面要支持按Tab键的自动切换功能;Tab键切换是否正确; Tab键的顺序与控件排列顺序要一直,目前流行总体从上到下,同时行间从左到右的方式; 3. 默认按钮要支持Enter及选操作,即按Enter后自动执行默认按钮对应操作 4. 菜单点击,窗口初始化 5. 父窗体或主窗体的中心位置应该在对角线焦点附近;子窗体位置应该在主窗体的左上角或正中;多个子窗体弹出时应该依次向右下方偏移,以显示窗体出标题为宜 6. 在各种分辨率下是否显示正常 7. 前景与背景色搭配合理协调,反差不宜太大,最好少用深色,如大红、大绿等。常用色考虑使用Windows界面色调。 8. 如果窗体支持最小化和最大化或放大时,窗体上的控件也要随着窗体而缩放;对于含有按钮的界面一般不应该支持缩放,即右上角只有关闭功能。 9. 窗体能否多次正确关闭,打开 10. 滚动条是否能拖动,并可通过键盘自动拖动 11. 与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示,没法使用该按钮)。 12. 对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会,如删除确认提示,退出前确认是否保存 13. 可写控件的数据类型及长度,尽量在前台进行控制 14. 非法的输入或操作应有足够的提示说明, 让用户明白错误出处,避免形成无限期的等待,提示、警告、或错误说明应该清楚、明了、恰当;提示顺序按Tab顺序 15. 对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符, 特殊字符常有;;’”><,`‘:“[”{、\|}]+=)-(_*&&^%$#@!,.。?/还有空格 16. 在读入用户所输入的信息时,根据需要选择是否去掉前后空格。 三. 一般客户端测试逻辑划分 1. 标题栏 a、标题文字描述的正确性 b、标题栏中(最大化、最小化、关闭)按钮,根据窗口的特性,如没有最大化或者最小化状态的窗口,应该不显示最大化和最小化按钮,或者把按钮Disable状态显示。 2. 文字 (1)文字描述的准确性: a、检查文字的描述和所对应的功能是否一致; b、检查错别字。 (2)文字用语的一致性: (菜单、界面按钮或者Label等、ToolTip、窗口标题)比如选项设置,在主界面的有按钮可以进入选项设置对话框,或者菜单中有菜单项可进入选项设置对话框中,那么,按钮、菜单、对话框的标题都应该统一用词,如用“选项”或者“设置”,而不能又用“选项”,又用“设置”,或者还有其他的的用词。 (3)为了全面的检查所有的文字,应该检查程序中的所有文字资源,因为一些对话框可能比较难在黑盒测试的时候能全部都出现过。 3. 控件 (1) 控件对齐: a、 并排关系的控件间应该左对齐,同行的控件应该横向对齐。 b、 有所属关系的控件应该缩进。 (2)控件状态: a、不能操作的的控件的状态应该为Disable,这样界面也起到引导用户使用操作的效果。 b、有依赖关系的控件,比如(几个选项供选择(CheckBox或者RadioBox),每个选项下面都有独立的设置(其他的控件:Edit、 ComboBox、CheckBox等),那么当所属的选项没有选中时,下面的控件应该是Disable的,相反为Enable。 (3)控件的TabOrder 控件的TabOrder应该依次从上到下、从左到右的顺序,界面中默认的TabOrder应该落在界面上的第一个Enable状态的控件上面。 (4)控件的右键菜单支持 允许输入的控件都应该支持右键菜单,方便习惯使用右键菜单的用户复制、剪切、粘贴、全选等操作。 (5)控件的操作方式 a、单行文本的Edit输入框中,对回车符的支持:回车默认操作是本窗口中的“确定”按钮的功能。 b、在可操作的列表控件(List、ListView)中,鼠标双击的操作、键盘操作都应该有对应的默认操作。比如下面的图中,双击列表中某一项,默认操作就是Modify按钮的操作;双击列表中的空白处,默认操作应该是Add按钮的操作;选中列表中的项的情况下,按下Delete键,默认操作应该是 Remove按钮的操作。 (6)Edit控件对输入的有效性判断 a、类型判断:整型、浮点型的数据输入框中,不允许输入非表示数据的其他字符串(如:abcd或者其他字符等); b、大小判断:数据类型的数据如有大小范围限制的,要对输入的大小进行判断(如:表示月份的输入框中,只能允许输入1-12的数字。 c、长度判断:如果是程序处理的字符串有长度限制,但是输入框中没有对输入的数据长度进行限制,将有可能会造成程序错误,或者处理后的结果和输入的不相符合。 d、正确性判断:表示路径的或者文件名全路径的输入框,要对输入的路径是否为有效的路径进行判断,如:输入aaaa或者 C:\\//等为不正确的输入。 4. 图片 图片显示的篇幅不要太大。 5. 界面整体的颜色搭配 6. 窗口在任务栏上的系统菜单 每个应用程序,如窗口在系统任务栏上有缩小图标的,都应该有系统右键菜单的支持(还原、最大化、最小化等),要测试右键菜单中各个项的Enable和Disable状态的正确性以及功能的正确性。 7. 提示对话框测试 1、文字描述的正确性 2、图标显示的正确性: a、程序错误、操作错误、禁止操作等的提示:MB_ICONHAND, MB_ICONSTOP,MB_ICONERROR b、询问的提示:MB_ICONQUESTION c、感叹、警告的提示:MB_ICONEXCLAMATION ,MB_ICONWARNING d、普通信息的提示:MB_ICONASTERISK,MB_ICONINFORMATION 第三部分: UE测试概要 UE(User Experience 用户体验):指的是软件应用和审美价值,是以用户至上的观点作为基石的。主要由以下四种因素构成: 用户体验是一种纯主观的在用户使用一个产品(服务)的过程中建立起来的心理感受。因为它是纯主观的,就带有一定的不确定因素。个体差异也决定了每个用户的真实体验是无法通过其他途径来完全模拟或再现的。但是对于一个界定明确的用户群体来讲,其用户体验的共性是能够经由良好设计的实验来认识到。 用户体验主要是来自用户和人机界面的交互过程。在早期的软件设计过程中,人机界面被看做仅仅是一层包裹于功能核心之外的“包装”而没有得到足够的重视。其结果就是对人机界面的开发是独立于功能核心的开发,而且往往是在整个开发过程的尾声部分才开始的。这种方式极大地限制了对人机交互的设计,其结果带有很大的风险性。因为在最后阶段再修改功能核心的设计代价巨大,牺牲人机交互界面便是唯一的出路。这种带有猜测性和赌博性的开发几乎是难以获得令人满意的用户体验。至于客户服务,从广义上说也是用户体验的一部分,因为它是同产品自身的设计分不开的。客户服务更多的是对人员素质的要求,而已经难以改变已经完成并投入市场的产品了。但是一个好的设计可以减少用户对客户服务的需要,从而减少公司在客户服务方面的投入,也降低由于客户服务质量引发用户流失的机率。 现在流行的设计过程注重以用户为中心。用户体验的概念从开发的最早期就开始进入整个流程,并贯穿始终。其目的就是保证(1)对用户体验有正确的预估(2)认识用户的真实期望和目的(3)在功能核心还能够以低廉成本加以修改的时候对设计进行修正(4)保证功能核心同人机界面之间的协调工作,减少BUG。 在具体的实施上,就包括了早期的focus group(焦点小组),contextual interview,和开发过程中的多次usability study(可用性实验),以及后期的user test(用户测试)。在设计–测试–修改这个反复循环的开发流程中,可用性实验为何时出离该循环提供了可量化的指标。
|