|
主要原则
如果你不懂得好的用户界面的设计，你不可能够设计出更有用的程序。让两个程序员来考虑同样的一个用户界面，将会产生一场争论。每一个人都会有自己的观点和看法。但是真正的关键是什么在起作用。因为缺乏客观的测试，我们不得不依赖于良好的人机对话的通用原则。Jacob Neilsen将其归纳为10条清晰显著的启发式。从我们以往与开发者工作的经验中我们发现以下的基本原则是易于学习和易于应用到实际设计决策中的。其中有五项（原则）被非常夸张的称为可用性规则的指标；它们为好的用户界面提供了一个框架以及通用的对象。其它六项（原则）则涵盖了好的用户界面的特殊方面的准则。 牢记这些主要的准则并不能保证一个好的用户界面，但是在已发布的原则的基础上作出的决策将提高这种可能性。一个观念是：在一条或更多的已被验证的准则上而不是在个人观点和看法的基础上谨慎且自觉的做出用户界面设计决策。这当然不可能涵盖所有事情；甚至艺术和美学也没有被提及。一个好的用户界面常有图形的优美和可视化的要求。但换句话说，在将美学放在必要用途之前考虑是一种普遍的错误，这将导致产生一个漂亮却难以使用的用户界面。 第一条准则：可用：一个好的系统应该不需要任何帮助和指导，就能被那些具有系统所涉及领域的经验和知识却对该系统没有经验的用户使用。 第二条准则：效率：一个好的系统不会干预或中断那些对系统有丰富经验的熟练用户的高效使用。 第三条准则：渐进：一个好的系统在用户渐渐获取系统使用经验的同时，在知识，技能，易用性以及适应性上有相应的持续改进。 第四条准则：支持：一个好的系统能设法帮助用户轻松，简单，快速而且有趣味地完成任务。 第五条准则：环境：一个好的系统可以适应于实际配置的环境中的条件和情况。 结构原则：使用有意义且有用的方法，在用户所能清楚了解的简明一致的模型中，将有关联的事物合并，把无关联的事物分离，以此来有意识地组织用户界面。 简单化原则：使简单通用的任务易于执行， 用用户自己的语言直接沟通，并为长的操作过程提供好的快捷方式。 可视化原则：保持所有需要的选项和材料可视，并避免让一些外部的或是多余的信息来分散用户的注意力。和WYSIWYG（所见即所得）相比，我们提倡WYSIWYN：What-You-See-Is-What-You-Need. 复用原则：通过使用外部或内部的组件或行为来减少用户的再记忆或再思考，保持和目标一致性更胜于仅仅武断而得的一致。 反馈原则：使用对于用户而言简明、清晰的语言及时向用户告知：行动和解释、条件和状态的改变以及错误或例外。 容错原则：灵活和宽容。通过容许不同的输入和顺序，和合理地解释清楚合理的行为，来避免可能的错误；利用“重复”（redo）和撤销（undo）来降低错误或误用的代价。 基本用例有点象场景，也许更像它们所基于的用例。最好是通过例子来区分场景、用例和基本用例。场景是对一次非常明确的交互的具体描述。例如，一个用户拨打计算机控制的帮助热线的场景： Ian Smith在凌晨4点拨通了TechnoTech的支持热线，他听到了要求输入用户ID的提示。于是他在电话键盘上键入17682002，此后他听到了TechnoTech的产品线的菜单。 不会有人建议专门为一个通宵工作的名叫Ian Smith的人设计一个系统，但是也很难判断如何从这样的场景中获得通用的案例，以及这样的一个具体例子当中又包含有什么不必要的细节。 用例是一种通用的场景，它描述与特定用户界面的一种类型的交互。TechnoTech的用例为： 用户拨通支持热线并听到登录的提示。之后用户键入用户ID号听到菜单。 用例假定了一个特殊的用户界面，在该事件中有一个供声音输出及数字键入的电话机。在这个用例中还隐含了一个用户界面的假设。用户通过在电话按键上键入的用户ID号来鉴别他们的身份，选项被指定为声音菜单。 基本用例是一种用于表示抽象交互的广义的理想化的用例。在这个例子当中它可以用以下的形式表示： 调用帮助热线；鉴别自身；选择帮助。 换句话说，场景、用例、基本用例表示了抽象、理想化、一般化的继承关系。基本用例被简化到交互的最小化极点。如果我们仔细的设计一个用户界面并使其最接近基本用例。我们会很幸运的设计出最小而且最易于使用的系统。无论如何，我们要保证始终关注如何真正的满足用户的需求。 真正的应用系统包含了很多相互关联的基本用例。一个用例也许就是另一个用例的特例。例如，在远程银行应用系统中获取存款余额（GettingSavingBalance）就是查询帐户（QueryingAccount）的特例或是子集。一些基本用户案例也许作为附属进程依附于其他用户案例。例如在一个制图工具当中，做标记（Labeling）就作为一个设置员工职位（InsertingStaffPosition）的附属进程。另一个非常有用的关系就是由Jacobson提出的扩展（extension）。扩展是在其他用例进行期间插入，用于表示一种选择或是例外，或是变更交互的一种用例。在一个往文档中插入特殊符号的工具中，浏览符号（BrowsingSymbols）可能是插入符号（InsertingSymbol）的一个扩展。在用户看不到他们需要的符号时将用到浏览符号（BrowsingSymbols）。扩展，特殊化和次要性(?)使我们能够更缜密的描述应用程序的完整结构，因为我们不需要重复的写入或者拷贝同样的用例。它们还使我们明白用例之间如何关联，由此我们可以组织用户界面的架构。有时在一个项目开始阶段我们不能很好的了解特定用例之间的关系，但是我们可以认为他们有着共同的一些特性。 Role me over 做笔记，这是一次测验 可用性测试是制作更好的软件的重要部分。只有客观的测试才能最终解决关于什么可以工作什么不能工作等并不清晰的问题。精心构造的测试也能够揭露没有设计方针可以覆盖和没有专家检查能识别的可用性的问题。可用性测试有许多变体，但其主题是简单的：你使用户或是有效的替身在一些版本的软件前就坐并观察他们试用。你让他们持续去做，尝试，然后通过你观察分析所得到的就是什么会使系统更有趣，有时，更昂贵。有效的做法就是建立一个可用性测试的实验室，用成排的计算机和声视频设备装备起来，再配备上心理学家，技术人员和人机交互专家。这将使你可以向用户以及工业分析员指出可视化体系来证明你对于软件的可用性的最高优先权的承诺。 现场测试（Field testing）是可用性测试的贫穷的姊妹。它没有明亮的实验室供相片成册，所有需要的设备仅是笔记本和铅笔。从另一方面，低预算的现场测试也有一个优点，就是它着眼于人们在普通装备的工作环境下进行真实的操作时要做些什么。这并不令人惊奇，当技术人员走出他们的办公室进入到实验室时，倾向于以不同方式来思考和行动。测试并不能解决软件可用性的问题，因为测试来得太晚。正如他们在整体质量管理中提及的，你不能有测试质量的方式。在促成错误，然后发现它，之后设计补丁或是其它工作上已花费了太多。一开始就正确地设计和构造它或很早就发现错误将是更经济的。如果不是这样，就算是拥有成千上万的beta测试员的大量的测试程序也不能发现足够的错误。通过测试得到的大量的模糊的不足将被不确定的终止，因为没有人知道如何去修正他们或是问题已经深入以及密切的嵌到在软件的体系结构当中。你可以利用可用性测试来协调好有争议的特征，或者解决关于改变方法的途径的争论，备份大块的硬数据或大胆的证明新的偏差是正确的，但是你别指望能测试出真正有用的软件的方法。 通常基本用例可以由那些帮助我们将思考的焦点由用户转向使用的抽象模型中衍生而来。用户通过不同的角色与系统交互。角色是一种用户和系统间的抽象关系。正如软件方法论学者Rebecca Wirfs-Brock所提出的，它是共同兴趣、行为模式、和期望的集合。 再次思考在线电话目录应用程序。许多用户仅用中等频率访问这个系统，通常是要寻找单个的电话号码。这些用户用我们称之为偶然用户（Casual Caller）的角色进行交互。通常他们都确切的知道他们需要什么，但是偶尔也只是有一些模糊的、大概的想法或是部分的信息。另一类用户则是大量地访问系统，经常要和在一个特定的集合或组里的一系列的人联系。例如一个特殊职能的小组，或是所有的产品经理。公关助理（Social Coordinator）角色可供秘书、委员会主席或是意图组织一个排球队的程序员使用。然而另外一个角色是目录管理员（Directory Administrator），可以供那些有机会可能向系统加入条目、对系统进行定义或对组重新排列、更改电话号码的人使用。不同的用例用于支持不同的用户角色。例如，为了支持偶然用户角色我们需要开发一个用于查找一个名字或方位不确定的人的电话号码的用例。我们把这个用例称为寻找她（GettingWhatsHerFace）： 用户目的 系统反应 这是我知道的 显示找到的信息 『继续直至满意』 离开 “我知道的”可能包括姓的第一个字母加上部门名字，可能还是对姓的拼写的猜测或是电话号码的区号。 这个用例可以被另一个可选用例拨号（DialingNumber）扩展： 用户目的 系统反应 给我这个 拨号码 将拨号作为一个扩展分离出来的好处是可以把它作为其它用例的扩展。当以目录管理员角色创建新的条目时，拨打该号码检查是否有效，或者查找已知道确切名字的人时，这个用例都是有用的。 在上下文中 用户角色和基本用户案例帮助我们了解用户想做什么以及系统需要为用户做到什么，但是并不能告诉我们用户界面上应该有什么以及如何组织。我们可能经常直接从用户案例中获得用户界面原型，但是通常需要跨越一个很大的鸿沟。 这有助于我们在不过多顾虑到外观或者是UI小部件的准确形状或选择的情况下考虑为了支持特定用例而必须放置在用户界面上的部件。我们需要一个抽象模型以便更容易探索几条不同途径来使得在不必详细构造及设计的情况下就可以组织用户界面架构，这就是内容模型（content model）。（我们采用Contextual Inquiry中的工作环境模型的想法，Contextual Inquiry是由Karen Holtzblatt和Hugh Beyer开发的定义需求的方法） 内容模型是一种对工具和物品，控件和容器的抽象化表示，一个用户界面需要根据不同的用户角色来向用户提供一种对一个或几个用例的支持。我们需要一些简单的形状――长方形或椭圆形――来表示这些抽象工具。即时贴可以很好的满足这个需要，因为它们易于移动并且有着普遍的外观来使我们关注本质而不是用户界面小部件外观或性能上的细节。 例如，为了支持基本用例寻找她（GettingWhatsHerFace）和拨号（DialingNumber），我们可能在一开始就要定义一些我们认为用户在实施以下这些相关用例时所需要的工具和物品。 工具/控件 数字选择器 拨号器 组选择器 物品/容器 名字容器 找到的人信息的文件夹 这些最终可能会象图2那样排列。注意我们已经开始加入一些关于行为甚至是实现符号的想法。使用上下文模型有点象被我们说的低保真模型。它不怎么象真的屏幕布局或是对话框设计，但是它需要一些基本元素来支持基本用例。 深入研究 基本知识 如果你想要学习可以迎合你的用户的基本需求的软件工程知识，看一看这些资料，首先从学习Larry的文章：“基本建模：用于用户界面的用户案例”（Essential Modeling: Use Cases for User Interface）（ ACM Interaction April 1995）以及“图形导航”（Graphical Navigation）（Windows Tech Journal ,August 1994）开始。很多关于可用性的期刊包括在Constantine on Peopleware（Prentice Hall, 1995）和Jacob Nielson的Usability Engineering (Academic Press, 1993)中。更多关于用例的书籍，可以查阅Ivar Jacobson 的基于对象的软件工程（Object-Oriented Software Engineering）（Addison－Wesley，1992）和lane Graham的迁移至对象技术（Migrating to Object Technology）（Addison－Wesley，1994）。关于基本建模的经典资料依旧是Steve McMenamin和John Palmer的基本系统分析（Essential System Analysis）（Prentice Hall，1984）。 在更复杂的设计中，当我们要实现不同的用例时，需要仔细地考虑在对话框之间、屏幕之间的用户导航。为此我们需要一张导航图来在上下文交互中链接用户导航到交互序列当中。导航图包括一些表示交互场景的标记符号，和连接他们的标记有转换状态的线条。例如，在线电话目录需要支持由用户维护的个人列表以及集中的整体列表。如果一个用户需要编辑整体数据库中某个列表中的一个域，那么授权机制将检验他的权限。这些我们可以在图3的导航图中看到。 从用户到用户界面 所有这些抽象建模的目的就是为了获得密切接近用户所试图完成的工作的本质的用户界面架构设计。详细的模型和导航图将作为用户界面原型的粗略的向导。但是依然有很多工作要做，还有很大的空间留给有创意的图形设计和明智的软件工程。图4给出了明显未完工的在线电话目录应用的最初纸上原型。在这个版本中，通过微调基本用例来实现对FindingWhatherFace快速灵活的支持。随着用户的键入，系统的不断进行搜索，在下面的带有可编辑区域的行的数据表格不断挖掘。一旦根据用户填入搜索域的数据使得搜索范围有效的缩小，只要简单的双击所要的数字或者选择了数字后再点击拨号按钮就可以进行拨号。 焦点放在目标和本质上，以整个流程的使用为中心。如果不用这种方法，最终的屏幕草图或是纸上原型看上去可能是有据可依的，但结果常常是令人惊奇的难以使用。如同图5中的设计，使用了常用的控件和重叠的对话框，这是一种典型的学生式解决方案，但甚至也出现在一些管理个人信息的商业产品当中，直到你真正使用它时才能发现毛病。 尽管这些对于基本用例建模的概述使它看上去是象一个相当线性和严格的过程，实践中我们常常发现自己可以从柱子跳到即时贴。整个过程在图6中进行了描述。对于电话目录应用系统，我们始于一个单一视图的想法，把数据库分成两部分，个人列表存放在每台PC上，整体列表放在服务器上。这确实是一个内部应用软件的设计决策。我们可能会有一个极具灵感的用于拨号按钮的图标的想法，一个真实的用户界面原型的细节。在我们写出支持DirectoryAdministrator的基本用例之前，我们也许尝试了所有的方式来产生用于FindingHerFace的上下文。只有这时我们才开始完成导航图。 换句话说，这个策略确实是一个灵活的并行建模过程。所有的基本建模和用户界面原型对于交付使用都是极其重要的，但是他们不需要一个很严格的开发顺序。目标是跟随工作流程，以任何一种可以方便地构筑出简明而有活力的用户界面架构的方式来工作。 |
|
|
