13 易用性

第13章 易用性

人们会忽略那些忽略人的设计。

—— 弗兰克・奇梅罗（Frank Chimero）

易用性关注的是用户完成期望任务的难易程度以及系统提供的用户支持类型。多年来，对易用性的关注已被证明是提高系统质量（或者更确切地说，是用户对质量的感知）以及最终用户满意度的最经济、最简便的方法之一。

易用性包括以下几个方面：

• 学习系统特性：如果用户不熟悉特定系统或其某一方面，系统可以采取哪些措施来使学习任务更容易？这可能包括提供帮助功能。
• 高效使用系统：系统可以采取哪些措施来提高用户的操作效率？这可能包括使用户能够在发出命令后重新引导系统。例如，用户可能希望暂停一项任务，执行几项操作，然后恢复该任务。
• 将用户错误的影响最小化：系统可以采取哪些措施来确保用户错误的影响最小？例如，用户可能希望取消错误发出的命令或撤销其影响。
• 使系统适应用户需求：用户（或系统本身）如何适应以使用户的任务更容易？例如，系统可能会根据用户过去的输入自动填写网址。
• 增强信心和满意度：系统采取什么措施让用户相信正在采取正确的行动？例如，提供反馈表明系统正在执行一项长期运行的任务，并显示到目前为止的完成百分比，这将增加用户对系统的信心。

专注于人机交互的研究人员使用了“用户主导”“系统主导”和“混合主导”这些术语来描述人机组合中哪一方在执行某些操作时采取主动以及交互是如何进行的。可用性场景可以结合来自这两个方面的主导。例如，在取消命令时，用户发出取消指令（用户主导），系统做出响应。然而，在取消过程中，系统可能会显示进度指示器（系统主导）。因此，取消操作可能包含混合主导。在本章中，我们将利用用户主导和系统主导之间的这种区别来讨论架构师用于实现各种场景的策略。

易用性的实现与可修改性之间存在着紧密的联系。用户界面设计过程包括生成用户界面设计，然后对其进行测试。第一次就做对的可能性极小，所以你应该计划对这个过程进行迭代——因此你应该设计你的架构，以使这种迭代不那么痛苦。这就是易用性与可修改性紧密相关的原因。在迭代过程中，希望设计中的缺陷能够得到纠正，然后这个过程会重复进行。

这种联系导致了支持用户界面设计的标准模式。事实上，要实现易用性，您能做的最有帮助的事情之一就是一遍又一遍地修改你的系统，随着你从用户那里了解到情况并发现需要改进的地方，从而让系统变得更好。

13.1 易用性的通用场景

表 13.1 列举了表征易用性的通用场景的要素。

表 13.1 易用性通用场景

场景部分	描述	可能的值
来源	触发来自何处？	最终用户（可能处于专门的角色，例如系统或网络管理员）是易用性触发的主要来源。到达系统的外部事件（用户可能对此做出反应）也可能是触发源。
触发事件	最终用户想要什么？	最终用户希望： 高效使用系统 学习使用系统 将错误的影响最小化 调整系统 配置系统
环境	触发何时到达系统？	易用性所关注的用户操作总是发生在运行时或系统配置时。 。
构件	系统的哪个部分受到触发？	常见的例子包括： 图形用户界面（GUI） 命令行界面 语音界面 触摸屏
响应	系统应该如何响应？	系统应： 为用户提供所需的功能 预测用户的需求 为用户提供适当的反馈
响应度量	如何衡量响应？	以下一项或多项： 任务时间 错误数量 学习时间 学习时间与任务时间的比率 完成的任务数量 用户满意度 用户知识的增益 成功操作与总操作的比率 发生错误时丢失的时间或数据量

图 13.1 给出了一个具体的易用性场景示例，您可以使用 表 13.1 生成：用户下载了一个新的应用程序，经过 2 分钟的尝试就能有效地使用它

图 13.1 易用性场景示例

13.2 易用性的策略

图 13.2 展示了这组易用性策略的目标。

图13.2 易用性策略的目标

Support User Initiative

支持用户主导

一旦系统在执行，通过向用户反馈系统正在做什么以及允许用户做出适当的响应，可以增强易用性。例如，接下来描述的策略——“取消”“撤销”“暂停/恢复”和“聚合”——支持用户纠正错误或提高效率。

架构师通过列举并分配系统响应用户命令的职责，来设计针对用户主导的响应。以下是一些支持用户主导的常见策略示例：

• “取消”：当用户发出取消命令时，系统必须能够监听该命令（因此，有责任设置一个持续的监听程序，该监听程序不会被正在取消的操作所阻塞）；正在被取消的活动必须终止；被取消的活动所使用的任何资源必须被释放；与被取消的活动协作的组件必须得到通知，以便它们也能采取适当的行动。

