香蒲对《可用性工程》的笔记(5)

可用性工程
  • 书名: 可用性工程
  • 作者: 尼尔森
  • 页数: 227
  • 出版社: 机械工业出版社
  • 出版年: 2004-1
  • 第31页 第1,2 章
    • 中文版序
    • 译者序
    • 前言
    • 第 1 章本书概要
      • 1.1 节省成本
      • 1.2 可用性:从现在做起
      • 1.3 可用性警句…
        • 不能凭相像和猜测
        • 用户总是对的
        • 用户并不总是对的
        • 用户不是设计人员
        • 设计人员不是用户
        • 副总裁不是用户
        • 少就是多
        • 细节是重要的
        • 帮助并不能帮助
        • 可用性工程是一个过程
      • 1.4 简化可用性工程
        • 用户和任务观察
        • 剧情
        • 简化自言自语
        • 经验性评估
      • 1.5 该怎样做…
    • 第 2 章什么是可用性
      • 2.1 可用性及其他相关概念
      • 2.2 可用性定义…
        • 可用性属性
        • 可学习性(learnability
        • 效率(efficiency
        • 可记忆性(memorability
        • 出错(errors
        • 满意度(satisfaction
      • 2.3 实例:图标的可用性度量……
      • 2.4 可用性权衡
      • 2.5 用户分类及用户个体差异……

    中文版序

    译者序

    前言

    第 1 章本书概要

    1.1 节省成本

    关于因采用可用性工程方法而节省成本的情况,有若干证据充分的实例。例如

    当对某种旋转拨号盘电话进行第一次测试的时候,发现用户拨号很慢。一位人类因素学专家花了一个小时设计出一种简单的图形界面部件,使用户拨每位号码的拨号操作时间缩短了 0.15 秒,这样,每年在减少中央交换机需求方面可以节省约 100000 美元【Karlin and Klemmer1989]。

    有一家澳大利亚保险公司对申请表格进行了重新设计,以减少顾客填表时出错的可能性,每年可以节省 536023 澳元【Fisher and Sless 1990]。而可用性项目的成本只有不到 100000 澳元。原先的表格填写起来很困难,以至于每份表格平均有 7.8 个错误,这使得公司职员不得不在每份表格上花费一个多小时来改正错误。

    。一家著名的计算机公司通过改进设计来加快某个安全应用程序的注册速度,结果在系统投入使用的第一天就节省了 41700 美元。这可用性改进是通过反复设计来实现的,为此只花了 20700 美元 Karat 1990]。在 Haris [1984] 所讨论的 25 个“人类因素学成功案例”中,包括有波音 757 驾驶座舱界面的改进,使飞行员由 3 人减到 2 人;集成电路生产线的生产效率提高了 35%;某传呼设备的操作手册由 3000 年减少到 150 字;甚至还包括酒后驾驶检测系统的改进,使每个警察每小时出巡时间内的捕获率提高了 12%等等。

    由于可用性方法所带来的经济上的好处,许多是在产品发布以后才显现出来,

    1.2 可用性:从现在做起

    1.3 可用性警句…

    不能凭相像和猜测

    用户总是对的

    需要修改原来的设计来解决用户遇到的问题。设计人员的正确态度应当是,如果用户在界面的某个方面遇到问题,那么应当意识到这并不是由于用户的愚蠢,也不是由于用户没有认真操作。有人曾经测试过一本用户手册的可用性,发现用户总是在某个特定过程的特定步骤上出错。他们的解决办法就是,把用户遇到困难的那个步骤的有关描述框起来,在上面加上这样一句提示“仔细阅读这段说明!”。当然,从中得到的正确结论不应当是这样的,而应当是:这段描述太难理解了,应当重写。

    用户并不总是对的

    用户不是设计人员

    设计人员不是用户

    副总裁不是用户

    少就是多

    细节是重要的

    帮助并不能帮助

    可用性工程是一个过程

    1.4 简化可用性工程

    可用性专家经常会建议采用最好的方法。的确,在几乎所有的大学里他们受的都是这样的训练。然而,““最好'是・好”的敌人”【Voltaire1764] 这句话似乎是有道理的,如果一味地坚持采用最好的方法,可能会导致没有方法可以采用

    所谓的“简化可用性工程”【Nielsen1989 b,199 b,199」方法的基础是所采用的以下四种技术

    用户和任务观察

    观察用户,保持安静,让用户在不被打扰的情况下正常工作。

    剧情

    剧情可以作为纸面原型【Nielsen1990 d】来实现,或者借助比复杂的程序设计环境【Nielsen et al.1991] 更容易掌握的简单原型环境【Nielsen 1989 a】来实现。

    简化自言自语

    6.8 节将会详细介绍边做边说方法。这种方法的基本做法是每次让一个测试用户使用系统来执行一组给定任务,在这个过程中边做边“自言自语”。

    经验性评估

    简单自然的对话:对话中不应当包含无关或大多数情况下不需要的信息。对话中的任何额外信息都会分散对相关信息的注意力,从而降低其相对可见性。对所有信息都应以自然和合平逻辑的次序出现采用用户的语盲:对话应当以用户熟悉的词汇和概念,而不是面向系统的术语来表达

    将用户的记忆负担减到最小:不应当要求用户在对话过程中必须记住某个地方的信息才能进行另一个地方的操作。对于系统使用的指令应当在需要时是可见或容易获得的

    一致性:不应当让用户为不同的词语、状态和动作是否是同一个意思而感到迷感反愤:系统应当总是在合理的时间内,通过适当的反馈信息让用户了解系统正在做什么

    清断的退出路径:用户经常会误选系统功能,因而需要一个清晰标明的“紧急出 1”来退出所不希望的状态,而不必非得经过由此而导致的多余对话

    快捷方式:新手用户看不到的快捷键经常可以加快熟练用户的交互操作,从而使系统可以同时适合新手用户和有

    经验的用户

    良好的出错倍息:出错信息应当用通俗的语言(不要使用代码)来表达,准确指出问题,建设性地给出解决办法遵免出错:比良好的出错信息更好的办法是,首先通过精心的设计来防止问题的发生

    助与文档:尽管最好是让用户可以在不使用文档的情况下使用系统,但可能还是需要提供帮助和文档。任何这类信息都应当容易查找,紧紧围绕用户的任务,给出要做的具体步骤,而且篇幅不要太长。

    1.5 该怎样做…

    从管理的角度来看,需要采取的行动是

    1) 认识到你所在的组织对于可用性的需求。

    2) 明确管理上对可用性的支持(这包括推动这样一种文化的形成:开发人员修改最初的设计方案,以使之适合用户需要的做法是受到肯定的)。

    3) 给可用性工程投入一定的专用资源(开始时投入的资源可以是较少的,但需要有一个最低限度的用于可用性的专用资源,以保证它不会成为来自最后工期压力的牺牲品)。

    4) 将系统化的可用性工程活动集成到开发生命周期的各个阶段(见第 4 章),包括早期阶段。

    5) 确保所有用户界面都经过用户测试。

    如果你认为这 5 个步骤太多了,可以先试试下面这一个步骤

    选择一个你已有的用户界面。对它进行一次简单的用户测试,定义若干典型的测试任务,找几个以前没有使用过该系统的可能顾客,在他们用系统尝试执行任务时,对他们进行观察(不要有任何的帮助和干扰)。如果没有发现任何可用性问题,那么应当庆幸运气不错。而更可能发生的情况是发现了一些问题,这样你就已经定义了你的第一个可用性项目:通过采用反复设计方法在下一个版本纠正这些问题。

    第 2 章什么是可用性

    2.1 可用性及其他相关概念

    在某种程度上,与更大的系统可接受性(acceptability)概念相比,可用性是一个较窄的概念,前者是有关系统是否足够良好,是否可以达到满足用户及其他可能的相关方(如用户的客户和经理)的所有需要和需求的程度。计算机系统的整体可接受性,又是由社会可接受性(social acceptability)和实际可接受性(practical acceptability)组合而成的。

    作为社会可接受性的例子,让我们来考虑这样一个系统,它用来调查那些申请失业救济的人目前是否有支付薪酬的工作,即是否在申请上有欺诈行为。该系统可能会向用户询问一些问题,从中寻找前后矛盾之处或者说谎的迹象。有的人可能认为这种欺诈防范系统对社会很有好处,而有的人则可能认为它对申请人的盘问是种冒犯,而且延后具有某些特征的申请人得到救济的时间对社会是不利的。在这里,后一种人可能会认为系统是不可接受的,即使它因为能识别出许多说谎者并且让申请人感到容易使用,而在实际可接受性方面得到较高评价。

    如果某个系统具有社会可接受性,我们可以进一步分析它在各个方面的实际可接受性,这包括一些传统的方面,如成本、技术支持、可靠性、与已有系统的兼容性等,以及有用性。有用性(usefulness)指的是系统能否用来达到某个想要的目标。它可以被进一步分解为实用性和可用性[Grudin 1992]。这里,实用性(utility)指的是系统的功能在原理上是否能够做所需要的事情,而可用性(usability)指的则是用户能否很好地使用系统的功能。请注意,“实用性”这个概念并不一定限于工作范畴。教育软件(“课件”)的实用性在于学生能否通过使用它来达到学习目的,娛乐产品的实用性在于使用起来是否有趣。这里概要介绍的系统可接受性的简单模型如图 2-1 所示。图中清楚地表明,系统可接受性具有许多成分,而在一个开发项目中,在可用性与其他许多方面的考虑因素之间必须进行权衡。

    2.2 可用性定义…

    可用性属性

    可学习性(learnability):系统应当容易学习,从而用户可以在短时间内开始用系统来做某些事情。

    效率(efficiency):系统的使用应当高效,因此当用户学会使用系统之后,可能具有高的生产力水平。

    可记忆性(memorability):系统应当容易记忆,从而那些非频繁使用系统的用户,在中间有一段时间没有使用之后能够使用系统,而不用切事情从头学起。

    出错(errors):系统应当具有低的出错率,从而用户在使用系统的过程中能够少出错,在出错之后也能够迅速恢复。而且必须能够防止灾难性错误的发生。

    满意度(satisfaction):系统应当使用起来令人愉快,从而让用户在使用时主观上感到满意,喜欢使用系统。

    可用性通常是通过让一些测试用户(尽可能地选择那些能代表目标用户的人)使用系统来执行一组预定的任务来进行度量的,当然,也可以通过让真实的用户在工作现场执行自己的日常任务的办法来进行度量。不论是哪种情况,重要的一点是要针对特定用户和特定任务来度量可用性。

    为了在一组可用性度量的基础上确定系统的整体可用性水平,通常的做法是取每个可用性属性度量的平均值,然后看它们是否比先前确定的某个最低标准要好(参见 4.3 节)。由于我们知道用户之间的差别可能是挺大的,所以最好考虑可用性度量值的整个分布情况,而不仅仅只是一个平均值。例如,主观满意度的标准可以是在 15分的 5 分制情况下平均值至少为 4; 也可以是至少 50%的用户给系统打 5 分;也可以是给系统打 1 分的用户不超过 5%。

    可学习性(learnability)

    容易学习。

    通常人们都是需要一定的学习时间的。

    有例外情况,这包括所谓的走来即用(walk- up-and-use)系统,如博物馆信息系统,这种系统的使用通常是一次性的,因此所需的学习时间应当为零,让用户可以在第一次尝试使用时就能够成功。

    除了主观满意度之外,初始易学习性也许是可用性属性中最容易度量的。可以直接找一些以前没有用过系统的用户,然后度量他们达到某种熟练使用程度所用的时间。

    在分析可学习性时,应当意识到用户通常并不是在花时间学完了整个用户界面之后,才开始使用系统。相反,用户经常是只学习了部分界面就开始使用。例如,在一项针对那些身为有经验的个人计算机用户的商务专业人员的调查中【Nielsen1989 e】,我们发现,在 6 个得分最高的可用性特征中(总共调查了 21 个特征),有 4 个与探索性学习有关:容易理解的出错信息、在学习程序的全部功能之前就可以用它来做有用的事情、具有撤消功能以及在执行有风险的命令之前进行确认。由于用户具有这种直接上手使用系统的倾向,所以不仅要度量用户需要花多长时间掌握整个系统,还应当度量需要花多长时间可以达到能够做些有用的事情的熟练程度。

    效率(efficiency)

    因此,度量使用效率的典型方法就是,确定类于技能水平的某种定义寻找一些具有这种技能水平的有代表性的用户样本,然后度量这些用户执行某些典型测试任务所用时间

    可记忆性(memorability)

    非频繁使用用户

    对界面可记忆性的测试,很少像对其他可用性属性那样全面。但从原理上说,有两种主要的度量方法。一种方法是对于在特定长的一段时间内没有使用系统的用户,进行标准用户测试,度量这些用户执行某些特定任务所用的时间。另一种方法是对用户进行记忆测试,在他们结東一个使用系统的过程后,让其解释各种命令的作用,或者说出完成某种功能的命令(或画出对应的图标)。最后得到的用户界面可记忆性得分,就是用户给出的正确答案的个数。

    【满分100,全部记住。】

    出错(errors)

    少出错,无灾难性错误

    应当让用户在使用计算机系统的过程中尽可能少出错。通常错误被定义为不能实现预定目标的任何操作,而系统的出错率是通过用户执行某个特定任务时统计这种操作的次数来度量的。从而,可以作为度量其他可用性属性的试验的一部分来度量出错率。

    某些出错可以被用户立刻纠正,除了使用户的事务处理速度降低之外,没有什么其他的影响。对于这类出错没有必要单独统计,因为如果按常规根据事务处理时间来度量使用效率的话,其影响会被包含在使用效率中。

    而某些错误从性质上来看则更具有灾难性,这或者是由于不能被用户所发现,从而造成有问题的工作结果,或者是由于它们破坏用户的工作,使之难以恢复。对于这类灾难性的错误应当与轻微错误分开统计,要采取特殊措施将其发生频度降到最低。

    满意度(satisfaction)

    这里需要注意,作为一项可用性属性的主观满意度,与公众对于计算机的总的态度并不是一回事。尽管一个人对计算机的态度,一般来说可能会影响这个人喜欢与某个特定系统交互的程度,但人们对于计算机的态度也许般应当被看成是计算机的社会可接受性的组成部分,而不是可用性的组成部分。

    从原理上来说,也许可以采用某些客观度量指标,而不是通过询问用户的主观倾向来评估界面令人愉快的性质。在为数不多的几个案例中,人们采用了脑电图、瞳孔扩散率、心率、皮肤传导率、血压和血液肾上腺素浓度心理-生理指标评估用户的压力和舒适程度【Mullins and Treu1991; Schleifer 1990; Wastell199。不过,这种度量需要那种让人感到畏惧的试验条件比如把用户连到脑电图仪器上,或者采集用户的血样。由于测试用户本来已经感到比较紧张了,而且一种放松的氛围对很多用户测试来说都很重要(见 6.4 节),所以在可用性工程研究中,心理-生理方法往往不合适。

    主观满意度也可以通过询问用户的主观想法来进行度量。从任何一个用户的角度来看,对这种问题的回答都是主观的,但当把许多用户的回答平均起来,得到的结果就是对于系统令人愉快程度的一种客观度量。由于主观满意度这一可用性属性的目的是衡量用户是否喜欢系统,因此,通过询问用户来进行度量似乎是很合适的,这也的确是大量可用性研究所采用的方法。

    为了保证度量的一致性,通常是在用户测试后进行总结时,让用户填写份简短的问卷,来进行主观满意度的度量。

    我们知道,用户可能因为看到用户手册太厚,而拒绝使用某个程序【Nielsen et al.1986】,甚至根本没有去读一读,看是否真的如他们想像的那么难读。所以,应当研究一下系统的可接近性(approachability)(从市场营销的角度来看这一点特别重要)[Angiolillo and Roberts1991]。为此,可以向用户展示系统,然后问用户“你认为学习使用这个系统的难易程度如何?”,但在这里,不要指望用户的回答与系统的实际可学习性之间会有多大的相关性。

    即使用户的确使用过系统,他们对于系统使用难度的主观评价,也会更接近对系统中最难的地方的评价,而不是平均难度最艰难的经历对用户来说是最难忘的。在一项试验中,执行任务过程中最困难的地方,在用户关于系统使用难度的主观评价中占到 31%,而任务执行时间则只占到 7% [Cordes 1993]。从中可以得到这样的结论,如果目标是改进系统的整体性能,那么就不能只依赖用户的评价。而在另一个方面,由于对销售方面的考虑,需要让用户相信系统是容易使用的,以便产生好的口碑。而且这种印象可以通过个平淡而不存在特别难度的界面来进一步得到加强;而一个大部分地方都很出色,但却有一个地方让用户感到很难使用的系统,则会起到相反的作用。

    主观满意度问卷通常都很简短,尽管也开发了某些较长的问卷用于更详细的研究【Chin et al.1988]。通常是要求用户以 15 或 1-7 的 Likert 度量尺度语义差异尺度来给系统打分【Ialomia and Sidowski1990。对于 Likert 尺度来说,问卷上给出一些陈述句(如“我感到这个系统使用起来令人愉快”),然后要求用户指出他们同意或不同意的程度。在使用 15 分尺度的情况下,回答选项通常是 1=很不同意,2=部分不同意,3=既不同意也不反对,4=部分同意,5=非常同意。

    语义差异尺度则是列出两个在某种意义上相互对立的词语(如,很容易学会与很难学会),让用户把系统放在这个语义尺度上最合适的地方。表 3 和表 4 列出了度量主观满意度时经常用到的一些问题样本。可以增加几个关于某些特别感兴趣内容的问题,如“快速参考卡片很有帮助”,但一般最好使问卷简短,以保证最高的返回率。对主观满意度的最后评价,经常是从各个问题打分求出的平均值(在对所有使用相反方式的问题进行补偿之后),但也可能采用来自社会学和心理度量学评价尺度理论的更复杂的方法。

    表 3 使用 Likert 度量尺度来度量主观满意度时,可能向用户提的问题。通常用户会对每个陈述句,在 15 分的范围内给出他同意的程度。一般是通过系统的名字,而不是“这个系统”来称呼被评估的系统

    对于下面关于系统的陈述,请指出您同意或不同意的程度

    很容易学会怎样使用这个系统。

    使用这个系统是一段让人很沮丧的经历。”

    我感这个系统可以让我达到很高的生产效率。

    我担心我用这个系统所做的许多事情可能都是错的。

    “这个系统能够做我认为需要做的所有事情。”

    “使用这个系统工作让人感到愉快。”

    表 4 某些用来度量用户对计算机的主观满意度的语义差异尺度。参见 [coleman et al.1985] 提供的一个包含 17 个这种尺度的清单

    请在最能够体现您对这个系统印象的位置上做标记:

    愉快气恼

    完荐--- 不完善

    合作 -不合作

    简单 ー--·-复杂

    使用起来很快 ----使用起来很慢

    安全-- --不安全

    不论采用的是什么评价尺度,都应当进行试点测试(参见 6.1 节),以便保证用户会对问题做出正确的解释。例如,在一个用于销售点(point-of sales)系统的问卷中,有一个“是人性化接触(human contact)还是冷冰冰的技术”的度量尺度,用来评估由机器来提供销售服务是否让用户感到缺少人情味。然而,由于用户误认为 human contact 是指“人之间的接触”,而在他们使用系统时旁边没有其他人,许多用户认为在逻辑上谈不到“人之间的接触”“,所以,并没有按照所期望的方式来回答这个问题。

    当使用评价尺度时,在对结果进行评估之前,需要用一个锚点或基准来对尺度进行校准。如果有关于若干不同系统或同一系统的若干版本的主观满意度评价的话,可以相对于其他系统来考虑这次得到的评价,从而可以确定哪个系统使用起来最令人感到愉快。如果只对一个系统进行度量,那么在对评价做出解释时就应当谨慎,因为用户在回答问题时经常是比较客气的。用户通常知道,那些请他们进行评价的人,对于所度量的系统是有某种既定干系的,所以他们的回答会倾向于肯定,除非他们的确有不愉快的体验。这种现象可以通过对某些问题采用相反方式来提问,部分地加以抵消,这就是说,对某些问题的同意是对系统的负面评价

    Nielsen 和 Iewy 发现【199, 已发表的 127 个用户界面主观满意度评价的中值,在 15分的尺度上是 3.6 分,其中 1 最差,5 最好。从表面上看在 15 分尺度上,3 应当是中点,但由于中值的意思是说,一半的系统比该值好,一半的系统比该值差,所以 3.6 这个值似乎是对主观满意度“中点”或“平均值”的一种偏高的评价

    如果对若干个系统进行测试,可以通过询问用户倾向于哪个系统,或者他们在多大程度上倾向于哪个系统的办法,来度量主观满意度。另外,对于已运行的系统,可以度量用户选择使用各个系统的程度。表明用户自主使用情况的数据,的确是最权威的主观满意度评价。【对比物】

    2.3 实例:图标的可用性度量……

    Bewley 等人【1983] 介绍了一项经典的关于图标可用性的研究工作。为某个图形用户界面设计了四套不同的图标,每套 17 个。对每一个图标都测试了其易学习性、使用效率和主观满意度。对易学习性是通过若干种方法来评估的:首先,通过每次向用户展示一个图标,然后让用户描述“你认为这是什么意思?”的办法,测试每个图标的直觉性。其次,由于图标通常都不是孤立出现的,所以,通过向用户展示一整套图标(每次展示所设计的四套图标中的一套),来测试图标的可理解性。告诉用户一个图标的名字以及关于它是做什么的简短描述,让用户指出与之最匹配的图标。还给用户一整套图标名字,让用户把它们与所有图标相匹配。这些学习测试的得分就是被正确描述或命名的图标所占的比例。

    还进行过两个效率测试。在第一个测试中,对于通过参加学习测试已经知道图标含义的用户,给他们一个图标的名字,告诉他们它可能会出现在计算机屏幕上。然后随机地显示图标,如果是用户要寻找的图标,用户就按“是”键,如果是其他图标,就按“否”键。在第二个测试中,向用户同时显示随机分布的若干图标,让用户点击相应的那个。这两个测试都是计时的,图标的得分就是用户的反应时间(秒)。

    对于主观满意度是以两种方法来度量的。第一种方法是,让用户就图标是否容易识别,挨个给图标打分。第二种方法是,针对 17 个概念中的每个,给用户显示四个可能的图标,让用户选择他们倾向的那个。图标的主观满意度得分,就是用户在第一个测试中给该图标的打分,以及在第二个测试中选择该图标的用户比例。

    在所有这些测试结果的基础上,可以对四套图标进行比较。在图标中包含命令名字的那套图标,在要求用户描述图标表示什么意思的测试中总是得高分。这一结果并不出人意料,而且的确在后来关于其他界面的研究中也得到了证实【E gido and Patterson1988; Kacmar and Carey1991]。不过,这套图标从图形上来说不太显眼,在有很多类似图标的屏幕上,这种图标找起来比较困难。最后,又给系统设计了第五套图标,它们主要是基于前面四套图标中的一套,但根据前面测试的结果以及图形设计人员的审美考虑做了一些变化。

    代表物体的图标可能要比代表操作的图标更容易设计,因为许多物体可以象形表示。Rogers [1986] 对于因包含成分逐渐增多复杂程度相应递增的若干组操作图标进行了研究,以此来测试代表操作的图标的可用性。所测试的可用性参数为可理解性,这是通过匹配试验来进行的。对于图标的每个复杂度水平(如具有极少几个成分的图标),设计整组图标来表示系统的命令。对于这样的每一组图标,让 10 个用户阅读一组命令功能的文字描述同时向他们展示所有图标°。对于每个文字描述,让用户选择他们认为与之最匹配图标整组图标的可理解性得分就是正确匹配的图标个数。

    最好的图标可以既表现操作的具体对象如一张纸),又抽象地表现所进行的操作如一个箭头)。只包含一个这类成分的图标理解起来就会比较困难,同样,包含太多信息的图标(比如,不是用箭头,而是用带有卡通风格的运动方向线条的手指形状来表示)也会比较难理解。因此中等复杂程度的图标最容易理解。另外,有可视输出(如文字处理程序中正文的移动)的命令所对应的图标比较容易理解,而没有可视输出的命令(如“保存文件”)所对应的图标则要难理解得多。

    用于关键或广泛使用的应用程序的图标,可能比其他图标有更严格的质量要求。国际标准的确是一个需要具有高可用性的领域。Lindgaard 等人【1987] 报告了这样一个案例,国际标准化组织(ISO)要求图标必须在测试中能被至少 66%的测试对象正确解释,才能够被采纳为国际标准。在对具有技术知识的用户进行的测试中,所提出的图标只有一半通过了这个标准, 而在对不具有技术知识的用户进行的测试中,只有 1/12 的图标获得了通过反复设计会不断改进图标设计,但从这项研究中,我们得到的重要教训是应先确定用于可度量的可用性的合理标准,然后通过测试,在产品发布之前检验是否达到了预定目标。

    这一节的实例表明,图标的可用性可以通过多种不同方法来定义和度量。从实例中得到的主要结论是,需要根据每个项目的具体情况,对 2.2 节列出的基本可用性标准进行细化。有许多度量可用性的不同方法,没有哪种度量方法对所有项目都是最佳的。

    2.4 可用性权衡

    学习曲线....使得用户可以在开始阶段先学习使用容易学习的交互风格,后来再转向对于频繁操作更高效的风格

    实现这种“优势互补”效果的典型途径,就是在用户界面中包含加速键(accelerator)。所谓加速键是这样一种用户界面成分,它可以让用户更快捷地执行频繁的任务,尽管同样的任务也可以通过更一般的、也许较慢的方式来执行。加速键的典型例子包括功能键、命令名缩写以及通过双击来激活某个对象。5.7 节提供了更多的可以被熟练用户用来作为加速键的快捷对话方式的实例。

    【有可能是快捷键】

    在对于新手用户的可学习性与对于熟练用户的使用效率之间所做的权衡,有的时候不必使用双重交互风格,就可以得到同时有利于两种用户的解决办法。例如,在应用程序涉及的域不多的情况下,也许可以在对话框中使用描述性的域标识,尽管与使用难懂的缩写形式作为域标识相比,这样会使对话框大ー些。熟练用户不会因这种对新手用户的让步而受到什么损害°。.....

    在需要进行可用性权衡的时候,首先应当努力寻找能同时满足双方需要的双赢解决方案。如果不可能做到的话,应当按照项目的可用性目标(参见 4.3 节)所确定的方向,来解决这一两难局面,在项目的可用性目标中定义了在项目的具体情况下,哪一个可用性属性是最重要的。

    2.5 用户分类及用户个体差异……

    对可用性来说,两个最重要的问题就是用户的任务以及他们的个体特征和差异。我们对 92 个公开发表的关于超文本系统可用性的比较研究进行了分析,从中发现,在研究中 10 个影响最大的因素当中,有 4 个(包括影响最大的 3 个因素)是由于用户之间的个体差异,2 个是由于任务差异【Nielsen1989]。

    【用户任务,用户细分】

    【用户分类的方法】

    图 2-3 描述了“用户立方体”“,它由三个区分用户经验的主要方面(维)°构成:对于系统的经验,对于计算机的一般经验,以及对于任务领域的经验。

    尽管我们可以把用户简单地分为新手用户和熟练用户,但在现实生活中,不论怎样去使用一个系统,大多数人都不能对其所有方面都达到深入了解的程度。几乎所有有些复杂的系统都有很多功能和很多种用法,其实任何用户经常用到的都只是其中一个很小的子集【Draper1984]。这样一来,即使是“熟练”用户,对于系统中平日不经常用到的许多部分也会相当陌生。所以,对于界面中不经常使用的那些部分,熟练用户也需要使用帮助系统提高这些功能的可学习性将使他们从中受益

    用户对于计算机的一般经验也会影响用户界面设计。作为一个简单的例子,让我们来考虑一个供大型机系统管理员使用的实用程序,还有一个供家用计算机用户使用的实用程序。尽管两个实用程序的用途可能一样(比如磁盘碎片整理),但它们界面的差别会比较大。即使对于更面向应用的界面,那些使用过许多应用程序的用户,也会比只使用过一个应用程序的用户有更大的优势,因为有经验的用户会知道寻找什么功能,以及计算机通常是怎样处理各种情况的。例如,有电子数据表和数据库程序使用经验的用户,会试图在一个新的文字处理程序中寻找“排序”命令。另外,用户在程序设计方面的经验,会在很大程度上决定他们是否会使用宏语言和其他组合命令的复杂手段,以及他们所建立的结构在用户需求发生改变时是否容易维护和修改。

    最后一个重要方面是用户对系统所涉及的任务领域的知识水平。对于在相关领域具有广泛知识的用户,在界面上可以使用专用术语,屏幕设计中的信息密度也可以较高。领域知识比较有限的用户会需要系统解释它正在做什么,各个选项是什么意思,对他们不应当像对领域专家那样采用缩略术语和密集信息显示形式。

    用户在除了经验之外的其他方面也是不同的。某些差别因素是一目了然的,如年龄【Czja1988] 和性别【Fowler and Murray1987; Teasley et al.1994]。其他一些因素并不那么一目了然,如在空间记忆和推理能力上【Gomez et al.1986] 以及所喜欢的学习方式上【Sein and Bostrom1989] 的差别,有些人通过抽象概念学习得更好,而有些人则喜欢通过具体实例来学习

    除了用户类型之间的差异之外,在用户个体之间也存在重要差异【Egan 1988]。最极端的例子可能是在程序设计方面,最好和最差的程序员在生产效率上的差异通常可以高达 20 倍【Curtis1981]。这就是说,某个人用两周时间编写的一个程序,让另一个人来编写则可能需要一年时间,而且用两周时同编写的那个程序,很可能比用一年时间编写的那个程序的质量更好。人们在好几个研究中都发现了这个相同的结果。我们可以从中得到一个很有实际意义的启发,那就是改进软件项目的最重要途径就是雇用少而优的程序员。即使是对非程序设计任务,最好与最差的用户在绩效方面的差别,通常也在 410 倍之间。

    由于最好与最差用户之间的差异所反映的是极端的情况,而且取决于测试用户的数量,所以通常也采用四分比率法来表达个体差异的大小。所谓四分比率法就是把经排序的一组观察数据,如一组用户绩效数据,分成四等分Q3/Q1比率指的是最好的25%(顶部,第四个四分之一)°的用户比最差的 25%的(底部,第一个四分之一)用户更好的程度。Q3 表示这样一个绩效水平:25%的用户比它要好,而 75%的用户比它要差。与此类似,Q1 则表示这样一个绩效水平:25%的用户比它要差,而 75%的用户比它要好。例如,假定所度量的 8 个用户的效率分别是每分钟处理 2、3、3、4、4、5 6、9 个事务。由于有 8 个用户,所以最低的四分之一将以第二个最差的用户和第三个最差的用户之间为界,即 Q1 水平为 3。与此类似,最高的四分之一将以第二个最好的用户和第三个最好的用户之间为界, 相应的Q3水平 为5.5。于是,Q3/Q1之比为5.5/3=1.8。对于许多计算机任务来说,Q3/Q1之比大约为 2。

    【?Q值是如何确定下来的?】

    态度上的差别也会影响人使用计算机的方式。由于某些原因,有的人就是喜欢使用计算机,他们会尽其所能来学习掌握系统的各个方面。我曾经与个商务专业人员进行过访谈,她说她喜欢每个月学会掌握一个新的软件包,来获得保持先进的某种满足感,许多其他的“超级用户”也像黑客们那样,花大量时间来学习和研究他们计算机上那些难懂的细节,尽管他们是商务专业人员,而不是程序员【Nielsen et al.1986]。这种超级用户(也被称为高手用户”或“大师”)经常在普通用户和由信息管理部门或外部软件供应商引进的新计算机开发项目之间,起着一种纽带作用。超级用户作为技术能手不仅有助于新系统的引进,而且给普通用户提供了一种得到有同情心和针对任务的帮助的渠道【Gantt and Nardi1992; Nardi and Miller1991] l。由于超级用户一般喜欢交谈,所以在大多数普通用户明显意识到需要提出某些用户需求变更之前,软件开发人员就可以从超级用户那里获得这种反馈。不过需要记住,超级用户与大多数用户是不同的,所以不要完全按照他们的意愿来设计用户界面

    鉴于不同用户群体和不同用户个体之间存在的许多差异,有的人可能会想放弃努力,干脆让用户去定制他们的界面以适合他们的个体喜好。不过,正如我们在 1.3 节中“用户不是设计人员”标题下所讨论的那样,在那个方向上走得太远也是不行的。一般来说,只要在设计过程中能够关注所有有关的用户群体,就可以设计出能适合若干种用户的界面针对一种用户的需要对界面所做出的修改,可能给另一种用户造成严重障碍,或者造成不可能解决的困难,但这样的情况是很少见的

    2019-10-28 10:19:11 1人喜欢 1回应
  • 第75页 第三章至第四章
    • 第 3 章用户界面的分代…
      • 3.1 批处理系统…
      • 3.2 命令行界面…
      • 3.3 全屏幕界面……
        • 多层菜单
      • 3.4 图形用户界面
      • 3.5 下一代界面…
      • 3.6 可用性的长期趋势……
    • 第 4 章可用性工程生命周期
      • 4.1 了解用户……
        • 个体用户特征
        • 任务分析
        • 功能性分析
        • 用户的演变
      • 4.2 竞争性分析……
      • 4.3 确立目标
        • 经济影响分析
      • 4.4 并行设计
      • 4.5 参与型设计…
      • 4.6 整体界面的协调
      • 4.7 指南应用和经验性评估…
      • 4.8 原型……
        • 剧情
      • 4.9 界面评估……
        • 严重性评价
      • 4.10 反复设计…
        • 捕捉设计道理
      • 4.11 对已安装系统的跟踪研究
      • 4.12 元方法………
      • 4.13 可用性活动的优先顺序
      • 4.14 有所准备

    第 3 章用户界面的分代…

    3.1 批处理系统…

    参考affinity的宏命令。 batch。

    3.2 命令行界面…

    在分时系统的早期工作中起核心作用的 J. C. R. Licklider 还写了一篇非常有影响的论文“人机合作关系”(“Man Computer Symbiosis") [Licklider1960],这是一篇关于让计算机更接近地反映用户需要和能力的早期动员。

    分时计算机?

    3.3 全屏幕界面……

    多层菜单

    多层菜单的设计[Paap and Roske- Hofstrand1988]

    3.4 图形用户界面

    即使图形用户界面的历史可以追溯到 1962 年 Ivan Sutherland 提出的 Sketchpad 系统【Sutherland1963],1964 年 Douglas Engelbart 的鼠标【Engelbart 198】,以及从 20 世纪 70 年代开始的一些研究系统【Goldberg1988】,但是直到 20 世纪 80 年代才看到这些系统得到广泛的商业应用【Perry and Voelcker 1989]。大多数当前的图形用户界面有时候指的就是 WIMP 系统(窗口、图标、菜单和指点设备)。

    许多图形用户界面都可以说是面向对象的°。面向对象的界面与面向功能的界面大不相同,后者具有传统结构并通常基于字符界面。在面向功能的界面上,交互是围绕着一套命令来构成的,用户用各种命令的组合来实现期望的结果。主要的界面问题就是如何为访问这些命令及其参数提供一种轻松的方法,典型的解决方法就是具有各种缩写选项的命令行界面和全屏幕菜单

    有一个例子或许可以澄清面向功能和面向对象的界面之间的差异,并且表明为什么并非所有的图形用户界面都是面向对象的。让我们来看这样一个任务:从数据库中选择特定信息,将其格式化,然后打印出结果报告。由参与我们研究的人员所设计的面向功能的界面中,首先让用户在一个(图形的)对话框中指定查询的准则,然后从(图形的)下拉菜单中选择格式化选项,最后用户点击一个(图形的)打印按钮。只有在完成最后一步之后用户才能看到数据库中的实际数据。所有的这些操作步骤都是围绕着用户要完成的操作来展开的,而不是固绕着用户要处理的实际数据进行的。而在另外一种面向对象的设计中,开始时通过一个窗口向用户显示数据库中的样本记录。看到这种数据就能使用户更容易地记住数据库内容的性质,并能简化构造恰当查询的工作。随着用户对査询的修改,系统动态地更新数据窗口中的内容,显示出满足查询要求的记录样本。格式化操作可以通过修改窗口布局来进行,因而修改过后记录的格式是什么样子可以立即反馈出来。发出打印命令仍然是最后一步,由于它只是反映以数据为中心处理过程的结果,而且用户已经看到了每一步骤的反馈,因此输出的内容在用户的预料之中。

    大多数界面专家都以为图形用户界面通常要比基于字符的界面有更好的可用性,尤其是在新手用户的学习方面更是如此。尽管大家普遍这么认为,但尚没有很强有力的实验证据证明图形界面的优越性。

    图形用户界面是否更好,没有定论,但这个比较没有意义,因为如果图形用户界面没有设计好,可能抵消它潜在的优势。

    图形用户界面对残障人士的不友好:例如看不见图形,无法操作。

    3.5 下一代界面…

    时间(动画),声音,语音,VR。

    给用户界面增加维数的常用方法有增加时间(用动画的形式【Baecker et al.1991; Robertson et al.1993 声音【Gaver1989] 或者语音【Tucker and Jones1991】,以及用虚拟现实形式来增加一个真正的第三维空间【Biocca1992; Mercurio and Erickson1990 Pausch 1991; Rheingold 1991; Thomas and Stuart 1992 J.

    3.6 可用性的长期趋势……

    第 4 章可用性工程生命周期

    4.1 了解用户……

    当考虑用户的时候,我们应当牢记,除了坐在键盘前面的人之外,用户还包括安装人员、维护人员、系统管理人员以及其他支持人员。“用户”这个概念应当是指其工作以某种方式受到产品影响的所有人,包括系统最终产品或输出的用户,即使他们根本没有直接看到屏幕。

    接触用户方面的困难。

    开发企业需要防止顾客认识开发人员,因为顾客可能会绕过正常的技术支持渠道,而直接找到开发人员,从而使开发人员不能专心于自己的主要工作

    销售代表不愿意让公司内的其他人与“他们的”顾客接触,担心开发人员或可用性人员会冒犯顾客,或造成顾客对当前产品的不满。

    用户单位只允许与用户进行短暂接触,这或者是由于用户是高薪的行政人员,或者是由于用户受工会约束,不愿意作为别人的研究对象。

    唯一的建议就是应当直接接触用户代表,而不要满足于间接的接触和道听途说。

    个体用户特征

    了解用户的工作经历、教育程度、年岭、计算机使用经验等情况,可以在某种程度上预测他们在学习上会遇到的困难,从而对用户界面的复杂程度做出恰当的限制。我们的确还需要了解用户的阅读和语言技能水平。例如,很小的孩子没有阅读能力,所以适合给他们提供非文字的界面。我们还需要了解用户能够有多少时间用于学习系统的使用,以及是否有机会参加培训课程:如果希望用户在受到很有限的培训之后就可以使用,就应当使用户界面大大简化。

    我们还应当了解用户的工作环境和社会环境。有一个简单的例子,声音提示、“嘟”声或者更加复杂的声音效果,对于在开放式办公环境中的用户来说可能是不太合适的。在我曾经做过的一次现场访谈中,有一位秘书强烈不满,她需要能关闭“嘟”声提示的功能,因为她不想因为她的计算机总是响个不停,而让其他人觉得自己很笨。

    关于区别个体用户特征的大量信息可以来自于市场研究,或者来自于任务分析时可能进行的观察性研究,还可以通过问卷调查或访谈来直接搜集这种信息。在任何情况下,最好都不应当完全依赖于书面记载的信息,因为新的见解几乎总是来自于对实际工作环境中实际用户的观察和交谈

    任务分析

    任务分析[Diaper1989 a; Fath and Bias1992; Johnson1992] 是系统设计必需的早期输入。应当研究用户的最终目标,还要研究他们目前是怎样执行任务的,他们的信息需求,以及他们怎样处理异常或紧急情况

    应当识别用户的任务模型,因为可以利用它得到关于如何设计用户界面隐喻(Metaphor)的启发(参见 5.2 节)。而且,通过观察那些特别有效的用户以及他们的策略和工作环境,可以对于新系统应当提供的支持得到某些启示。这种“领先的用户”往往是创新设计的源泉【von Hippel1988]。最后还应当找出当前情况下存在的问题,即用户未能实现目标、花费过多时间或感到不舒服的那些地方。这些弱点为改进新产品提供了机会。

    当为了搜集有关任务的信息而对用户进行访谈时,应当总是让用户提供关于其工作产品的具体事例,而不是只在抽象层次上讨论问题。而且作为对访谈方法的补充,应当对一些用户实际工作的情况进行观察,因为在访谈中,用户常常把他们的行为合理化,或者遗忘重要的细节或例外情况

    任务分析经常可以按照层次结构进行分解【Greif1991】,.....通常,每当用户说“然后我做这件事情”时,进行访谈的人员可以问两个问题:“你为什么做这件事情?”(把这件事情与更大的目标联系起来),“你怎样做这件事情?”(把这件事情进一步分解为子任务,以便进一步的研究)。其他好的问题还有,“你为什么不这样或不那样做这件事情呢?”(提到做这件事情的一些不同的方法),“做这件事情时出过差错吗?你是怎样发现并纠正这些差错的?“”【Nielsen et al 1986]。

    最后,还应当让用户描述其正常工作过程中的例外情况。即使不能期望用户记住他们所遇到的所有例外情况,即使不可能预测今后会出现的所有例外情况,列出系统必须应付的例外情况的范围是很有价值的。还应当让用户谈一谈留下深刻印象的成功或失败的事例,存在的问题,他们最喜欢或最不喜欢什么东西,希望有什么改变,对改进有什么建议,以及目前有什么东西让他们感到烦恼。即使我们并不按照所有这些建议来进行最终的设计,他们也会给我们许多启示。

    功能性分析

    ......分析任务的底层功能上的原因:真正想要做的到底是什么,哪些是可以或应当改变的表面过程[Schmidt1988]

    让我们来看一个通俗的例子,对人们阅读技术手册的行为所进行的初步观察发现,他们通过频繁翻页来浏览整个手册。一个缺乏深思熟虑的联机文档手册设计方案,可能会根据这一观察结果而实现快速的翻页和滚动功能。然而,功能性分析会发现,手册的用户的确是通过频繁翻页来查找特定信息的,但要想准确找到想要的那一页却并不太容易。基于这一分析,我们可以设计这样一种联机文档界面:可以让用户首先给出他们的搜索需求,然后用手册的概要提纲来显示与搜索需求高度匹配的那些地方,最后可以让用户直接跳到这些地方去,并且将相应的搜索词突出显示,以便让用户可以更容易地判断这是否是想要的信息【Egan et al.1989]。

    [cinema4D,help documents.]

    当然,要想彻底改变用户执行任务的当前方式还是有困难的,因此功能性分析应当与任务分析相协调

    用户的演变

    用户并不是一成不变的。对于系统的使用会改变用户,随着这种改变,他们使用系统的方式会发生变化。Carroll 和 Rosson [1991] 将这一辨证的现象称为“任务与人造物的共同进化”。

    .....

    [你无法预测用户会怎样使用你的产品。]

    完全预测这些变化是不可能的,因为用户对计算机系统经过一段时间的使用之后,总是会发现新的使用方式,不过,采取灵活的设计方案将会有助于支持这些新使用方式。可以根据对有关其他用户过去如何发生演变的了解,来尽可能地对此做出自己的推测。4.11 节所讨论的系统部署后现场研究方法,是获得这种知识的一种途径。

    【快捷键】

    4.2 竞争性分析……

    ....现有产品或同类竞争产品,则常常是可以得到的我们自己产品的最好原型【Byme1989]。

    ......对他们各自的不同处理方法进行比较性分析。这将为新的设计方案提供启发,对那些似乎可行的和应当避免的做法,提供一系列具体的指导意见。另外,通过阅读媒体上的评论文章,可以得到关于可用性特征,以及大量同类竞争产品对此的不同处理方法的一些见解对于这种评述,应当辅之以对少数重要产品的较深人和有根有据的分析和测试。有的时候,竞争性分析还包括对非计算机界面的研究。例如,一个电子参考书开发项目,应当首先研究人是怎样使用传统纸媒体百科全书的【Marchionini1989]。

    4.3 确立目标

    ......根据对用户和任务的分析来明确他们的优先级

    可用性目标序列

    对于现有系统的新版本或在市场上有明确的竞争产品的系统来说,可用性目标的确立相当容易。最低可接受的可用性水平通常等于当前的可用性水平,而目标可用性水平可以确定为在此基础上某种程度的改进,其改进的程度应当足以吸引用户更换所使用的系统。

    而对于目前没有竞争产品的全新系统来说,可用性目标的确立就要困难得多。有一种办法是定义一组样本任务,然后请一些可用性专家来评估一下用户“应当”用多长时间完成这些任务。还可以通过询问用户来建立最低可接受的可用性目标水平,不过 用户在这方面却经常是没谱的: 有无数的项目最后失败了,原因是开发人员在需求方面相信了用户的说法,结果发现这样开发出来的产品在实际使用中无法令人满意。

    经济影响分析

    在确立可用性目标的同时,还应当对系统可用性的经济影响进行分析。

    【观察节省了多少钱?】

    这样的分析需要估算将使用系统的用户人数,他们的全额工资或其他成本,以及他们使用系统的大致时间量。用户时间的成本并不仅仅只是他们的薪洲,还应包括其他成本,诸如各种养老金和福利,政府征收的就业税费,以及办公室租金这样的日常开销。所有这些成本被称之为用户的全额工资或全额成本。

    对于供本企业内部使用而开发的软件,或者根据直接来自用户单位的合同而开发的软件来说,其经济影响分析是最容易做的,因为所得到的节省实际上是利润底线

    例如,让我们来考虑一个供 3000 名专业雇员用来处理某种服务订单的软件系统的开发。如果假定这些专业人员每小时的全额工资为 25 美元,而且假定他们每个工作日有三分之一的时间使用系统,我们马上就可以算出该用户界面每年的经济影响大约为 470000 美元°。

    而且,我们还可以假定,按照计划该系统将在两年之内引人,随后将使用四年,直到被新系统或重大的更新设计所取代。根据这样一些假设,在考虑到金钱的时间价值以及未来几年中花费的金钱每年会贬值 10%这样一种情况°,可以把这些年的经济影响累计为 12900000 美元。

    .....

    对于在开放市场上销售的软件来说,其用户方面的节省就不如开发组织方面的收益那样容易计算。

    因此经济影响分析应当包括两个部分:关于对开发组织影响的评估(有助于确定可用性预算的量级)和关于对用户组织影响的评估(有助于对可用的可用性资源进行优先排序)。

    对于开发组织的可用性方面经济影响的分析,应当包括对于收人减少或增加的估计,以及对顾客支持热线电话方面的开销这种成本的估计。

    然而,有关这两方面的数据通常被认为是高度机密的内部数据,因为用户界面现在是企业竞争优势的重要组成部分。

    以往一些传奇证据表明,某些开发商发现,如果产品的可用性水平低于一定标准的话,就不值得去卖它,因为人们能够预测到它将会在市场上失败。换句话来说,顾客可能会买这个产品,但随后就会需要厂商提供大量的技术支持服务,从而使得厂商在每件产品上都会赔钱

    ......

    一般来说,在许多公司,节省客服技术支持的需要是可用性工程的动力。根据行业简讯 Soft letter 在 1993 年对 148 家软件厂商开展的一项调查,每个顾客技术支持热线电话服务的全额成本的中值是 23.33 美元。

    作为针对顾客的用户界面的经济影响分析的例子,假定我们要开发个计划销售 100 万份拷贝的文字处理程序。预计大约有一半的用户从事的是秘书职业,他们每个工作日有将近一半时间需要使用文字处理程序,而另外一半用户是商务人员,他们每个工作日有约 10%的时间需要使用文字处理程序。此外,假定秘书每小时的全额工资为 20 美元,商务人员为 100 美元。这就是说,用户每年在使用该文字处理程序时所花费的金钱约为 19000000 美元(按照每天 8 小时、每年 236 个工作日来计算)。这实际上是可用性工程师在该文字处理程序用户界面上的工作所影响到的价值,尽管这一价值绝不会出现在开发组织的预算中。

    假定我们来考虑一下将该文字处理程序编辑功能的 效率提高 5% 所带来的收益。

    为了计算从这一改进中可以获得的节省,我们还需要进一步估计下,用户用于编辑功能的时间相对于仅用于文字输入的时间的比例。

    这一数据最好来自现场研究,或者来自对使用中的先前系统版本的日志记录数据。

    在这里,让我们假定秘书使用文字处理程序时,有 10%的时间在使用编辑功能,而商务人员有 25%的时间在使用编辑功能。这意味着,用户每年使用该文字处理程序编辑功能的时间总价值为 3300000000 美元,5%的节省将价值 16500000 美元。

    当然,该文字处理软件包的开发商并不能得到这笔钱,但给用户节省这笔钱还是有一些价值的。对于能够带来这种节省的可用性工作,比起那种只能给用户带来几百万美元节省的功能改进工作,在项目预算中所占的比例应当更大。

    ........

    4.4 并行设计

    几个不同的设计人员来进行初步设计【Nielsen et al.1993,1994]。

    并行设计的目的是在确定某个设计方案之前,先对几个不同的设计方案进行一番探索,然后再对所确定的设计方案做进一步的开发,开展更细致的可用性活动。图 4-2 是对并行设计和反复设计之间关系的概念描述。

    通常,可以由 34 设计人员来进行并行设计。

    ........在进行并行设计的时候,重要的一点是让设计人员(或设计团队)独立进行设计,因为其目标是为了产生尽可能大的多样性。因此,在产生各自的界面设计草案之前,设计人员之间不应当相互讨论他们的设计方案。

    [最后几个方案之间进行组合]

    ............

    并行设计的一种变形被称之为多样化并行设计Diversified Parallel Design),它是基于让不同的设计人员侧重于不同的设计问题

    例如,可以让个设计人员针对新手用户来设计一个界面,同时让另一个设计人员针对熟练用户来设计一个方案,再让第三个设计人员来探索设计一个完全无需语言的界面

    ........对于某些多样化的设计构思需要进行修改,才能用到一个统一和集成的设计方案中。

    对于那种创新型的系统来说,往往并不存在关于什么设计方法是最好的指导意见,在这种情况下,特别需要采用并行设计方法

    对于存在同类竞争产品的比较传统的系统来说,可以采取 4.2 节介绍的竞争性分析方法来作为初步的并行设计,但仍然应该让几个设计人员来建立其他的并行设计方案,以进一步探索未来可能的设计构思。

    乍一看,并行设计方法似乎与经济的可用性工程原理是相抵触的,因为大多数设计构思没有实现就被抛弃了。然而实际上,并行设计是一种探索设计空间的非常经济的方法,这正是由于对大多数设计构思都不需要费力去实现,而如果不这样做的话,其中的某些设计构思则要等到晚一些时候进行反复设计时才能去实现。对于并行设计方法来说,其经济上的主要好处来自于它的并行性,这使得我们可以同时对若干种设计构思进行探索,从而缩短了产品的开发周期,可以更快地将产品推向市场。研究表明,产品晚半年投放市场,就会损失大约三分之一的利润【House and Price1991, 因此,任何能够通过并行而非串行进行设计而加快开发过程的方法,其价值都应当超过其小小的额外成本。

    4.5 参与型设计…

    .........

    对于较大型的开发项目,应当注意定期更新参与项目的用户代表,因为存在这样一种风险,即随着参与系统开发的过程,他们会逐渐变得不具有普通用户的代表性。

    ........

    4.6 整体界面的协调

    一致性(Consistency)是最重要的可用性特征之一(参见 5.4 节)。.........

    ..........尽管对一致性的愿望是普遍存在的,但显然它并不是唯一想要的可用性特征,而且一致性有的时候还会与其他界面设计需求相冲突「Grudin1989]。因此,需要保持一定的灵活性,从而使得那种不好的设计方案,不会仅仅因为强调一致性而强加给用户。

    为了实现整体界面的一致性,每个开发项目都必须有一个唯一的权威,来对界面的各个方面进行协调。通常这种协调可以通过某个人来实现,但对于规模很大的项目或整个企业范围的一致性,则更适合采取成立一个委员会的方式。而且,界面标准是实现一致性的一种重要途径。除了这种通用的标准之外,项目还可以开发自己的专用标准,诸如建立一个相关术语词典,来规范所有屏幕设计以及整体界面的其他部分所使用的术语。

    ............

    4.7 指南应用和经验性评估…

    ..........

    在任何特定项目中,应当使用若干不同层次的指南:适用于所有用户界面的通用指南(General Guideline),针对所开发的系统类型的种类专用指南(Category Specific Guidelines)(例如,针对基于窗口的行政管理数据处理的指南,或者针对通过电话键盘使用的语音界面的指南),以及针对特定产品的产品专用指南(Product- Specific Guideline)。所有这些指南都可以用作经验性评估(Heuristic Evaluation)的依据。

    .........

    标准与指南之间的区别在于,标准描述界面呈现给用户的样子,而指南则对于界面的可用性特征提出建议

    目前,有一些内容十分广泛的通用用户界面指南,这包括,

    [Brown1988] 的 302 条指南

    [Marshall et al.1987] 的 162 条指南

    [Mayhew1992] 的 288 条指南

    [Smith and Mosier1986] 的 944 条指南

    .........

    4.8 原型……

    ..........

    减少功能数的办法被称为垂直原型(Vertical Prototyping),.........因此,垂直原型只能用来测试完整系统中有限的一部分,但却能用真实的用户任务在逼真的情况下进行有深度的测试。

    例如,在对可视图文系统进行的测试中,有深度的功能意味着,用户将可以真正地访问数据库中由信息提供商所提供的真实数据。

    降低功能水平的做法被称为水平原型(Horizontal Prototyping),.......... 在可视图文系统的例子中,这意味着用户可以执行所有的导航和搜索命令,但却不能通过执行这些命令得到任何真实的信息【Nielsen1987 a】。

    水平原型可以用来测试整个用户界面,当然这种测试的真实感要差一些,因为用户在一个不具有功能性的系统上,是不可能执行任何真实任务的。水平原型的主要优点在于,它们经常可以通过使用各种原型工具和屏幕设计工具来很快地实现,而且可以用来评估把界面各部分放在一起的整体效果

    我们还可以通过既减少功能数,又降低功能水平来实现剧情(Scenario 方法,它在测试用户遵循预定执行路径的情况下可以对用户界面进行模拟。剧情构造起来非常方便和经济,但真实感却不那么好

    除了减少系统中所实现的部分之外,可以通过下列办法来加快原型的实现

    不要追求原型的执行效率。例如,原型使用多大磁盘空间是无所谓的,因为它只使用很短的时间。.......

    不太可靠或质量较差的程序代码也可以凑合。尽管程序错误和死机在测试中的确会分散用户的注意力,但他们经常可以通过测试人员来弥补。

    采用简化的算法。这种算法不能处理所有的特殊情况(如闰年),而特殊情况通常需要在编程上有相当大的投入。

    通过人类专家的幕后操纵,来实现那些难以编程实现的计算机操作。根据这种“没想到幕后有人在操纵”的情景,这一方法经常被称为 神术(Wizard of Oz) 方法。........

    “听写打字机”【Gould et al.1983] 是一个著名的采用神术方法的研究案例,它是一个对语音识别界面的模拟,用户的语音输人被坐在另一个房间的人类打字员键入到一个文字处理程序中。.......

    使用不同于最终目标平台的计算机系统。在许多情况下,我们会有比最终目标平台更快或更先进的计算机,因此它可以支持更灵活的原型工具,不需要那么多的编程技能就可以实现必要的系统反应时间。

    采用低逼真度介质【Varzi1989】,虽然他们不如最终界面那么精细,但却仍然可以体现交互的基本性质

    例如,一个超媒体系统原型为了举例说明,可以用扫描的静态图像来代替实时视频画面。・

    采用模拟的数据和其他内容。例如,在一个需要大量使用视频数据的超媒体系统原型中,为了得到对处理实时图像所需交互技术的感觉,可以使用现有的视频素材,尽管他们与文字信息并不完全匹配。在广告行业也使用类似的技术,他们采用一种称之为 nematics 的做法,使用以前商业广告中的现成画面来做电视商业广告原型,用来在客户答应为新广告片的制作付款之前,向他们展示有关的创意。

    采用纸面原型,而不是可运行的计算机系统。......

    采用完全想像的原型,即实验人员向用户口头描述一个可能的界面,并且在用户一步步地执行任务实例的时候,提出一连串“如果(界面这样或那样),你将怎样…?”的问题。这种言语原型技术被人们称为“未来剧情模拟”【Cordingley1989】,与其说它是一种原型技术,还不如说它是一种访谈或自由讨论方法。

    /////////////

    显然,可以把若干种原型技术组合成为一种特别经济的原型;也可以把它们组合成几种不同的原型,每个原型分别对整个系统可用性的不同方面进行探索。

    ........

    有的时候,可以用原型来进行一种特殊的、称为交互原型(Interactive Prototyping)的参与型设计活动,也就是说,在用户指出原型所存在弱点的同时,对原型进行即时开发和修改如果有一位编程高手,又有灵活的界面构造系统工具,这种交互原型方法对于用户来说会是一种极好的体验,可以看到自己的设计建议马上得到实现。而且,由于可以在一次测试过程中对多种方案进行测试和修改,使得设计过程得以加快。

    然而,现实往往并不那么理想,因为再“神”的程序员在实际编程时也经常会出错。编程上的错误和系统存在的困难,会在测试过程中分散对用户任务和界面的注意力,而且那些弹出来供程序员进行即时编辑的大量额外窗口,也会让用户觉得受到冷落。这些问题可以通过用纸面原型进行交互原型设计,让用户来修改纸面原型的办法加以避免

    PICTTVE (Plastic Interface for Collaborative Technology Initiatives through Video Exploration)[Muller 1991, 1992 J 就是一种这样的技术,它把设计组合成可以用彩色笔修改的多层粘性纸签和透明胶片记录。最后得到的 PICTTVE 设计方案,可能就是一堆散乱的纸签和胶片,因此需要把设计过程拍摄成视频录像,以便把设计结果传达给负责实现的人员,这也就是该方法名字中最后两个字母缩写的含义。这种方法特别适于作为参与型设计过程的一部分而进行的原型设计活动,因为所用材料的低技术特性,使得用户和开发人员都很容易接受它们。

    原型是一种对设计规范的描述形式,它经常被用来作为一种把最终的设计方案传达给开发人员的主要方式。然而,原型可能会被过度限定在并非属于设计方案一部分的某些方面。当具体描述某个东西的时候,就可能需要把一些并没有明确设计的表示细节具体化。例如,屏幕设计肯定会用到确定的颜色和字体,即使设计人员所关注的可能只是对话元素所用的措辞和摆放位置。我们应当意识到,并不需要把原型中的所有方面都重现到最终系统中,而且设计人员应当告诉开发人员,原型的哪些方面是有意识设计的,哪些方面只是随意而为之。

    剧情

    剧情是最低限度的原型,因为它只描述了一个交互过程,没有给用户提供任何灵活性。因此,它兼有水平原型(用户无法与真实的数据进行交互)和垂直原型(用户无法在系统中自由移动)所具有的限制。

    ........

    剧情是对以下事物的一种笼统描述:

    用户个体

    对一组特定计算机功能的使用

    获取特定的结果

    在特定情况下

    经过特定的时间间隔(这不同于屏幕和菜单的简单静态集合:剧情明确包含关于什么时间发生了什么事情的时间因素)。

    这样一来,剧情就具有两种用途。

    首先,在用户界面设计过程中,可以把剧情作为关于用户最终如何与未来的系统进行交互的描述手段。

    其次,在用户界面设计的早期评估中,可以在不用建造可运行原型的情况下,通过剧情来获得用户反馈。

    例如,在设计阶段,可能有如下关于自动柜员机(ATM)使用过程的剧情:

    1) 用户走到机器前,插入银行卡。不论卡的哪一面朝上,机器都能正确读取。

    2) 机器请求用户输入四位个人身份号码,用户通过数字键盘输人该号码。

    3) 机器向用户显示包含四个选项的菜单:“支取 100 美元”、“支取其他数额现金”、“存入”和“其他交易”。在每个菜单选项旁都有一个相应的按钮。

    4) 用户按下对应于“支取 100 美元”的按钮,机器付出该数额的现金,并从用户的账户中扣除该数额。如果该用户的银行卡对应多个账户的话,则从余额最多的账户中扣除。

    5) 机器退出用户的银行卡。

    根据这一剧情,马上就可以对该机器用户界面的设计提出一些问题。例如,作为单键选项来说,100 美元是最合适的数额吗?在有若干种可能选择的情况下,应当用这种加速键来进行单键支取操作,还是应当总是让用户指定支取数额?如此等等。

    ..........

    如果剧情能够在纯粹叙述的基础上包含更多的细节,那么它还可以用来进行用户测试。在前面的例子中,可以制作包含按钮和菜单的 ATM 屏幕草图,把他们展示给用户,让他们“使用”这些屏幕去支取现金,在执行每个步骤之前,询问用户他们认为接下来将会发生什么事情。

    细致的剧情有时会以“日常生活”录像片的形式出现【Vertelney1989]。

    这些录像片表现了“用户”(演员)在日常的活动中与某个模拟系统交互的情景。因为交互是通过录像片来表现的,因此可以采用一切可能的特殊效果来制作模拟系统,并且可以让它看起来挺复杂【Dubberly and Mitsch1987]。这些录像片随后可以播放给用户看,例如,在焦点小组活动中用来启发讨论。

    4.9 界面评估……

    用户测试。.......

    Whitefield 等人【1991] 对评估方法提出了一种基于两种因素的分类方法:

    真正的用户是否参与以及界面是否已经实现。 ..........

    严重性评价

    .........

    通常,严重性评价是通过把界面上所发现的可用性问题清单发给一组可用性专家,让他们给每个问题的严重性打分来获得的

    .........

    然而,纯粹根据可用性专家的主观判断而做出的严重性评价是不太可靠的。人们对可用性的判断的确有较大差异。因此我建议,绝对不要依赖于任何一个可用性专家(尤其是你自己!)所做出的严重性评价,而应当综合若干独立评价者的意见即使只有 3-4 名评价者,其评价的平均值也要比他们其中任何一位的评价好得多

    在一项案例研究中,由一位可用性专家做出的严重性评价与真正的严重性之间的误差在+-0.5 以内(采用 5 分制)的概率只有 55%,而对于由 4 名独立的可用性专家所做评价的平均值来说,其概率为 95% [Nielsen1994 bJ。

    严重性评价常用的两种方法是,或者采用单一尺度,或者采用若干正交尺度的组合。用于可用性问题严重性评价的单一评价尺度可能是

    0=这根本不是个可用性问题

    1=只是一个表面的可用性问题一一除非项目有额外的时间,否则不必进行纠正

    2=轻微的可用性问题一一纠正这一问题的优先级较低

    3=重要可用性问题一一需要重视该问题的纠正,应当给以高优先级

    4=可用性灾难一一在产品发布之前必须予以纠正

    严重性还可以根据可用性问题最重要的两个因素来评价:预期有多少用户会遇到这个问题,以及这些用户受该问题影响的程度

    .......

    遇到问题的用户比例和问题对用户的影响程度这两个因素,都可以直接通过用户测试来进行度量。..........

    如果得不到用户测试数据,也可以由可用性专家对每个问题的频度和影响程度做出经验性的估计,但这种估计可能最好以少量的用户观察工作为基础。

    ..........

    4.10 反复设计…

    .......

    边做边说(Thinking Aloud).........

    .........

    正如该例所示,为解决特定可用性问题而进行的设计变更有时是会失败的。变更后的设计方案甚至可能会引人新的可用性问题【Bailey1993]。这从另ー个方面说明了,为什么要把反复设计与评估结合起来。实际上,每次重新设计往往侧重于改进某个可用性属性(如减少用户出错次数),但结果却发现,某些设计变更出人意料地影响了其他的可用性属性(如事务处理速度)。

    有的时候,解决某个问题,可能对于那些没有遇到该问题的用户来说,会使得界面更糟。这样一来,就需要对是否修改界面设计进行权衡分析(Trade- off Analysis),也就是说,有多少用户会遇到这个问题,又有多少用户会受到修改设计的不利影响,应当就此进行比较分析

    ..........

    经验性分析(Heuristic Analysis),展示给可用性专家和咨询专家,或者与专家用户进行讨论(或者在开发学习系统的情况下与教师进行讨论)。我们不应当对每个设计构思都进行彻底的用户测试,这对用户资源是一种“浪费”,因为测试用户通常不太容易找到,所以应当留给对主要设计版本的测试

    而且,随着用户对系统获得越来越多的经验,他们就逐渐变得不适于作为测试用户了,不能代表初次见到设计方案的那些新手用户。尤其不应当让那些参加了参与型设计活动的用户来担当测试用户,因为他们会具有倾向性。

    捕捉设计道理

    以把各种用户界面设计决定背后的道理加以明确的记载,以便于今后参考【Moran and Carroll 199]。

    .......

    [设计规范]

    在开发过程中,也可以在设计团队会议室墙上用低技术手段来记载设计道理。Karat 和 Bennett [1990,1991 b】就采用了这种技术,他们是在墙上贴纸签,把不同的墙面用于设计的不同方面。第一面墙放设计草图,第二面墙放设计的约東条件,第三面墙放剧情,第四面墙放有待解决的问题。其中的剧情是一些交互示例,描述了为获得特定结果所需执行的特定用户操作序列,侧重于描述用户会看到什么,用户必须知道什么,以及用户能做什么【Karat and Bennett199 la】。由于对设计问题经常难以抽象地理解,所以形象具体的剧情对设计道理是一种很好的补充。

    4.11 对已安装系统的跟踪研究

    ........

    有的时候,现场反馈搜集可以作为标准的市场研究工作的一部分而持续进行。......

    另外,还可以进行专门的研究来搜集有关已发布产品的使用信息。其他现场研究和任务分析所采用的方法同样可以用于这种场合,尤其是访谈、问卷和观察研究等方法。........

    除了由开发组织主动寻求用户反馈的现场研究之外,还可以通过比较被动的方法来获得此类信息,如分析用户的投诉、修改请求以及热线求助电话。......关于一般的可学习性问题的信息,可以从讲授系统使用培训课程的教师那里搜集到。

    ......

    4.12 元方法………

    ......

    对于使用方法时需要做什么写一个清晰的计划。.......

    用整个方法预算资源的 10%15%做一次试验性应用。然后用剩下 85%90%的预算对计划进行完善,克服那些在试验性应用中无法回避的困难

    ........

    4.13 可用性活动的优先顺序

    ......

    • 访问用户现场
    • 借助剧情来建立原型
    • 应用简化自言自语方法
    • 进行经验性评估

    打分

    ........

    4.14 有所准备

    尽管人们希望能够在整个软件生命周期中应用可用性工程方法,但在实际情况中,经常有一些误人歧途的项目或工期特别紧张的项目,需要人类因素学方面的紧急帮助。.....

    寻找一个好的用户界面原型工具,熟练掌其使用。........

    掌握正确的可用性检查(Usability Inspection)和经验性评估技术熟悉有关的界面标准和指南。采用这些方法只用几个小时就可以改进界面设计,但可能需要两周时间才能掌握某些方法【Jefries et al,1991]。

    了解与你的组织有关的典型用户类型、任务、应用程序和计算机平台。......

    为在需要时招聘测试用户而建立相应的流程。例如,与附近主要的顾客单位和当地的高等院校建立联系,与临时用工代理机构签订合同,或者建立感兴趣志愿人员的数据库(退休人员经常是获得富有领域知识的志愿人员的一个来源)。....

    在那些还没有专职可用性专业人员的每个项目团队中,物色和培训一名可用性的拥护者【Mravek and Rafeld199]。....

    阅读更多关于可用性的书和文章...参加会议。还可以尝试使用许多具有不同类型界面的系统,以获得关于不同交互风格的经验:许多好的设计构思来自于对其他界面怎样解决类似设计问题的了解。

    2019-06-28 00:06:11 1人喜欢 回应
  • 第104页 第五章
    • 第 5 章可用性经验准则…
      • 5.1 简洁而自然的对话…
        • 图形设计和颜色
        • 少即是多
      • 5.2 使用用户的语言
        • 映射和隐喻
      • 5.3 将用户的记忆负担减到最小……
      • 5.4 一致性……
      • 5.5 反馈
        • 响应时间
        • 系统错误
      • 5.6 清楚地标识退出
      • 5.7 快捷方式……
      • 5.8 好的出错信息
        • 多层次消息
      • 5.9 避免出错……
        • 避免使用模式
      • 5.10 帮助和文档…
        • 使用文档的一种模型
        • 最简化手册
      • 5.11 经验性评估
        • 评估者知识的影响

    第 5 章可用性经验准则…

    5.1 简洁而自然的对话…

    ........

    图形设计和颜色

    ......

    突出最重要的对话元素”...

    关于如何在界面设计中使用颜色【Rice1991; Travis1991】,有如下三个重要法则

    不要过度使用颜色。....颜色方案中的颜色数量最好不要超过 57 种,因为用户很难记忆和区分太多的颜色,经过专门训练的用户也只能对付大约 11 种颜色【Durrent and Tr ozona1982]。同时,浅灰色或一些柔和的颜色比一些鲜艳的颜色更适合于作为背景色。

    确保界面在不用颜色的情况下也可使用。.......

    颜色应当仅仅用于区分和强调的目的,而不要用于提供信息特别是提供量化信息

    某些颜色或某些颜色的组合会比其它的颜色或颜色组合更具有可视性【Durrett1987】,.....

    少即是多

    ......

    5.2 使用用户的语言

    .......

    要做到使用用户的语言,一个显而易见的想法就是去询问用户:他们喜欢在界面中使用哪些词汇或概念。但是,言语相左现象会使该方法行不通.日常使用中对同一种事物可以使用的词汇数目非常多,使得用户在被询问时给出最合适名称的概率非常低

    Pumas 等人【1987] 发现:两个用户选中同一个名称的可能性不会超过 7%18%,当然这与所命名的具体事物有关。即使通过询问多个用户来得出一个多数结果,也可能只符合 15%36%的用户。换句话说,大多数用户不会满意这个结果,即使词汇本来就是用户自己选出来的。

    一个更好的方法是让用户来对一个可能的名字清单进行投票这个清单可以通过几种不同的方式来产生,包括开发者的建议、可用性专业人员的建议、一些来自用户的建议。在一个实验【Bloom1987-88] 中,使用以下三种不同方式选择一个邮件合并工具的功能名称:

    由系统开发人员提出的技术词汇:变量字段、符号字符、记录、分隔符等。

    在给用户提供概念的简要描述的情况下,由大多数用户建议的词汇:如部件、标记、单位、逗号等等。

    让用户对一些同义词汇进行投票得出的词汇:部件、占位符、信息包、分隔器等等。

    用户投票选出的词汇不仅更贴切,它们在用户测试中的表现也更好

    数据表明,测试用户在学习采用技术词汇的原始系统时平均犯 11.1 个错误,当用户学习采用多数用户建议词汇的系统时平均犯 10.3 个错误,而当学习采用经投票产生词汇的系统时平均只犯 8.3 个错误。

    在第二个测试中,只对技术词汇和投票产生词汇进行了比较。用户在学习采用技术词汇的系统时平均犯 14.7 个错误,而与此相比,在学习采用投票产生词汇的系统时平均只犯 4.6 个错误。这证实了采用投票产生的词汇使得系统更容易掌握。

    但是在对已经学会使用系统的用户进行测试时发现,无论采用哪一类名字,错误率(2.0 个错误)都一样这表明用户最终都能基本学会

    最后让这些测试用户使用系统去完成另一组新的任务,并且不让他们查看手册。在这次转换测试中,使用技术词汇系统的用户平均犯 23.6 个错误,而使用投票产生词汇系统的用户平均犯 5.8 个错误。后面这次测试的结果表明,使用投票产生的词汇能让用户更好地理解系统,使他们能够根据使用系统的相关知识归纳总结出采用的新方式。

    由于同一个概念的表示方法非常之多,计算机应该允许在命令语言的解释和帮助索引中大量使用同义语。同时也应该让用户能够定义别名(可由系统翻译的用户自定义词汇)。别名不仅让定义别名的用户更容易记住,也可以为一些复杂操作提供快捷方式,例如带有多个参数的命令或电子邮件地址

    对于某些应用,例如,查询在线文档或数据库,一段时间后,系统本身通过使用自适应索引就可建立一个别名列表【Pumas1985】,每当用户尝试个系统尚不知道的查询关键词时,如果用户成功地找到了有关信息,就加人关于此对象的新名词。

    映射和隐喻

    .....

    世界地图的建立【Monmonier1991。地球是圆的,但遗憾的是地图是平的,这导致出现了多种地理变形方法,也就需要从中选择一种适合用户任务的映射方法。

    为了找到这样的映射方法,首先要进行任务分析,并理解用户以及用户的应用领域。除了观察用户并和他们交谈之外,也可能需要使用一些更复杂的方法来理解用户的知识表示和他们建模应用领域的方式

    通常,会要求用户列出一组与应用领域相关的概念,并且依据用户的应用领域模型进行排序和分组。其中一些常用的技术包括顺序回想(ordered recall)(让用户尽可能自由地联想他们所能想到的概念,其中运用的原则是一同提到的想法在用户的概念模型中是相关联的)。卡片分类(card sorting)(每个概念写在一张卡片上,让用户来将它们分类),相似性打分(paired similarity ratings)(给用户提供一个问卷,其中包括各种可能的成对概念,让用户给它们的相似性打分)[Mcdonald, Schvaneveldt1988]。

    这些测试结果可以直接拿来使用,也可以通过使用统计程序来用于多维度量或聚类分析。........

    用户界面隐喻【Carroll et al,.1988, Wozny1989] 可用来在计算机系统和用户理解的现实参照系统之间建立起一种对应。......

    但有时隐喻会误导用户,或者将用户对计算机的理解局限于从隐喻获得的知识【Halasz and Moran1982]。比如,将“字处理软件”比喻成“打字机会帮助用户发现回退和滚动这样的功能,但也可能会妨碍用户发现类似于全局替换这样的功能

    另一个例子是,在图形用户界面中经常把“删除文件”的操作用废物箱、碎纸机甚至是黑洞图标来表示。即使黑洞不是十分面向用户的,但这些图标都能唤起用户相关的非计算机的经验和知识,并成为“删除文件”这个概念的好隐喻。当我们考虑数据安全时就产生了一个新的问题。在目前大多数操作系统中,在删除文件时并不会真正将文件的内容从磁盘清除。通常删除文件的操作只是让文件占据的空间在以后可以被其他文件使用。这意味着只要没有其他文件覆盖被删除文件所占用的区域,就有可能读取被删除文件的内容。因此在磁盘上存有敏感数据的用户不能采取删除文件的方法来保护数据,以防止其他人通过访问磁盘来查看这些数据,例如计算机卖出后或维修时。而碎纸机图标会让用户在安全方面有一个错误的认识,因为实际的碎纸机是用来销毁机密文件材料的。与此相反,废物箱图标至少隐含表示其他人可能会查看丢弃的文档

    ......在使用简化的模型来隐喻表示系统的详细概念模型时应当小心仔细【Nielsen199】,而不要用隐喻来直接表示系统。

    隐喻在国际化领域也会带来一些潜在问题,因为不是任何隐喻都适用于所有文化。...........

    5.3 将用户的记忆负担减到最小……

    ........被动词汇量会远远大于主动词汇量......

    有一个著名的例子表明,度量单位可以帮助用户进行有效的记忆。在对发现号”宇宙飞船发射的一个太空镜进行定位操作时【Neumann1!991】,人们希望这个镜子瞄准山顶以反射激光束,而且用户已通过计算机命令镜子指向海拔高度为“10023”的点。用户认为显然要输入以英尺为单位的高度,但实际上系统是以英里为单位的,这就导致镜子瞄向的点远离地球,指向地球外 10000 英里远的一个点°。

    .....

    使用通用命令【Rosenberg and Moran1984].....通用命令在不同的情况下可完成类似的工作,....

    5.4 一致性……

    ......

    为了便于识别,同样的信息在所有屏幕和对话框中显示的位置和形式应当一样

    .........

    不仅要在屏幕设计中考虑一致性,在系统的任务和功能结构上也要考虑致性【Kelg1987,1989]。例如,Alberts 和 Mac Millan [1987] 发现,用户在采用命令行的 PC 机和采用命令行的大型机之间切换,要比在采用命令行的 PC 机和采用图形界面的 PC 机之间切换更困难。从屏幕设计的观点来看,两个命令行界面非常类似,但其底层的操作系统差别很大。而两个不同类型的 PC 界面是建立在具有同样原理和功能的系统之上的。

    .........即较大范围的不一致性问题最难解决。

    5.5 反馈

    ......

    系统反馈不应当使用抽象和通用的词汇,而是应该重述或改述用户的输入以提示现在正在干什么

    ........

    用户界面中不同种类的反馈应当具有不同的持续时间【Nielsen1987]

    有些反馈只在发生某种情况时才需要,持续时间很短,当不再需要时就消失。比如显示打印机缺纸的信息在问题解决后应该自动清除。

    有些反馈具有中等的持续时间,在用户做出明确响应之前会一直显示在屏幕上。比如,由于用户指定的打印机出了问题,用户的打印任务被重定向到其他打印机的信息就属于这一类。

    还有一类反馈信息由于非常重要,要求有最长的持续性,最后成为界面的一部分。比如,关于硬盘剩余空间的提示。

    响应时间

    如果系统所进行的操作需要很长的响应时间,反馈就变得很重要了。关于响应时间的基本建议多少年来都变化不大【Miller968; Card et al.1991]

    0.1 秒是让用户感觉到系统立即做出了响应的时间上限,此时除了显示结果外不需要其他反馈。

    1.0 秒是让用户思维不被中断的上限,但用户会感觉到延迟。通常不需要对 0.1 秒 1.0 秒的延迟专门给出反馈信息,但此时用户会失去对数据直接操作的感觉。

    10 秒是让用户注意力保持在对话过程中的上限。......

    对于一些快速操作,如花费 210 秒,就没有必要使用真正的进度指示器了,实际上这时如果使用就违背了惯性显示原则(即避免屏幕闪动太快,使得用户无法跟上或紧张)。此时可以提供不太显眼的进度反馈。常见方法是使用“系统忙”的光标,同时在屏幕底部的一个小地方显示一个快速变化的数字来指示当前有多少已经完成。

    系统错误

    系统出错时应当给出信息反馈。但许多系统不是这么设计的,它们在出现问题时只是简单地停止响应用户。然而,无反馈信息是一种最差的反馈,因为此时用户只能去猜测发生了什么问题。系统应当设计成能够给用户提供友好的出错信息,即使在非常严重的崩溃情况下也应当为用户提供某些反馈信息。

    .........

    5.6 清楚地标识退出

    .......

    5.7 快捷方式……

    .........

    应当允许用户在大的信息空间,如文件或层次菜单中,能够立即跳转到想去的位置。通常,可以采用一种类似于超文本的方法【Nielson1990 a】来链接可能一起使用的信息元素。在文件系统中,这种链接通常被称为别名,因为此时无须定义完整路径,就可以指定信息对象(文件)。

    另外,可以为常用位置定义容易记的名字,方便用户以后的键入。......

    应当允许用户重用他们以前的交互输入【Greenberg1993]。对命令行系统的研究表明,35%的命令在前 5 个命令之中曾经出现过,74%的命令是以前至少使用过一次的【Greenberg, Whitten1989。

    利用用户交互历史来提供快捷访问的一个简单例子是,一些程序会记录用户经常打开的文件【Barratt1991]。这些程序可以为用户提供一个特殊的文件菜单,列出下一步最有可能打开的文件,这些文件或者是由于它们最近被使用过,或者是由于总的看来它们经常被使用,或者是由于它们和当前打开的文件经常在特定任务中一起使用。

    [finder 的最近使用文件夹]

    系统提供默认值也是一种快捷方式,.........

    5.8 好的出错信息

    ........

    出错信息应当遵循以下四个简单原则【Shneiderman1982]

    出错信息应当用清晰的语言来表达,而不要使用难懂的代码。......

    出错信息使用的语言应当精练准确,而不是空泛而模糊的。......

    出错信息应当对用户解决问题提供建设性帮助。.......

    出错信息应当友好,不要威胁或责备用户。.......

    多层次消息

    ......

    多层次信息通常包含两层,在初始的简短消息中点击一个按钮可以获得更多的信息。.......

    5.9 避免出错……

    .........

    根据错误的频率或严重程度,可以针对某些用户错误重新设计系统来消除这些错误。.......

    避免使用模式

    模式【Monk1986] 经常导致用户出错,使用户感到挫折,应当尽可能加以避免。

    早期的文本编辑器就是一个典型的使用模式的例子,其中有两个完全独立的模式;编辑模式和插人入模式。当用户处于插入模式时,所有的键盘输入都被解释为插入的文字。当用户处于编辑模式时,所有的键盘输人都被解释为命令。在现代的文字处理软件中也有一个这样的例子,就是注释的使用,注释有时侯可见,有时候隐藏。在不同模式下用户可以使用的操作是不同的,不是所有的操作在所有的时候都可用,这会导致用户产生困惑。......

    然而,在一些较为复杂的界面中完全不使用模式是不太可能的

    例如,多数字处理软件都有一个文字自动换行功能,它使文字自动折到下一行,而不会进人页边距外的区域。事实上,该功能在界面中引人了模式,因为同样的动作(输入)可能会也可能不会产生ー一个新行,取决于是否处于“已到行尾”模式。

    通常这种模式不会影响用户的使用,因为用户不在意他们的输入是否被分成多行。但当用户在意时,这种模式就会带来问题【Monk1986],比如建立一个表格时。如果无法完全避免使用模式,设计人员通过在界面设计中清楚标识模式,至少可以避免很多因模式而带来的错误。

    设计人员可以遵循反馈原则,为用户显示各种清楚、明显的状态,让用户清楚地了解当前的模式。在一个实验中发现,给一个计算机游戏的不同模式配上不同的声音效果,可以减少 70%与模式有关的错误【Monk1986]。如果不适合使用音效,可以使用其他方式提供模式反馈信息,如不同颜色的窗口。........

    .........在“弹簧模式”中,只有当用户按住某个键或进行类似操作时オ会进入模式,只要用户松开键就会自动离开模式【Sellen et al.1990]。

    .........

    5.10 帮助和文档…

    尽管我们希望让系统能够在没有帮助和文档的情况下就易于使用。但这个目标很难完全达到。除了像 ATM 机这样的系统要求必须具有“走来即用”walk-up-and-use)的可用性外,多数具有很多功能的系统需要用户手册或帮助系统。.......

    一个基本事实是,大部分用户根本不阅读手册【Rettig199】, 用户更愿意把时间花费在他们认为更有成果的活动上【Carroll and Rosson1987】,........只有当用户碰到不可解决的麻烦,并且需要获得立即帮助时才会想起査阅手册。........现在除了纸面手册外,往往还提供在线帮助和在线文档。......

    关于在线帮助和文档有一个重要的原则要记住,即它们都是对系统功能的额外补充,它们的存在使原有界面变得更复杂了。.........这证实了帮助本身也是一个有其自身可用性问题的系统。.......

    与纸面文档相比,在线帮助还有一个好处就是上下文相关。.....

    当然,无论帮助文档采用在线形式还是纸面形式,写作质量都非常重要,其中包括信息的组织方式以及文字的可读性【Klare1984]。在对在线文档进行的一个深入研究中发现,“与选择何种机制来访问帮助文档相比,文档的写作质量更为重要”【Borenstein1985]。......

    用户通常不去阅读手册的第二个原因是:当他们想要查阅手册时,却找不到。.......

    .......手册往往被放在一些奇怪的地方!.........用户往往习惯站着使用手册,拿着手册到处走动以及同时使用多个手册。

    使用文档的一种模型

    用户使用手册和帮助系统的交互过程可以分为 3 个阶段【Wright1983】,

    1. 查找:找到需要的信息
    2. 理解:找到的信息
    3. 应用:根据文档描述的步骤来执行。

    信息空间结构的索引和信息纵览图是两种主要的搜索工具。书本中的纵览图通常使用目录形式,但有时使用表格形式也很有效。索引非常有用,我们不需要对它加以强调,但很多手册依然缺少索引。.......

    为了帮助用户在找到信息后理解信息,应当避免使用行话,而且要以用户执行任务的顺序和方式来书写。.........

    ........。最好让用户能够一边参照指令一边执行,而不用去记忆,.......

    根据用户使用文档的各种方式,可能需要最多三种层次的文档:

    简短的参考卡片和/或任务帮助......

    针对初学者的辅导和/或人门手册

    针对熟练用户的传统参考手册。

    对于包含多个部分的文档,有必要让每种手册尽可能自成体系。........

    最简化手册

    .........

    5.11 经验性评估

    .......

    其他可用性检查方法还包括认知步进评审cognitive walkthroughs) [Lewis et al.1990; Wharton et al.1982] 和诉求分析(claims analysis) [Carroll 1990; Carroll et a.199 Klg199]。、

    在经验性评估过程中,通常让一小组评估人员来检查界面,并判断界面与已知可用性准则(经验)的符合程度。......

    从原则上说,单个评估人员可以独立对用户界面进行经验性评估,但从一些实际项目的经验中得出这样一个结论:单个评估人员会漏掉界面中的大部分可用性问题。.......

    每个评估者对界面进行独立评估。只有当所有人都完成评估后,才允许他们相互交流并综合他们的发现。......

    单个评估者在经验性评估中花费的时间通常是 1 到 2 个小时。对包含大量对话元素的较大型或复杂界面进行评估可能需要更长的时间,这时最好将其分为几个小的评估过程,分别针对界面的不同部分。

    使用经验性评估方法获得的结果是关于界面的一个可用性问题清单,其中每一个问题都包含有评估者认为系统设计所违背可用性原则的注释信息经验性评估不会提供可以修正可用性问题的系统化方法,也无法估计重新设计后可能达到的质量。但由于经验性评估的目标在于,参照已有的可用性准则来解释每一个观察到的可用性问题,因此通常可以相当容易地根据所违反的可用性准则来形成改进设计。许多可用性问题在发现它们时就可以很容易地予以改正。

    .......

    评估者知识的影响

    象计算机相关的其他领域一样,在经验性评估中,需要考虑评估者个体差异的影响。在对8个案例进行研究后发现,Q3/Q1比值(即发现问题最多的1/4的评估者所发现的问题数比上发现问题最少的1/4的评估者所发现的问题数)处于 1.42.2 之间,平均值为 1.7。这些数据代表的案例中,评估者具有基本相同的背景和资历。因此,如果能确认哪些评估者擅长进行经验性评估会很有帮助。在一个案例研究【Nielsen and Molich1990 中,34 个具有同样背景的评估者评估了两个不同的用户界面,单个评估者在两个界面中发现可用性问题数的相关性 r=0.57。这表明评估者发现问题的能力不是随机的(p <0.01),但同时也表明,对于不同的评估,评估者的评估效果具有许多不可解释的不确定性。尽管我们可以通过长期实践,通过选拔一些在几个评估过程中都有好的表现的评估人员来形成一支“好”的评估队伍,但是这一过程会比较缓慢,也会降低前几次评估的成效。

    在一个案例研究中【Nielsen1992 c】,让三组评估者对同一个界面进行可用性评估:“可用性新手”具有一些计算机知识但没有可用性方面的知识;“单项专家”是可用性专业人员,但不是界面应用领域方面的专家;“双料专家”同时具有可用性专业知识以及相关界面领域知识°。

    新手评估者在评估中的表现非常差,他们平均找到 22%的可用性问题。单项专家找到 41%的问题,是新手的 1.8 倍,双料专家找到 60%的问题,是新手的 2.7 倍、单项专家的 1.5 倍。

    结果表明,除了个体差异外,不同组之间的表现存在着系统性的差异。尽管进行经验性评估的人员,可以只具有少量甚至不具有可用性专业知识(从简化可用性工程的观点来看,这是一个优点),但应该尽量让可用性专业人员作为评估者,如果使用双料专家则会获得最佳的结果。

    如果无法找到足够多的可用性专业人员,可以考虑让撰写技术文档和帮助文档的专家来参加经验性评估他们因为工作的需要必须理解系统,并且知道什么地方解释起来有困难(或使用起来比较困难)。

    另一种利用不同技能的方法是协作式可用性步进评审方法【Bias199】,参加经验性评估的人员包括用户代表、产品开发人员以及可用性专家。用户将他们的领域知识带入评估过程,在仅有“单项”可用性专家(这些专家不具备应用领域的知识)的时候,这种变形的经验性评估方法特别合适。

    Ran- dolph Bias [1991] 提倡在小组讨论前,让每个评估者单独进行初步评估。而在传统方法中,在讨论之前每个评估者都独立完成整个界面的评估,Ran dolph Bias 提倡一次只评估一个屏幕的设计,随后让整个评估小组对该屏幕设计进行讨论,然后评估者再评估下一个屏幕。很明显,这种技术非常适合于对传统的基于字符的全屏幕界面进行评估。这些界面明显地按子任务划分成一些单独的屏幕,许多图形界面也有一些单独的对话框,可以对它们进行分步检査。为了不让计算机专家主导小组的讨论,Bias 建议让用户先提交评估结果。

    协作式步进评审的好处在于,用户、设计人员同时参与,可以在设计的早期阶段获得用户的信息。在这一阶段,手册、帮助系统或其他文档还不存在,此时用户可能很难在没有帮助的情况下使用系统。在协作式步进评审中,系统设计人员可以作为“活的手册“,让用户问那些他们通常会到手册中查找答案的问题。

    2019-06-28 14:38:28 1人喜欢 回应
  • 第131页 第六章
    • 第 6 章可用性测试…
      • 6.1 测试目标和测试计划…
        • 测试计划
        • 测试预算
        • 试点测试
      • 6.2 招募测试用户………
        • 新手用户还是熟练用户
        • 用户间还是用户内测试
      • 6.3 选择实验人员……………
      • 6.4 用人来进行测试的伦理问题…
      • 6.5 测试任务
      • 6.6 测试的各个阶段
        • 准备
        • 介绍
        • 测试
        • 事后交流
      • 6.7 绩效度量方法…
      • 6.8 边做边说法
        • 协同交互方法
        • 回顾式测试
        • 辅导方法
      • 6.9 可用性实验室
        • 需不需要录像
        • 没有摄像机的录像
        • 便携式可用性实验室
        • 可用性信息亭

    第 6 章可用性测试…

    可靠性

    由于测试用户之间存在着巨大的个体差异,因此可用性测试的可靠性是一个让人为难的问题。最快的用户速度是最慢的用户速度 10 倍的情况并不罕见,并且通常的情形是,最熟练的 25%的用户执行任务的操作速度大约是最慢的25%的用户的两倍【Egan1988]。......

    不管怎样,研究结果显示,出错率的变化性是最大的,这意味着它需要更多的测试用户,才能达到某个置信度,而对于同样的置信度,对于可学习性的测量用较少的用户就能得到,而对于熟练用户的绩效情况的测量甚至用更少的用户就能得到。.......

    [缺少统计基础知识,关于统计数据的解读。]

    有效性

    有效性指的是可用性测试是否真的测量了与实际产品在实验室外的实际使用相关的某些可用性指标。......

    典型的有效性问题包括选择了不适当的用户,或者给出了不当的用户测试任务,或者没有考虑时间约束和社会因素的影响。...........

    6.1 测试目标和测试计划…

    在进行任何测试之前,都应该首先搞清楚测试的目的,因为它对要进行的测试有重要的影响。主要差异在于,测试是想对用户界面进行形成性评估(formative evaluation))还是总结性评估(summative evaluation)

    形成性评估是反复设计过程的一部分,目的是为了改进界面设计。.......形成性评估使用的典型方法就是边做边说式(thinking-aloud)测试

    与此相反,总结性评估的目的在于评定界面的整体质量,例如可以用它在两个备选方案中进行选择,或者作为竞争性分析的一种手段,来了解竞争对手的产品设计好在哪里。典型的总结性评估方法就是度量型测试

    测试计划

    应该在测试开始之前写好测试计划,并且在计划中要说明下列问题:

    测试的目标:想达到什么目的?

    测试在什么地方和什么时候

    进行每一次测试预期用多少时间?

    测试需要什么样的计算机设备?

    测试之前要准备好什么软件?

    开始测试时系统要处于什么状态?

    系统或者网络负载和响应时间应该是多少?.........

    谁担任测试人员?

    谁是测试用户,怎么找到这些用户?・

    需要多少测试用户?

    让用户完成哪些测试任务?

    用什么标准来确定用户已经正确地完成了每一项测试任务?

    测试用户可以使用什么辅助手段(手册、在线帮助等等)?

    测试人员在测试期间可以给测试用户提供何种程度的帮助?

    要收集什么数据,以及在数据收集之后怎么对其进行分析?

    判断界面是否成功的标准是什么?

    .......

    测试预算

    ........

    标准的用户测试成本预算有以下几部分:

    可用性专家设计、实施和分析测试的工作:如果聘请了咨询专家还要直接向他们付费

    管理助手安排测试用户时间表和录人数据等工作

    软件开发人员为加入数据收集功能或满足其他测试要求所做的代码修改工作

    测试用户的时间:如果招募了外面的人员来测试,就要直接支付费用

    在测试和分析期间使用的计算机

    可用性实验室或者其他用于测试的房间

    录像带和其他消耗品:直接购买

    付给各种工作人员的费用应该根据他们的全额薪水而不是他们的名义工资来估算。全额工资就是公司雇用一个人的总体费用,包括福利、休假报洲、就业税费以及企业的一般开销。

    测试预算应该分成固定费用和可变费用。固定费用就是计划和组织测试所需的花费,而不考虑测试用户的多少,可变费用就是付给每一位测试用户的那些额外费用。用这种方式把费用估算分开可以更好地为每一次测试所需的测试用户数量做出计划。........

    根据若干个已经公布的预算,可以得出一个有代表性的中等规模的可用性测试费用估算,其固定费用为 3000 美元、可变费用为每位测试用户 1000 美元【Nielsen and Landauer1993]。需要注意的是,任何一个具体项目的预算都有可能与此不同。

    .........

    Nielsen 和 Landauer [1993] 给出了以下的公式,它可以对发现可用性问题做出很好的估算:

    这里 i 是测试用户的数量,N 是界面上可用性问题的总数,𝛌为任一个测试用户找到任一个问题的概率。N 和𝛌的值在各个项目中的变化相当大,应该用根据每个项目已有数据所做的曲线来估计。当然我们也建议,应当在自己的项目中留意搜集这些数据,这样就能估计出这些参数的“常规”值,以用于为将来的测试做计划。

    ........

    试点测试

    【在正式开始可用性测试之前,进行一到两次的测试。自己做,或者同事做。】

    .......

    在试点测试过程中,人们一般都会发现某些让用户难以理解的测试任务说明,或者引起他们误解的地方。.......

    试点测试还能用来完善测试过程,以及清楚地对拟测量的各种事物进行定义。..........

    6.2 招募测试用户………

    .......

    所选测试用户越能代表预期使用系统的用户越好。........

    ......一个例外情况就是用销售人员来进行测试。

    对于许多产品来说,销售人员的任务就是给可能的顾客进行示范,他们能否熟练地演示可能会成为产品的一个主要卖点。......尽管大多数可用性方面工作的目的都应该是使系统让用户更容易使用,如果把“可演示性”也当作可用性的一个方面来考虑的话,销售可能会有显著的增长。

    ....

    新手用户还是熟练用户

    用户类型的一种主要区分方法就是把他们划分成新手用户和熟练用户(参见 2.5 节,用户的分类和个体差异)。几乎所有的用户界面都需要用新手用户进行测试,当然许多系统也应该用熟练用户进行测试。.....

    用户间还是用户内测试

    可用性测试常常用于比较两个或多个系统的可用性。如果是这样,那么就有两种基本的方法来选择测试用户:即**用户间测试(between- subject testing)和用户内测试(within-subject testing) **

    从某种程度上来说,用户间测试是最简单和最有效的方法,因为它在不同的系统测试中使用了不同的测试用户。因而每一个测试用户只参与一个测试过程。对于用户间测试设计来说,主要问题是本章开头所提到的用户技能存在巨大的个体差异。因此就需要为每一种不同的测试条件准备数量众多的测试用户,以便抵消各组测试用户之间的随机差异。

    由于把测试用户分配到各个小组中,用户间测试的结果可能会有一定的偏向。....

    有两种更可靠的分配测试用户的方法:最简单和最好的就是随机分配,它能把任何可能的偏向都减少到最小,但是因为测试用户的个体差异,这种方法需要大量的用户

    第二种方法就是进行分配,使各组用户中测试所要求的各类用户人数相等。例如,可以考虑按照不同的部门把用户分类,也可以按年龄长幼分类,按男女分类,或者也可以按计算机使用经验和教育背景来分类。

    另外,还可以进行用户内测试,就是说让所有测试用户来使用所有被测试的系统。这种方式能自动抵消个体差异,因为操作特别快或特别优秀的用户差不多在每个测试条件下都会很出色。用户内测试也有一个主要的不利之处,那就是测试用户在学过使用第一系统之后,再去使用其他系统时,就无法把他们算做新手了。多个系统之间通常会有一些通用的技能,因此用户在使用第二个系统时都会比第一个系统用得好。为了控制这种影响的存在,通常的做法是把用户分成小组,让一组人先使用一个系统,另一组人先使用另一系统。....

    6.3 选择实验人员……………

    ....最好是选择那种以前曾经使用过所选测试方法的有经验的实验人员。....

    除了具备测试方法方面的知识之外,实验人员还必须具备大量有关应用程序及其用户界面方面的知识。....

    让实验人员具备丰富系统知识的一种方法是让系统设计人员自己来担当评估人员【Wright and Monk1991]。....不过,让设计人员亲自对自己设计的软件进行测试也会带来一些问题,很可能会由于他们给予用户太多的帮助而使测试缺乏客观性。一个常见的缺陷就是设计人员总想去给用户解释以开脱问题,而不愿意承认这是实际存在的问题。为了避免这种情况,开发人员可以作为可用性测试队伍中的一员,但让可用性专业人员去和用户进行交流【Ehrlich et al. 1994]。

    6.4 用人来进行测试的伦理问题…

    ..... 但与此相反,高级管理人员和非常专业的人员常常特别在乎不要在测试中表现得无知。因此实验人员应该特别小心地尊重这些用户所具有的专业技能,并强调在测试中需要这些用户的专门知识。

    实验人员应尽量让用户在测试过程中和测试之后感到舒适。特别是,实验人员不能取笑用户,也不能用任何方式表示用户在找到如何操作系统的过程很慢。....

    应该告诉用户,不会公开用户的任何个人绩效信息,特别是不会向他们的经理透露有关他们的表现。.....

    测试之后,应该就有关问题对用户进行询问,听听他们对系统的意见。在完成调查问卷(如果采用的话)以后,在实验中采用的任何“伎俩”都要向用户公开,以免让用户带着对系统的误解离开测试。

    一个应该告诉用户的伪装技术的例子就是神术(Wizard of Oz) 方法(见 4.8 节),它用来模拟计算机并不具有的能力。....实验人员最后应当对用户参与测试表示谢意,还应当明确告诉用户他们帮助找出了产品需要改进的一些地方。用户可能觉得他们在测试时犯了许多错误,这样的交流可以帮助用户恢复自尊心。.....

    6.5 测试任务

    选择测试任务的基本原则就是所选择的测试任务要尽可能地代表系统的最终使用。另外,测试任务应该大致覆盖用户界面上最重要的那些部分。测试任务的设计可以基于任务分析或者基于产品用途说明来自于在运行系统中日志记录的关于频繁使用命令的信息,以及其他了解用户实际使用系统的方法,如现场观察等,都能用于为测试类似系统构造一组有代表性的测试任务【Gaylin1986]。

    应当把任务设计得比较小,这样就能在有限的测试时间内完成,但是任务也不能小到微不足道的程度测试任务应该详细精确地说明用户执行后产生什么结果,......

    测试任务不要轻佻、滑稽或者有冒犯,例如在测试一个绘画程序时,让用户在总统的扫描照片上画上小胡子的做法是不妥的首先,不能保证同样的事情在所有人看来都很好笑,其次,这种不严肃的任务会让系统的测试受到干扰,甚至有可能贬低用户的身份。相反,所有的测试任务都应该是面向业务处理的(当然,如果是测试娱乐软件之类的产品除外),并且尽可能逼真

    为了增加用户对任务的理解和真正使用软件的感觉,任务可以与整体剧情相关联例如,对于上面提到的电子表格的例子来说,可以假设用户刚刚被聘为公司的销售经理,并要求他在第二天做一个报告。

    ......

    6.6 测试的各个阶段

    可用性测试通常分成四个阶段 1) 准备 2) 介绍 3) 测试 4) 事后交流

    准备

    ....

    介绍

    .....

    在进行测试介绍时通常要包括以下要素:

    测试的目的是对软件进行评价,而不是对用户个人进行测试。....

    提醒用户对所测试的系统要保密,不要与别人讨论有关的内容。即使系统不是保密的,也最好要求用户保持沉默,不要与后面可能参加测试的同事讨论,免得他们有什么先入为主的印象。

    说明参与测试是自愿的,用户可以随时停止测试。

    让用户放心,对测试的结果会保密,并且不会以可区分出单个测试用户的方式向任何人展示。

    对于使用的任何录音录像设备都要向用户进行解释。不管是什么情况,录像时都不应该摄入用户的面部,只能有屏幕、键盘和用户的背影,明确说明这一点以减轻用户对录像的优虑。

    向用户说明欢迎他们提问,因为想知道他们在界面上有什么地方不清楚,但是实验人员在测试时一般不能回答用户的提问,因为测试的目的就是看用户在没有帮助的情况下能否使用系统。

    关于实验的任何特殊要求,诸如边做实验边大声说出感受,或者在保证出错最少的同时尽快操作等。

    在实验开始之前请用户提出需要澄清的任何问题。

    在许多测试中让测试用户签署一份知情表格,在表格中重申最重要的说明和实验条件,并声明用户对此已经知情。我不喜欢这种表格,因为它们会增加用户的顾虑,使测试看起来似乎有什么不样之兆,而实际并非如此。有时签署这种知情表格是出于法律上的考虑,因为把录像带或其他记录或测试结果向其他人展示时确实需要用到知情表格。不管怎样,还是建议这种表格应当简明扼要,而且要用日常的语言而非深奥的法律用语来书写,这样用户就不会担心被引诱签署一份会让他们失去什么权利的东西。

    在介绍阶段,实验人员还要保证计算机的物理设置适合于每个测试用户。这里常有的一个问题就是左撇子用户的鼠标,当然还需要调整椅子或者房间的其他部分,以使用户感到舒适。如果用户对所用的计算机类型不熟悉,最好让用户在测试之前练习使用一些其他的软件,以免由于用户最初适应硬件的操作而影响测试结果。

    在介绍之后,把写好的测试指南以及第一个测试任务说明交给用户,请他们阅读。实验人员应该在测试开始之前明确询问测试用户对测试过程、测试指南或者测试任务是否有什么疑问。

    测试

    在测试期间,实验人员通常不要与用户进行交流,也不要有任何个人观点或关于用户操作好还是不好的表示。

    实验人员可以发出一些不代表什么态度的声音,如“嗯”、“啊哈”,来表示知道用户的评论,并让用户继续做下去,但这里需要小心,应当注意声调和语气,不能让用户听出他做对了还是做了可笑的事情。即使用户已经陷人了相当严重的困境,实验人员也要控制

    事后交流

    在测试之后,要询问用户,并要求用户填写一份主观满意度问卷。

    .....

    在询问时,实验人员也可以请用户对测试过程中发生的实验人员难以理解的事件进行进一步的解释。即使用户可能不是总记得他们为什么做那些事情,但他们有时可以澄清他们的假设和目标。

    最后,在测试用户离开以后,实验人员要尽快检査所有测试结果,并用测试用户的编号进行标识,需要标识的还有计算机记录的所有文件、所有问卷和其他表格,以及实验人员自己所做的笔记。

    实验人员还应该在实验后尽快写出一份简短报告,因为这时测试当中所发生的事情在实验人员头脑中还记忆犹新,所有的笔记也还能看懂。

    在所有实验做完之后,最后一项工作就是撰写完整的报告,有了已经整理好的笔记和每次测试后形成的初步报告,这样的工作当然就不是什么难事了。

    6.7 绩效度量方法…

    .....

    关于度量的一个主要问题就是所度量的东西可能与真正想要评估的特性关系不大。......

    通常可以量化的可用性度量指标包括:

    用户完成规定任务所用时间。

    在限定时间内完成的任务数量(或者完成大任务的比例)

    正确的交互操作与所发生错误之间的比率。

    从错误中恢复所用的时间。

    用户出错的数量。

    随后导致的错误操作数量。

    用户用到的命令或其他功能的数量(或者是所发出命令的绝对数量,或者是所用不同命令与功能的数量)。・

    用户从未用到的命令或其他功能的数量。

    在测试后交流中,用户能记住的系统功能的数量。

    使用手册和/或帮助系统的频度,以及使用时间。

    手册和/或帮助系统有多少次解决了用户的问题。 ・

    用户在测试期间对系统肯定和批评的比率。

    用户表达明显的挫折(或明显的欢喜)的次数。

    表示喜欢用该系统而不喜欢用某个特定竞争产品的用户的比例。・

    用户不得不试图解决某个无法解决的问题的次数。

    采用高效策略的用户与使用低效策略的用户之间的比例(在有多种方法完成任务的情况下)。

    用户不与系统进行交互的“呆滞”时间。可以在系统中度量出两种呆滞时间:用户等待系统响应所造成的延迟,系统等待用户思考所造成的延迟。这两种呆滯时间显然可以用不同的方法来研究。

    用户注意力从真实任务被吸引到其他地方的次数。

    当然,在任何特定的度量研究中,通常只对以上这些度量指标的一部分进行数据收集。

    6.8 边做边说法

    ......

    但与此同时,如果过分重视用户关于什么会造成麻烦、什么有帮助的说法的话,边做边说方法也会给可用性问题的原因造成假象

    例如,观察中发现,用户在测试的第一部分忽视了对话框中的某个文本框。在他们最终发现该文本框后,可能会说如果它位于对话框的其他什么地方的话,他们就会立即看到。

    需要注意的是,不能依赖这样的陈述。在测试进行到这一部分时,如果用户忽视了关键对象,实验人员应该记下此时他们正在做什么。显示用户实际看着什么地方的数据比有关用户自己声称的如果把文本框放在其他地方就会看到它,要可信得多。

    边做边说方法的优势在于,它能在用户操作时就显示出用户在做什么和为什么这样做,而不必以后再来推断分析。

    对大多数人来说,把自己的想法大声说出来似乎很不自然。.....

    首先,口述所做的事情将减慢用户操作的速度,使得这样得到的绩效度量数据缺少对用户正常工作速度的代表性。

    其次,用户在口述他们想法的同时必然会影响到他们解决问题的行为。

    用户可能会注意到他们自己所建立的系统模型中相互矛盾的地方,或者他们会全神贯注于关键的任务【Bainbridge1979】,这些变化可能使他们比不这样做时能更快学会使用某些用户界面或以不同方式学会

    例如,Berry 和 Broadbent [1990 把关于如何完成特定任务的书面说明交给用户,他们发现,如果让用户在执行任务时大声说出自己想法,完成任务的速度快了 9%。Bery 和 Broadbent 这样解释道,用户在进行口述时加强了他们对那些任务说明的印象,因而变得更高效了

    [这种方法也许可以用于学习,一边操作,一边将自己的行为和想法说出来,表达出来。]

    在另外一个研究中【Wright and Converse1992】,人们发现在完成各种文件系统操作时边做边说的用户,所犯的错误只相当于那些不出声工作的用户的 20%。而且,边做边说的用户完成任务的速度是沉默用户的两倍。

    ......

    因为在许多人看来自言自语地说出自己的想法还是很不自然的,可以让测试用户在开始测试之前先观摩一段简短的边做边说测试,帮助他们进入角色

    一种可能的办法是让实验人员来演示一下边做边说方法,比如让实验人员进行一些查字典这样的日常工作,同时大声说出自己的想法。还可以给用户放映一小段专门教用户怎样边做边说的录像。让用户看一看录像也能让他们以更轻松的心情面对测试过程中的任何录像。

    用户常常对用户界面上他们喜欢和不喜欢的地方发表自己的评论。在某种程度上说,这正是边做边说方法的主要优点之一,这样可以收集一些有关小感触的非正式意见,而这在其他测试形式中是无法得到的

    尽管它们可能不会影响到可度量的可用性,但也可以对它们进行修复。但用户常常对这样的小问题持不同意见,因此应该注意,不要只因为某个用户的意见就去改变界面。而且,当从更大的方面来看界面设计时,用户的意见常常就不合适了,因此实验人员有责任去解释用户的意见,而且不能不分青红皂白地全盘接受

    ....

    协同交互方法

    边做边说方法的一种变形叫做协同交互(constructive interaction,就是让两个测试用户同时使用一个系统【o' Malley et al,1984]。

    这种方法有时也叫做协同发现式学习【Kennedy1989]。

    协同交互方法的主要优点在于,测试形式比只用单一用户进行的标准边做边说测试显得更为自然一些,因为人们习惯于在共同解决问题时把自己的想法讲出来。因此,当用户忙于协同交互时,会比只有单个测试用户为满足实验人员的需要而自言自语能说出更多的意见【Hackman and Biers192]。

    这种方法也有缺点,就是用户可能有不同的学习和使用计算机的策略。因此,测试时可能出现用户在迥异的使用方法之间来回转换的情况,偶尔还会出现两个测试用户无法共同工作的情况。

    协同交互方法尤其适于对儿童使用的用户界面的可用性测试,因为让孩子们遵循标准的边做边说测试方法可能会有困难。

    在很容易找到大量用户而且使用这些用户的费用比较低廉的情况下,最适于采用协同交互方法,因为这种方法所需要的测试用户数量是单用户边做边说测试的两倍。

    回顾式测试

    如果在测试期间录了像,就可以让用户温习录像的内容来收集额外的信息【Hewett and Scott1987]。这种方法有时就叫回顺式测试(retrospective testing)。

    在看录像带的时候用户不会那么紧张,没有执行测试任务时的紧迫感,因此会说出更多的意见,当然实验人员也能随时停止播放,以便向用户询问一些更详细的问题,由于测试本身已经完成,所以不用担心对测试造成干扰。

    回顾式测试在难以找到有代表性的测试用户时尤其有价值,因为它能从每一个测试用户那里获得更多的信息

    它明显的不足之处在于,每个测试至少要用双倍的时间,因此这个方法不适于用户报酬很高,或因用户从事关键工作而不能占用太多时间的情形。然而,那些难以参加测试的用户往往恰恰是高价的用户,不过还是存在一些回顾式测试能用得上的地方。

    辅导方法

    辅导方法(Coaching Method) [Mack and Burdett1992] .....需要引导用户在正确的方向上使用系统。

    在开展辅导方法研究时,测试用户可以问任何与系统相关的问题,辅导人员将尽可能地来回答这些问题

    通常由实验人员或者研究助手来担当辅导人员。

    有一种变形的辅导方法是从熟练用户中选择一人作为辅导人员。.....辅导方法通常关注的是新手用户,目的是发现这类用户的信息需求,以便提供更好的培训和文档资料,同时还能帮助重新设计界面来避免这些问题。

    已经证明,辅导方法对于发现日本用户使用计算机时遇到的问题是很有用的【Kato1986]。很多其他的传统方法有时难以在日本使用,文化上的因素使得一些人不愿表述自己对界面设计有不同意见的地方。

    辅导方法的情况与边做边说方法相比要自然一些。它另外一个好处是,可以用在所面向的用户群较小、很特殊或报酬很高的情况。....

    最后,辅导方法还能用于想用熟练用户进行测试但却没有找到任何熟练用户的情况辅导可以让新手用户的操作水平得到迅速提高,一且他们达到了所要求的技能水平就可以进行关于用户绩效的传统测试了。

    6.9 可用性实验室

    ....实验室当然会提供很多的便利,但对可用性测试来说,却不是绝对不可或缺的。可以临时把常规的办公室改变成可用性实验室,而且即使只有一个笔记本而没有其他任何设备也可以进行可用性测试。

    .... 可用性实验室里通常都有隔音的单面镜,用于隔开观察间和测试间,让实验人员、其他可用性专业人员和开发人员在不打扰用户的情况下讨论用户的操作。

    用户并不笨,他们不可能不知道在测试间墙上巨大镜子后面有一群观察人员,因此不妨在测试前带用户简短地参观一下观察间。知道镜子后面有谁和有什么东西,与不得不想象那里有什么东西相比,用户的紧张感会小得多。即使他们知道观察人员就在那里,在测试期间他们通常会逐渐忽视这些看不见的观察人员。

    在主要的观察间后面再增加一个附属观察间的话,可以让第三组观察人员(例如,开发人员)在不打扰观察间的主要实验人员和可用性专业人员的情况下对测试进行讨论。

    可用性实验室通常都装备有多台可以在观察间进行遥控的摄像机.....

    可用性实验室里还有一些其他的设备,用来监视用户和研究他们的行为细节,当然这些设备并不太常见。例如,视线跟踪装置可以用来收集用户正在注视屏幕上的哪一部分这样的数据【Benel et al.1991]。

    需不需要录像

    ....

    通常并不需要重看用户测试的录像,因为不管怎样测试,我们最关心的就是发现主要的“可用性灾难”。这些可用性问题往往都很显眼,在第一次观察时就很明显了,因此并不需要对测试过程进行反复研究。.....

    人类因素学专业人员经常遇到这样的困难,就是怎样让开发人员和管理人员信服的确存在某个可用性问题,在这样的情况下,录像带可以成为一个十分重要沟通介质。看到用户与问题斗争的录像,常常可以使这些人相信确有其事。不过,要达到这个目的还有更简单的办法,那就是让持怀疑态度的人亲自去观察用户测试情况,这通常会更有效°。

    赞成使用录像和配备大量设备的可用性实验室的另一个理由,就是要让上级领导和研究资助机构对可用性工作的独特性留下印象。一些可用性专业人员觉得那种更简单的技术不足以给外行留下深刻印象,而拥有一个造价昂贵的实验室,将会由于它的“广告价值”而获得更多资助和重视。

    没有摄像机的录像

    ....许多计算机都有视频输出,....用这个技术录制的图像质量通常要好于用摄像机拍摄的屏幕画面质量,但影像分辨率仍然不如大多数计算机显示器。....

    没有摄像机的录像方法的明显缺点就是不把用户包含在画面里,也无法让摄像机操作人员把屏幕上感兴趣的部分以及用户徒劳地研究过的手册进行特写放大。.....这些局限使得最后制成的录像带有时缺乏感染力和不太令人信服。但由于既没有摄像机,也不需要操作人员,无摄像机的录像成本相当低廉,而且通常用户面对话筒时比面对摄像机时感到的畏惧要少一些

    便携式可用性实验室

    .....一个记事本,可能还有一台笔记本电脑来运行要测试的软件。不过通常的便携式可用性实验室还要多一些设备。典型设备有便携式摄像机和垂挂式话筒....

    可用性信息亭

    可用性信息亭(usability kiosk)....一种真正自助式的可用性实验室【Gould et al.1987]。一般说来,门厅调査方法就是把用户界面显示在公司自助餐厅外这样一些人流很大的地方,用于收集来自用户和过路人的意见。....

    2019-06-28 16:53:23 1人喜欢 回应
  • 第180页 第七章至第十章
    • 第 7 章其他可用性评估方法
      • 7.1 观察法
      • 7.2 问卷调查与访谈…………
      • 7.3 焦点小组………
      • 7.4 记录实际使用情况……………
        • 与后续访谈的结合
      • 7.5 用户反馈…
      • 7.6 可用性方法的选择…
        • 可用性方法的组合
    • 第 8 章界面标准
      • 8.1 国家标准、国际标准与企业标准
      • 8.2 制定可用的企业标准
    • 第 9 章国际化用户界面
      • 9.1 国际化图形用户界面
        • 手势界面
      • 9.2 国际化可用性工程
      • 9.3 国际化指南…
        • 字符
        • 数字与货币
        • 时间与度量单位
        • 不要绝望
      • 9.4 资源分离
      • 9.5 多地化界面
    • 第 10 章未来的发展
      • 10.1 理论解决方案…
      • 10.2 技术解决方案
      • 10.3 CAUSE 工具:计算机辅助可用性工程
      • 10.4 技术转移…
    • 附录 A 练习
    • 附录 B 文献

    第 7 章其他可用性评估方法

    7.1 观察法

    .....它只需要访问一个或几个用户,让他们使用系统和产品,观察者尽量什么也不要做,以免干扰他们的工作。.....

    7.2 问卷调查与访谈…………

    .....

    从可用性的角度来看,问卷调查或访谈属于间接方法,因为两者都不对用户界面本身进行研究,而只是研究用户对界面的看法。

    人们不能完全听信和采纳用户的说法。用户的实际行为要胜过用户对自己行为的语言表述。....

    7.3 焦点小组………

    7.4 记录实际使用情况……………

    记录数据是指计算机自动收集的关于系统使用情况的详细统计数据。 ......

    有关各种错误出现频率的统计数字可以用于改进今后所开发系统的可用性。

    日志方法一般通过使用系统软件中的低层部分,如键盘和鼠标的驱动程序,或者通过修改要测试的软件来实现。.....

    记录用户使用系统的各种情况会带来个人隐私问题一般要向用户解释所收集的是概要的统计数据,出现在报告中的结果不会涉及具体用户

    .....最大的优点是用户不会受到干扰。....

    日志数据除了用于统计之外,还可以记录用户在一段时间内的全部操作信息,可用于事后回放【Neal and Simons1983,1984】,或用于对使用模式的分析,例如在出错后用户发出的操作命令是什么【Siochi and Enrich1991]。....

    最后,还可以用日志数据来研究用户对界面的详细使用情况,以发现那些不明显的、无法通过观察用户而捕捉到的可用性问题。....

    与后续访谈的结合

    ....

    7.5 用户反馈…

    ....

    用户反馈方法有以下优点:

    由用户主动提供,因此能够直接反映出用户最关注的地方。

    反馈是一个持续的过程,所以不需要进行额外的收集工作。

    能迅速反映出用户在需求、环境和想法上的改变,因为无论何时发生这种改变,都可以通过最新的反馈显示出来。

    当然,可用性人员听到的往往是那些不满意的和最愿意抱怨的用户的意见,因此用户反馈可能并不代表大多数用户的看法。在这些抱怨中许多是不具有代表性的,是由于用户的错误分析而产生的,或者根据用户自己熟悉的某个系统(实际上该系统更糟糕)而期待当前系统具有那样的功能。因此,建议作为对用户主动反馈的补充,应当挑选一组有代表性的用户,对他们进行观察和提问

    ......

    另外,许多软件公司都采用 beta 测试,就是把即将问世的产品发行给小部分挑选出来的客户,让他们对产品做出评价。beta 测试方法能及时获得用户反馈,以改进产品的第一个正式发行版。

    不要认为 beta 测试只是种发现编程错误的调试方法,它还可以作为系统化的方法来搜集、分析用户关于软件中不符合用户需求的意见。

    当然,beta 方法并非用于程序调试的唯一方法,它也不应该是可用性工程的唯一方法,因为 beta 测试的反馈信息,与在产品开发早期使用的可用性工程方法所获得的反馈相比来得太迟了,无法获得同样富有成效的结果。

    ....

    7.6 可用性方法的选择…

    ....

    可用性方法的组合

    ....

    一个常用的组合是经验性评估加上边做边说或其他形式的可用性测试。....

    与此类似,访谈和问卷调查也可以结合使用,即通过对一小部分用户进行开放式访谈,用于探讨分析,来明确定义封闭式问卷中的具体问题。

    第 8 章界面标准

    ....

    一致性问题是可用性最重要的方面之一【Nielsen1989 c】。尽管一致性不是可用性的唯一考虑因素【Grudin1989】,.....

    界面一致性和标准有益于用户

    .....

    界面一致性和标准有益于软件商

    ....

    标准带来的不利因素

    ....

    费用昂贵.....产品开发被拖延.....与在市场上尽快投放第一个产品的压力之间会产生矛盾。......一旦拥有了标准也意味着在软件生命周期中要有相应的开销,以确保界面符合标准和评价新的用户界面是否确实具有一致性。.....

    对于通用的用户界面来说,因为要兼容大量已使用的原始界面,因此有可能会成为一个通用的低水平界面。不管怎么说,通用用户界面可能会遏制新产品设计的创新思路,并阻碍对产品设计的改变(有时是必要的改变)。一致性也意味着各个产品设计上的灵活性减少了,导致这些产品可能不能满足应用领域的特定需求和环境。另外,如果标准所包含的规则很糟糕,它不仅会阻碍产品设计的改进,甚至强制推行低劣的设计。

    从组织机构的角度来看,如果开发人员觉得他们无法主宰用户界面设计,那么企业标准会不利于激发开发人员的积极性。....

    从一开始就制定正式的工作程序,根据最新的需求和技术来修改通用用户界面,就可以避免用户界面标准的某些缺点。....

    8.1 国家标准、国际标准与企业标准

    .....

    请参见 ACM(美国计算机协会)的 SIGCHI Bulletin(人机交互专业组公告)的固定栏目“标准因素”,以了解 ISO (International Standards Organization,国际标准组织)、ANSI (American National Standands Institute,美国国家标准) 以及其他几个标准组织的工作进展情况报告。

    .....

    8.2 制定可用的企业标准

    .....

    有两种方法已被证明在对标准进行可用性测试方面比较成功,

    一种方法是请几个设计人员运用标准来设计一个小型的“玩具”界面,

    另一种方法是向他们展示一个在许多方面违反了标准的界面,并请他们找出该界面中违背标准的地方【Thovtrup and Nielsen1991]。

    在这样的测试中,对设计人员运用标准的情况进行观察,甚至可以请设计人员把自己的所思所想大声说出来,即“边做边说”(见 6.8 节),对标准是否易于使用进行评估。

    可以检查“玩具”界面的设计结果是否符合标准,可以把设计人员列出来的有悖标准之处与真正的情况相比较,看看哪一条被忽视了,哪一条本是合理的设计却被误认为是违背标准的。根据这些结果来评估标准是否能有效地用于实践以及实现界面一致性。

    有关这一方面尚无更多的研究,但现有事实确实表明有可能存在着“元可用性问题”(meta- usability problems)(可用性文档中的可用性问题)。 .....

    ....

    第一,在标准中要尽可能包含足够多的示例

    第二,特别要注意示例的设计是否完美和完全符合标准

    ....

    跨团队交流的一种方法叫做一致性检查(consistency inspection) [Wixon et al.1994]。

    一致性检查是一种可用性检査方法,旨在发现一组用户界面设计中存在的不一致性问题

    每次由一组评估人员检査一个界面,每个开发团队派出一名代表参加评估小组。按部就班地检査界面中的每个元素,对每一个与其他系统不一致的地方进行记录。有些不一致性问题在检査过程中可以轻易解决,这可以依据用户界面标准来实现,或者可以基于设计本身的特性来直接判断某个方案比另一个好。有些不一致性问题很难解决,可以留待进步讨论、用户测试或者进行更多的设计工作。

    一致性检査的另一种形式是协同评审(synergy review),一般在开发的早期阶段,在界面设计好之前进行这种检査。与一致性检査方式相同,参加协同评审的人员来自于多个项目小组,也是一次评审一个界面

    .....

    第 9 章国际化用户界面

    .....

    由此可见,虽然软件的国际化使用问题对美国的用户和开发人员来说看不到,但这一问题在非英语国家却是一个重要的问题【Sprung1909】

    9.1 国际化图形用户界面

    .....

    可以根据图标的图形设计将图标分为三大类° [Lodding1983; Roge 1989]:

    1) 相似图标(Resemblance icon):描述图标所要表示的物理对象。例如使用信封图片来表示电子邮件文件就使用了相似图标。

    2) 引用图标(Reference icon):描述一些图标对象,通过参照和类推来表达图标想要表示的概念。例如,用弹簧夹图片表示压缩文件的工具(因为夹子有挤压的效果)就使用了引用图标。除非使用两个图标的组合分别表示压缩前后的大文档和小文档,否则很难用引用图标来表示文件压缩,但采用这种体现状态变化的图标会让人难于理解。有时也把引用图标称作“符号图标或“索引图标”。

    3) 指定图标(arbitrary icon):指定图标只有通过约定才具有特定含义交通标志就是指定图标,由于交通标志在国际上已非常标准化,这些标志可能构成一个很好的计算机图标来源。.....

    在越来越国际化的今天,引用图标和指定图标的应用与相似图标相比,情况要糟得多。即使在有些情况下,指定图标有着广泛的国际基础,但却可能不为一些国家所知,......

    手势界面

    正如图标未必是全球通用的一样,在笔式电脑以及一些虚拟现实系统中使用的手势方面,可能需要对界面的国际可用性进行深入研究。.....

    9.2 国际化可用性工程

    .......

    为了保证获得最理想的翻译,翻译小组中至少要有一名翻译是目标语言国家的当地居民,因为移居国外的人若干年之后已对语言详细情况缺乏了解。......

    [翻译在国外太久,对本国语言反而不够熟悉了。...]

    最后,还要当心不要让随意的假设来限制软件设计,.....

    早期关注用户和用户任务也包括国际范围的用户,为此,应当促进开发机构和公司的国际部门或者销售人员之间的沟通与交流。国际部的代表应全程参与早期的产品规划阶段,还要鼓励他们对不同市场的特殊需求发表自己的看法

    9.3 国际化指南…

    .....

    字符

    许多国家除了英语中使用的 A-Z 字母和 ASCⅡ字符集之外,都有自己的扩展字符集。一条显而易见的原则就是应当包容各种本地字符集,......

    .....

    当前采用的两种真正的国际字符集标准是:采用双字节对字符进行编码的统一字符编码标准(Unicode)和 ISO 10646 的四字节编码标准【Sheldon199]9。 ......

    数字与货币

    不同的国家使用不同符号来表示数字。.....

    时间与度量单位

    用户界面需要处理不同的度量系统,最常用的两个重要度量系统是采用公制度量单位的 SI 系统(System International)和采用英寸、英尺、英里和华氏温度等单位的美国标准。一天的时间表示有时用 24 小时制(如 2200),有时用 12 小时制表示(如 10:00 PM)

    在日期的表示上也有不同的写法,最常见的几种写法如下所示

    日月/年(例如,5/093表示1993年10月 5日)

    日/月/年(例如,5/10-93)

    日/月/年(例如,10/5/93 或10/05/93)

    年/月/日(例如,1993.10.05)

    年/月/日(例如,1993-10-05) ....

    用数字来表示星期在欧洲也很常见。......有些国家使用的是自己的日历而不是现在通用的公历,......

    不要绝望

    .....

    能够结合当地的惯例提出具有一定灵活性的设计,而不是僵化和墨守成规,就已经很好了。同样,虽然不可能在所有可能用户的国家进行全面的测试,但在进行用户测试的时候让几个外国用户参加测试,要比只靠从本国用户获得信息来进行设计要好得多。

    9.4 资源分离

    在实践中提高国际化可用性的主要途径之一是将界面与系统功能的实现相分离【Edmonds1991]。......

    除了资源数据库外,可以用版本控制工具来协助对升级的界面进行翻译。有许多界面元素及其翻译将保持不变(为了保持跨版本一致性)。其他一些界面元素将会有所变化,即使没有任何变化的字符串,也会由于出现在不同的使用环境中而需要重新翻译。同样,翻译人员也需要一个翻译工具,把他们在相应环境下将会用到的各种资源显示出来。

    在一些系统中,许多本地的惯例,如字符排列顺序、日期书写形式、月份名称等,被存储在任何应用程序都可以使用的中心资源库中。....

    9.5 多地化界面

    根据系统范围资源以及对应用程序特有资源的翻译所进行的本地化,足以支持在某个特定文化背景下对界面的使用。......

    数据库命令、出错消息等也应该随着地区的改变由英文变为德文。如果德国用户刚好有一个法国人到访,应该也能将该系统的地区临时设为法国,使之能够在法语环境中运行。

    第 10 章未来的发展

    ......

    然而,并不存在可以神奇地解决所有可用性问题的“银弹”(银弹可以用来消灭凶恶的敌人)。.......没有一个方法可以解决根本问题「Bmok197]。Plus ça change, plus çest la meme chose(越改变越像从前一样)。

    ......

    可用性工程的基本问题在于如何了解实际用户以及他们的任务,提出创造性的设计方案使计算机的能力与用户和用户任务相匹配,并且对设计方案进行测试,以尽量消除界面、用户、用户任务之间的各种不相匹配的情况

    所有的问题都是源于两个因素:个人和真实任务【Nielsen1989】,与人们的期望相反,它们都往往与预定的限制相违背。 .......

    许多关于可用性工程发展的报告中都存在一个问题,即把方法本身的效果和具体实验的使用效果混为一谈

    ......在多数情况下,之所以能得到报告中的良好结果,主要是因为这些专家本身的技能以及他们对项目的高度热情,而不是因为所推荐的方法或工具本身的内在价值。

    10.1 理论解决方案…

    .....

    最好出现一种生成性的可用性理论,它可以根据希望达到的可用性目标来设计用户界面。最著名的分析方法就是 GOMS (goals, operators, methods, and selection rules) Card et al.1983]

    基本的 COMS 方法非常简单:

    首先列出可能的用户目标和子目标(比如,想修改文本中的单词);

    操作就是指用户的运动、感知或认知方面的基本行为(比如,点击鼠标、査看菜单条、记忆名称等);

    方法就是用户通过一系列操作来达到目标和子目标(比如,选择就是通过移动鼠标指向单词然后再双击来实现的);

    ......

    基本的 COMS 模型有一些缺点【Carroll and Campbell1986】,最主要的不足在于,它的数据来源仅仅局限于熟练用户的无差错操作。.....

    ....

    [类似界面规范]

    人们已经提出了多种规范定义用户界面的方法,包括许多在原来传统软件工程的规范技术基础上针对动态交互系统的定义所提出的扩展技术。

    例如,状态转换图【Wellner1989)、

    BNF [Reisner1981]、

    Petri网【Stotts and Furuta1989]、

    生产系统【Olsen199】,

    逻辑程序设计【Roach and Nickson 1983] 和

    时序逻辑【Johnson1991]。

    人们也发明了一些专门用来规范用户界面的新方法,比如

    用户动作表记法 UAN (User Action Notation) [Hartson et al.,1990]。

    尽管有这么多的研究工作,但当前几乎没有用户界面采用正式规范。

    .....

    10.2 技术解决方案

    .....

    语音.....本书认为,即使有一天,语音技术已经非常完美,仍然需要可用性工程工作来保证对话的质量。只要考虑一下你和其他人说话时出现误解的次数就可以知道这是为什么。

    ...

    人们在建立智能帮助系统上投入了相当多的努力,这么做可能是基于可用性的花生酱理论,该理论认为,盖上足够厚的一层花生酱会盖掉原有的味道。.......

    智能帮助的设想很好,如果帮助系统能够知道用户想做什么,并且可以基于用户的已知模型来提供建议,那么它们就可以提供更有效的帮助。但在现实中达到这一步还需要很多年。....

    10.3 CAUSE 工具:计算机辅助可用性工程

    .....CAUSE 是指计算机辅助可用性工程(Computer- Aided Usability Engineering),类似于 CASE 代表计算机辅助软件工程(Computer-Aid ed Software Engineering)。....

    .....

    在一些公司有各种各样自制的 CAUSE 工具,其中有一些也有商业版本,但大多数早期的尝试都没有形成集成工具,因此也无法完全支持整个可用性工程生命周期。....

    10.4 技术转移…

    .......

    人们更愿意让其他人来冒险尝试那些未被证实的创新,原有技术的用户群会形成强大的惯性,它甚至会阻止已经证实的概念得到立即应用。

    通常,技术转移是通过创新扩散过程来进行的,首先是从创新中心传播到一批早期使用者,而大多数用户在很长时间后才可能使用这些技术。.....

    有一种方法可以加快技术转移的速度,该方法通过采用改进代理人,让这些代理人专门负责技术推广,并且负责推动行动缓慢的组织机构采用新技术。在可用性工程领域,改进代理人可以是项目经理,....

    附录 A 练习

    [重要,要看]

    附录 B 文献

    [重要,要看]

    2019-06-28 18:06:52 回应

