11 易用性

任何该死的傻瓜都会使事情复杂化，需要一个天才才能使事情简单化。
——艾尔伯特爱因斯坦

易用性关注的是用户完成所需任务的简易程度以及系统提供的用户支持类型。多年来，易用性被证明是提高系统质量（或者更准确地说，用户对系统质量的感受）的最便宜且最简单的方法。
易用性由以下几方面组成：
学习系统的特点。如果用户并不熟悉特定的系统或者是系统中特定的某部分，系统将如何简化系统的学习？这就需要包括提供帮助的功能。
高效地使用系统。系统将如何使用户更高效地操作系统？这可能包括用户发出命令后，重定向系统的能力。例如，用户可能希望暂停一个任务，执行其他多项操作，然后再恢复该任务。
最小化错误的影响。系统如何使产生的用户错误影响最小？例如，用户可能希望取消发出的不正确指令。
调整系统以适应用户需求。用户（或者系统本身）如何使用户的任务更容易？例如，系统可以根据用户的过去的访问纪录自动填写URL。
增加信心和满意度。系统如何使用户确信正在执行正确的操作？例如，提供表明系统正在执行一个长时间运行的任务以及任务的完成程度的反馈可以增加用户对系统的信心。

11.1易用性一般情况

易用性一般情况构成概括如下：
刺激源。最终用户（可能是一个特定的角色，比如一个系统或者网络管理员）通常是易用性的刺激源。
刺激。刺激是由于最终用户希望高效地使用系统，学会使用系统，最大限度地减少错误的影响，适应系统，或者配置系统产生的。
环境。使易用性关注于系统运行时间或者配置时间的用户操作平台。
产品。产品是与用户进行交互的系统或者系统的一特定部分。
响应。系统应提供用户所需的功能，或预执行用户的需求。
*响应估量。响应通过任务时间、错误数量、完成任务数量、用户满意度、用户掌握度、成功操作的比率、错误产生后浪费的时间长短和丢失的数据多少。

表11.1列出了描述易用性的一般情况的相关术语。
图11.1给出了一个使用表11.1生成的具体的易用性情况的例子：用户下载了一个新的应用并在两分钟后的实验后对其进行有效的使用。

11.2易用性的策略

回忆一下，易用性关注的是用户完成所需任务的容易程度和系统提供的支持类型。人际交互的研究人员们已经用过术语用户主动，系统主动和混合主动来描述人机交互中哪一方在执行特定的动作时占主动地位，以及交互如何进行。易用性场景可以将双发的主动性结合起来。比如，当取消一个命令时，用户发出一个取消指令——用户主动——然后系统应答。在取消的过程中，无论如何，系统可能提出一个进行指令——系统主动。因此，取消操作可以作为混合主动的示例。我们运用用户和系统主动之间的差别来讨论架构师用来实现不同易用性场景的策略。

图11.2展示了一系列运行时易用性策略的目标。

分离用户界面！

通过快速构建产品原型以使用户界面的实验更快捷，是一个架构师能做的使系统更加易用的最有帮助的事情之一。构建一个产品原型，或者一些原型，让真实的用户体验用户界面并给出反馈，会得到巨大的意外收获。做到这一点最好的方法就是设计能够快速改变用户界面的软件。
我们在第7章看到的可修改性策略完美地支持这一目标，特别是以下这些：

• 增强语意连贯，封装和共同分配相关责任，将用户界面的责任集中于一处。
• 限制依赖，以最小化改变用户界面时的连锁反应。
• 推迟绑定，让你在做出关于用户界面的关键决定时不用重新编程。

推迟绑定在这里非常有帮助，因为你可以预料到你的产品的用户界面将会在测试甚至在其进入市场之后面临修改的压力。

用户界面生成工具与以下策略是一致的；大部分产生一个单一的模块，该模块有一个抽象的接口以连接软件的其余部分。大部分提供在编译后仍能改变用户界面的能力。你可以根据生成模块的依赖约束来完成你的工作部分，然后你需要决定采用不同的工具。

不同的用户界面分离模式的工作发生在1980年和1990年。随着网络和模型—视图－控制器这种现代化反映网络接口的模式的出现，MVC已经成为了占主导地位的分离模式。现在 MVC 模式被内置于多种不同的框架中。（详见第 14 章中对 MVC 的讨论。）MVC 让提供多种数据视图，支持用户主动更加简单，像我们下面要讨论的那样。