• “撤销”：为了支持撤销功能，系统必须保存足够的关于系统状态的信息，以便应用户的请求恢复到较早的状态。这种记录可以采取状态“快照”的形式——例如，检查点——或者一组可逆操作。并非所有操作都能轻易地被撤销。例如，在文档中将所有出现的字母“a”更改为字母“b”，不能通过将所有的“b”更改为“a”来撤销，因为其中一些“b”的实例可能在原始更改之前就已经存在。在这种情况下，系统必须保存更详细的更改记录。当然，有些操作根本无法撤销：例如，您无法召回已寄出的包裹或已经发射的导弹。

  撤销有多种形式。有些系统允许单次撤销（再次调用撤销会将您恢复到发出第一次撤销命令时的状态，实质上是撤销了撤销操作）。在其他系统中，多次调用撤销操作会使您逐步回退到许多之前的状态，要么达到某个限制，要么一直回退到应用程序上次打开时的状态。

• “暂停/恢复”：当用户启动了一个长时间运行的操作——比如，从服务器下载一个大文件或一组文件——提供暂停和恢复该操作的能力通常是有用的。暂停长时间运行的操作可能是为了暂时释放资源，以便将其重新分配给其他任务。

• “聚合”：当用户执行重复操作，或者以相同方式影响大量对象的操作时，提供将较低级别的对象聚合为一个组的能力是有用的，这样操作就可以应用于该组，从而使用户免除重复进行相同操作的繁琐和潜在的错误。一个例子是将幻灯片中的所有对象聚合，并将文本更改为 14 点字体。

支持系统主导

当系统采取主导时，它必须依赖于用户模型、用户正在执行的任务模型或系统状态模型。每个模型都需要各种类型的输入来完成其主导性。支持系统主导策略确定系统用于预测自身行为或用户意图的模型。封装此信息将使其更易于定制或修改。定制和修改可以基于过去的用户行为动态进行，也可以在开发期间离线进行。相关策略描述如下：

• “维护任务模型”：任务模型用于确定上下文，以便系统能够对用户试图做什么有一定的了解并提供帮助。例如，许多搜索引擎提供预测性的提前输入功能，许多邮件客户端提供拼写纠正。这两个功能都基于任务模型。
• “维护用户模型”：此模型明确表示用户对系统的了解、用户在预期响应时间方面的行为以及特定于用户或用户类别的其他方面。例如，语言学习应用程序会持续监控用户出错的领域，然后提供额外的练习来纠正这些行为。这种策略的一个特殊情况常见于用户界面“定制”，其中用户可以明确修改系统的用户模型。
• “维护系统模型”：系统维护自身的显式模型。这用于确定预期的系统行为，以便能够向用户提供适当的反馈。系统模型的常见表现形式是预测完成当前活动所需时间的进度条。

图13.3 总结了实现易用性的策略。

图13.3 易用性策略

13.3 基于策略的易用性调查问卷

基于 第 13.2 节 中描述的策略，我们可以创建一组受易用性策略启发的问题，如 表 13.2 所示。为了全面了解为支持易用性所做的架构选择，分析师提出每个问题，并将答案记录在表中。然后，这些问题的答案可以成为进一步活动的重点：文档调查、代码或其他工件的分析、代码的逆向工程等等。

表13.2 基于策略的易用性调查问卷

策略组	策略问题	支持与否（是/否）	风险	设计决策和定位	推理和假设
支持用户主导	系统是否能够监听并响应“取消”命令？
	是否可以“撤销”上一个命令，或者上几个命令？
	是否可以“暂停”然后“恢复”长时间运行的操作？
	是否可以将用户界面对象聚合为一组，并对该组应用操作？
支持系统主导	系统是否维护一个任务模型？
	系统是否维护一个用户模型？
	系统是否维护一个自身模型？

13.4 易用性模式

我们将简要讨论三种易用性模式：模型 - 视图 - 控制器（MVC）及其变体、观察者和备忘录。这些模式主要通过促进关注点分离来提高易用性，这反过来又使得用户界面的设计迭代变得容易。其他类型的模式也是可能的——包括在用户界面本身的设计中使用的模式，如面包屑导航、购物车或渐进式披露——但我们在这里不讨论它们。

模型-视图-控制器

MVC 可能是最广为人知的易用性模式。它有许多变体，例如 MVP（模型 - 视图 - 展示器）、MVVM（模型 - 视图 - 视图模型）、MVA（模型 - 视图 - 适配器）等等。本质上，所有这些模式都专注于将模型（系统底层的“业务”逻辑）与其在一个或多个用户界面视图中的实现相分离。在原始的 MVC 模型中，模型会向视图发送更新，用户可以看到并与之交互。用户交互（按键、按钮点击、鼠标移动等等）被传输到控制器，控制器将其解释为对模型的操作，然后将这些操作发送到模型，模型会相应地改变其状态。反向路径也是原始 MVC 模式的一部分。也就是说，模型可能会发生更改，控制器会向视图发送更新。

更新的发送取决于 MVC 是在一个进程中还是分布在多个进程（可能跨网络）中。如果 MVC 在一个进程中，那么使用观察者模式发送更新（在下一小节中讨论）。如果 MVC 分布在多个进程中，那么通常使用发布 - 订阅模式来发送更新（见 第 8 章）。