香蒲的其他笔记  · · · · · ·  ( 全部672条 )

厌女
1
高等数学(上册)
1
古今数学思想(一)
3
统计学习方法
1
Questions of Perception
1
HBR's 10 Must Reads Ultimate Boxed Set
1
Graphic Design Thinking
1
Why We Sleep
1
Creative Confidence Unleashing the Creative Potential within Us All
1
生命的重建
1
对伪心理学说不
1
商业静物摄影
1
商业创新设计
1
敏捷革命:提升个人创造力与企业效率的全新协作模式
1
写我人生诗
1
人类及其象征
1
User-Centered Design
1
The Mom Test
1
Personal Development for Smart People
1
Information Dashboard Design
1
Seeking Wisdom
1
Prototyping: A Practitioner's Guide
1
福尔摩斯探案全集(全七册)
1
How to Sell Your Business for the Price You Want
1
Change by Design
1
Unfolding the Napkin
1
The Design of Business
1
Systems Thinking in the Public Sector
1
In the Bubble
1
Business Model Generation
1
Nudge
1
From Products to Services
1
Exposing the Magic of Design
1
创新40法:TRIZ创造性解决技术问题的诀窍
1
GLSL Essentials
1
OpenGL Shading Language
1
Agile for Everybody
1
21 Lessons for the 21st Century
1
Designing UX
1
Designing Brand Identity: An Essential Guide for the Whole Branding Team
1
Design Drawing
1
Color, Space, and Style
1
101 Things I Learned in Advertising School
1
幸福的建筑
2
向大师学绘画
2
徒手绘画及速写
1
心理学与人类困境
2
现代设计的先驱者
1
Merriam-Webster's Vocabulary Builder
10
马克思恩格斯全集(第1版)
1
名利场(书虫·牛津英汉双语读物)
7
书虫·牛津英汉双语读物:巴彻斯特教堂尖塔
2
苔丝
2
罗生门
1
trapped!
1
奔向月球
1
神秘的流星
1
法老的雪茄
1
ㄎㄨㄥˇ(7)
1
设计入门教室1
1
设计入门教室:设计的基本规则
1
This Is Service Design Doing
15
Moebius 1: Upon A Star
1
The Artist’s Complete Book of Drawing Projects Step-by-Step
1
The Art of Thinking Clearly
1
网页的吸引力设计法则
1
匠心体验
1
网页设计创意书(卷4)
1
GUI设计禁忌
1
重新定义团队:谷歌如何工作
1
Sketching User Experiences
1
演讲的力量
1
草根也能玩收藏
1
赖声川的创意学
1
阳羡茗壶系.骨董十三说
1
食宪鸿秘
1
造房子
1
莫奈和他的眼睛
1
洛书河图
1
设计师谈家居色彩搭配
1
植物知道生命的答案
1
演员自我修养 第二部
1
乐之本事
1
MUJI 無印良品
1
美术馆里聊怪咖
1
视觉与绘画
1
国际用户体验设计 : 阿里国际站用户体验设计案例精粹
1
敏捷用户体验设计
1
惊奇UCD
1
设计败道:来自著名用户体验案例的教训
1
Landing Page优化权威指南
1
Web可用性设计
1
工业设计史
1
用户中心设计
1
设计与文化导论
1
黑客与设计:剖析设计之美的秘密
1
国际经典字体设计教程:字体要怎么使用
1
未来产品的设计
1
什么是网页设计
1
搞砸了的设计
1
UCD火花集
1
数学与设计
1
交互的未来
1
好设计不简单Ⅱ
1
用户界面设计指南
1
世界现代设计史
1
设计,在人人设计的时代
1
存在之难
1
多设备时代的UI设计法则
1
随意搜寻
1
表演圣经
1
网站情感化设计与内容策略
1
体验设计白书
1
网页设计创意书(卷3)
1
国际经典交互设计教程:用户体验设计
1
UX设计之道
1
国际经典设计教程:交互设计
1
设计的品格
1
包豪斯舞台
1
童话的魅力
1
贾想 I
1
启示录
1
研究是一门艺术
2
剑桥艺术史:中世纪艺术
1
古典音乐的巨匠时代(1685—1897)
1
美国学生艺术史
1
图说西方建筑艺术
1
无言之美
1
美学散步
1
伤花怒放
1
阴翳礼赞
1
古典音乐简单到不行!
1
剑桥艺术史:文艺复兴艺术
1
竞争的艺术
1
移动应用界面设计
1
剑桥艺术史:绘画观赏
1
美学十五讲
1
字体故事
1
穿T恤听古典音乐
1
设计心理学2
1
怦然心动
1
引人入胜
2
胜于言传
1
设计中的设计
1
幽默沟通学
1
疾病的隐喻
2
白板
1
App,这样设计才好卖
6
跟我玩孙子兵法和三十六计
2
愿望树
1
月光男孩
1
约瑟夫有件旧外套
1
有一天
1
圆圆的月亮
1
有个性的羊
1
勇敢的克兰西
1
一只有教养的狼
1
永远永远爱你
1
艺术大魔法
1
一只孤独的乌鸦
1
一只很饿很饿的小猪
1
一园青菜成了精
1
一口袋的吻
1
一片叶子落下来
1
野马之歌
1
爷爷变成了幽灵
1
摇摇晃晃的桥
1
鼹鼠的音乐
1
养只小龙很简单
1
鸭子农夫
1
鸭子骑车记
1
鸭子,鸭子,鹅
1
寻找国王的皇冠
1
我家是动物园
1
雪人
1
当熊爱上蝴蝶
1
幸福的大桌子
1
星期三书店
1
鞋子里的盐
1
小棕熊的梦
1
小真的长头发
1
小鼹鼠嘉宝
1
小熊不刷牙
1
小象的大便
1
小仙女艾丽斯
1
小熊进城
1
小猪奴尼
1
一颗超级顽固的牙
1
纸袋公主
1
朱家故事
1
祝你生日快乐
1
走进生命花园
1
GUJI GUJI
1
波罗历险记
1
月亮,你好吗
1
月亮的味道
1
月亮狗
1
月下看猫头鹰
1
再见小树林
1
提姆与莎兰1 远方寄来的生日礼物
1
糟糕,身上长条纹了!
1
这片草地真美丽
1
这是我的
1
自由的苹果
1
小老鼠忙碌的一天
1
小狐狸买手套
1
小步走路
1
我们要去捉狗熊
1
我弄丢了我的吻
1
我讨厌书
1
我讨厌妈妈
1
我喜欢自己
1
我喜欢我的小毯子
1
我想有颗星星
1
我想吃一个小孩
1
我有友情要出租
1
巫婆的孩子
1
巫婆的孩子与女王
1
西雅图酋长的宣言
1
下雪了
1
洗个不停的妈妈
1
五个丑家伙
1
像狼一样嚎叫
1
小刺猬的麻烦
1
小房子
1
小黑鱼
1
小红狼和小黑狼
1
小红书
1
小凯的家不一样了
1
小鸡和狐狸
1
小蜡笔头儿
1
小老鼠亚历山大
1
小牛的春天
1
小鲁的池塘
1
我爱我的爷爷
1
温情的狮子
1
小兔波力1:我不是故意的
1
我的爸爸叫焦尼
1
我好担心
1
伟大的一步
1
忘了说我爱你
1
万娅和野兽
1
晚安,尼尔斯
1
晚安,猫头鹰!
1
让路给小鸭子
1
全都是我的
1
晴朗的一天
1
抢救动物园
1
我不知道我是谁
1
我的名字克丽桑丝美美菊花
1
我的朋友好好吃
1
我的兔子朋友
1
我和你
1
我叫皮皮菲莉比
1
中国第一套儿童情绪管理图画书1(全4册)
1
我们的妈妈在哪里
1
我们的强强
1
婷卡
1
提姆与莎兰的小木屋
1
特别的客人
1
讨厌黑夜的席奶奶
1
跳舞吧,小雅
1
外公
1
世界是你的
1
书中书
1
十个手指头和十个脚趾头
1
狮子牙和丝绸爪子
1
小熊和最好的爸爸(全7册)
1
首先有一个苹果
1
世界为谁存在?
1
树真好
1
睡觉去,小怪物!
1
睡鼠的睡梦时光
1
四个红苹果
1
松鼠的眼泪
1
苏菲的杰作
1
汤姆上幼儿园
1
桃太郎
1
谁藏起来了
1
三个笨学生
1
旅之繪本 Ⅲ
1
你是我的孩子
1
你很特别
1
你睡不着吗?
1
欧先生的大提琴
1
你在开玩笑吗?
1
农夫去旅行
1
约瑟芬姨妈的房间/赛娜的鬼主意
1
谁来我家
1
誰在廁所里?
1
神奇的黑板熊
1
神奇的色彩女王
1
生命之树
1
生气的亚瑟
1
生气汤
1
三只小猪的真实故事
1
色彩的翅膀
1
森林大熊
1
莎莉,离水远一点
1
莎莉,洗好澡了没?
1
山猫怎么办
1
三个强盗
1
南瓜汤
1
尼尔森老师不见了!
1
母鸡萝丝去散步
1
气球小熊
1
梦是什么?
1
米丽的大秘密
1
陌生人
1
帽子先生和他的独木舟
1
忙忙碌碌镇
1
两只坏蚂蚁
1
1
楼上的外婆和楼下的外婆
1
妈妈不知道我的名字
1
妈妈的红沙发
1
妈妈的礼物
1
驴小弟变石头
1
妈妈心·妈妈树
1
妈妈你好吗?
1
两列小火车
1
连在一起
1
丽塔和鳄鱼迷路了
1
丽莎想要一只狗
1
雷奥与狗
1
老鼠,小心!
1
老鼠娶新娘
1
蓝色的天空
1
快乐鸟的许诺
1
卡卡莫特岛-好居乐农场的趣事-大师经典绘本
1
玛丽的秘密
1
快活的狮子
1
壳斗村的帽子店
1
看!身体怎么说话
1
看看我有什么
1
看!画家也会捉弄你
1
看!观察画里的光
1
凯迪和一场很大的雪
1
卡夫卡变虫记
1
咔嗒,咔嗒,哞
1
鲸鱼
1
杰德爷爷的理发店
1
驾驶机器人看恐龙
1
加油鸡蛋哥哥
1
机器人心里的蓝鸟
1
火焰
1
会说话的蛋
1
会说晚安的故事
1
灰狼家的小饭桶们
1
獾的礼物
1
花婆婆
1
花格子大象艾玛
1
蝴蝶·豌豆花
1
狐狸电话亭
1
呼噜,呼噜,哞
1
红豆与菲比
1
荷花镇的早市
1
和我一起玩
1
和甘伯伯去游河
1
和爸爸一起散步
1
海马先生
1
海底的秘密
1
怪男孩
1
公园里的声音
1
给爸爸的吻
1
大吼大叫的企鵝媽媽
1
疯狂星期二
1
鳄鱼爱上长颈鹿
1
动物园
1
我的妈妈真麻烦
1
调皮鬼恐怖心
1
蒂科与金翅膀
1
德沃夫爷爷的森林小屋
1
当我想睡的时候
1
当我睡不着的时候
1
胆小的老鼠
1
大嘴狗
1
大野狼
1
大猩猩
1
大卫上学去
1
大滴大滴的眼泪
1
打瞌睡的房子
1
打开诗的翅膀
1
春神跳舞的森林
1
窗外送來的禮物
1
出走的绒布熊
1
吃书的狐狸
1
吃掉黑暗的怪兽
1
不要再笑了,裘裘!
1
不要睡觉,赛莉
1
不会写字的狮子
1
不会唱歌的小鸟
1
重新定义公司
1
像艺术家一样思考
1
为什么大猩猩比专家高明
1
思维的乐趣
1
方寸指间
1
决策与判断
1
沟通的艺术
1
洞察:精确观察和有效沟通的艺术
1
意志力
1
囚徒爆发力
1
囚徒健身2
1
囚徒健身
1
失控
5
精英必修课:清单+Excel+方法+时间(全四册)
1
宽容
1
庄子今注今译(全三册)
1
为什么精英这样用脑不会累
1
自醒:从被动努力到主动进步的转变
1
自深深处
1
自控力
1
异类
1
幸福之路
1
新100个基本
1
把时间当作朋友
1
安静
1
如何阅读一本书
2
大脑的情绪生活
3
斯坦福高效睡眠法
1
休息的艺术
1
关键设计报告
4
锦绣蓝图
4
企业创新101设计法
6
亲爱的界面
5
人人都是产品经理2.0
7
人人都是产品经理
4
设计方法与策略
4
设计之下
5
设计中的视觉思维
8
瞬间之美
2
搜索模式
2
通用设计方法
3
网站交互设计模式
9
网站设计解构
2
细节决定交互设计的成败
3
信息可视化
4
移动设备交互设计
4
赢在设计
2
用户故事与敏捷方法
2
用户体验草图设计
2
用户体验面面观
9
移动应用UI设计模式
4
交互设计之路
3
用户体验的要素
3
街头生意经
2
精益创业
1
精益创业实战
2
潜移默化
1
一目了然
1
赢在用户
2
增长黑客
3
长尾理论
1
长尾理论
1
MBA教不了的创富课
1
破茧成蝶2
4
设计冲刺
2
高效能人士的七个习惯
1
为真实的世界设计
1
人因工程学导论
3
设计的法则
5
创造突破性产品
2
Web表单设计
2
UCD火花集2
1
众妙之门
1
一千零一夜
4
界面设计模式(第2版)
1
破茧成蝶
6
国际交互设计基础教程
1
触动人心
1
Voice Interaction Design
5
金字塔原理
5
About Face 4: 交互设计精髓
4
Thoughts on Interaction Design
3
交互设计沉思录
3
视觉艺术用光
2
冥想
1
简约至上
1
Don't Make Me Think, Revisited
5
点石成金
4
The Elements of Style
10