许多时候，质量属性是相互矛盾的。易用性和可修改性，恰恰相反，总是相得益彰，因为让一个系统更加易用的方法是让它容易修改。无论如何，也并不总是这样。在许多系统中，业务规则驱动用户界面——比如，指定如何验证输入。为了实现这一验证，用户界面可能需要调用服务器（对性能可能造成负面影响）。为了消除这一负面影响，架构师可能选择在客户端和服务端复制这些规则，这就会给升级带来困难。哎呀，架构师的生活从来都不容易！

易用性和可修改性的实现之间是有联系的。用户界面设计过程由生成用户界面和之后的测试用户界面设计组成。修正设计中的不足，并反复重复上述过程。如果用户界面已经被构建成了系统的一部分，系统必须被修改以反映最新的设计。这就是易用性与可修改性之间的连接。这种连接导致了支持用户界面设计的标准模式（比如侧边栏）。

支持用户主动

当系统正在被执行时，通过给用户系统正在做什么的反馈和通过允许用户做出合适响应能增强易用性。比如，下面要描述的策略：取消，撤销，暂停／继续，以及聚合——支持用户改正错误或者变得更高效。

架构师通过列举和分配系统责任来响应用户命令来设计针对用户主动的响应。以下是一些用户主动的常见示例：

• 取消。当用户发出取消命令时，系统必须服从（因此，无论是什么活动被取消，都需要一个恒定的不被屏蔽的监听器）；被取消的指令必须终止；任何被取消的指令正在使用的资源在执行取消后必须被释放；与被取消指令合作的组建必须被通知，以便它们采取合适的操作。
• 撤销。要支持撤销的功能，系统必须拥有足够数量的关于系统状态的信息，使一个早期的状态能够按照用户的要求被存储。这样的一条纪录大概以“快照”的形式存放——举个例子，检查点——或者说一系列可逆操作。不是所有的操作都很容易逆转：比如说，将一个文件中所有出现的字母“a”全部换成字母“b”不能被将所有的“b”替换成“a”逆转，因为一些“b”可能是在原始改变之前就存在的。在这种情况下系统必须保存更加详细的修改纪录。当然，一些操作，比如响铃，是不能被撤销的。
• 暂停／继续。当用户已经开始了一个长时间运行的操作——比如说，从某台服务器上下载一个很大的文件或者一系列文件——提供暂停和继续操作通常是有用的。高效地暂停一个长时间运行的操作要求暂时性释放资源的能力，以便这些资源能够重新分配给其他的任务。
• 聚合。当一个用户在进行有代表性的操作时，或者以同种方式影响很大数量的对象的操作，提供将低级对象聚合成单个群组的能力是非常有用的，这样，操作就能被应用到群组，将用户从重复操作的苦活儿（以及潜在的错误）中解救出来。比如，将一张幻灯片的所有对象聚合起来，将文本字体改成14号。

支持系统主动

当系统占主动时，它一定依赖于用户的一个模型，用户正在进行的任务或者系统状态本身。每个模型要求不同种类的输入以完成其主动性。支持系统主动的策略是识别系统使用的模型以预测其自身行为或者用户意图。封装这些信息可以让系统更加容易裁减或修改。在开发过程中的裁减和修改可以基于过去用户的行为动态地进行或者离线进行。以下是一些策略：

• 维持任务模型。任务模型被用于决定背景，于是系统能够知道用户正在尝试什么，进而提供帮助。比如，知道句子以大写字母开头将允许一个应用在该位置将小写的字母纠正。
• 维持用户模型。这个模型明确地代表了用户对系统的了解，在预期时间内的用户行为，和其他特别方面的用户或某一类用户。比如，维持一个用户模型，以允许系统控制鼠标选择的策略，这样当需要滚动的时候，不是所有的文件都会被选中。或者一个模型能够控制自动提供给用户帮助和建议的数量。这个策略的一个特例是总能在用户界面中找到用户自定义，在该处用户可以明确地修改系统的用户模型。
• 维持系统模型。在这里，系统维持着自己明确的模型。这被用于确定期待的系统动作，从而能给用户合适的反馈。系统模式的通常表现形式是预测完成当前任务所需时间的进度条。

图11.3展示了实现易用性策略的摘要