好处：

• 因为 MVC 促进了清晰的关注点分离，所以对系统某一方面（例如 UI 的布局（视图））的更改通常对模型或控制器没有影响。
• 此外，由于 MVC 促进了关注点分离，开发人员可以相对独立且并行地处理模式的所有方面——模型、视图和控制器。这些独立的方面也可以并行测试。
• 一个模型可以在具有不同视图的系统中使用，或者一个视图可能在具有不同模型的系统中使用。

权衡：

• 对于复杂的用户界面，MVC 可能会变得繁琐，因为信息通常分散在多个组件中。例如，如果同一模型有多个视图，对模型的更改可能需要对几个原本不相关的组件进行更改。
• 对于简单的用户界面，MVC 增加了前期的复杂性，可能无法在下游节省成本方面得到回报。
• MVC 给用户交互增加了少量延迟。虽然这通常是可以接受的，但对于需要非常低延迟的应用程序可能会有问题。

观察者

观察者模式是一种将某些功能与一个或多个视图相链接的方式。这种模式有一个“主体”——被观察的实体——以及该主体的一个或多个“观察者”。观察者需要向主体注册自己；然后，当主体的状态发生变化时，观察者会收到通知。这种模式经常用于实现 MVC（及其变体）——例如，作为一种通知模型更改的各种视图的方式。

好处：

• 此模式将某些底层功能与该功能如何呈现以及呈现多少次的问题分离开来。
• 观察者模式使得在运行时轻松更改主体和观察者之间的绑定关系。

权衡：

• 如果不需要主体的多个视图，观察者模式就过于复杂了。
• 观察者模式要求所有观察者向主体注册和注销。如果观察者忽略注销，那么它们的内存永远不会被释放，这实际上会导致内存泄漏。此外，这可能会对性能产生负面影响，因为过时的观察者将继续被调用。
• 观察者可能需要做大量工作来确定是否以及如何反映状态更新，并且每个观察者可能都需要重复这项工作。例如，假设主体正在以精细粒度更改其状态，例如温度传感器报告百分之一度的波动，但视图更新仅以整度更改。在这种存在“阻抗不匹配”的情况下，可能会浪费大量的处理资源。

备忘录

备忘录模式是实现撤销策略的常用方法。此模式具有三个主要组件：“原发器”、“管理者”和“备忘录”。原发器正在处理一些会改变其状态的事件流（源自用户交互）。管理者向原发器发送导致其状态改变的事件。当管理者即将更改原发器的状态时，它可以请求一个备忘录——现有状态的快照——并且如果需要，可以通过将备忘录传递回原发器来使用此工件恢复该现有状态。通过这种方式，管理者对状态如何管理一无所知；备忘录只是管理者使用的一种抽象。

好处：

• 这种模式的明显好处是，你将实现撤销的复杂过程以及确定要保留的状态委托给实际创建和管理该状态的类。因此，原发器的抽象得以保留，系统的其余部分不需要知道细节。

权衡：

• 根据所保存状态的性质，备忘录可能会消耗任意大量的内存，这可能会影响性能。在一个非常大的文档中，尝试剪切和粘贴许多大的部分，然后撤销所有这些操作。这很可能导致您的文本处理器明显变慢。
• 在某些编程语言中，很难将备忘录强制作为一个不透明的抽象。

13.5 扩展阅读

克莱尔·玛丽·卡拉特（Claire Marie Karat）研究了易用性与商业优势之间的关系[Karat 94]。

Jakob Nielsen也写了大量关于这个主题的文章，包括易用性ROI的计算[Nielsen 08]。

Bonnie John和Len Bass研究了易用性和软件架构之间的关系。他们列举了大约二十几种对架构有影响的可用性场景，并为这些场景提供了相关模式 [Bass 03]。

格雷格·哈特曼（Greg Hartman）将专注度定义为系统支持用户主动性并允许取消或暂停/恢复的能力 [Hartman 10] 。

13.6 问题讨论

1. 为您的汽车编写一个具体的易用性场景，明确你设置最喜欢的广播电台所需的时间。现在考虑驾驶员体验的另一部分，并创建场景来测试通用场景表（表 13.1）中响应的其他方面。

2. 易用性与安全性如何权衡？它如何在性能间权衡？

3. 挑选几个你喜欢的做类似事情的网站，例如社交网络或在线购物网站。现在从易用性通用场景（例如“预测用户的需求”）中选择一两个适当的响应，并选择相应的适当响应度量。使用您选择的响应和响应度量，比较这些网站的易用性。

4. 为什么在如此多的系统中，对话框中的取消按钮似乎没有响应？你认为这些系统中忽略了哪些架构原则？

5. 你认为为什么进度条经常表现得不稳定，一下子从 10% 跳到 90% ，然后卡在 90% ？

6. 研究 1988 年法航 296 航班在法国哈布斯海姆森林坠毁的事件。飞行员表示他们无法读取无线电高度表的数字显示或听到其声音读数。在此背景下，讨论易用性和安全性之间的关系。

---