Chapter11 优使性

目录

优使性总体情景包括以下部分：

优使性策略

分离用户界面！

支持用户主动性

支持系统主动性

设计优使性的检查清单表

总结

---

任何愚蠢的人都可以制造复杂的东西；制造简单的东西需要天才。

——阿尔伯特·爱因斯坦

优使性关注用户完成所需任务的难易程度以及系统提供的用户支持类型。多年来，专注于优使性已经被证明是改进系统质量（更准确地说，用户对质量的感知）的最廉价和最简单的方法之一。

优使性包括以下几个方面：

• 学习系统功能：如果用户对特定系统或特定方面不熟悉，系统可以采取哪些措施使学习任务更容易？这可能包括提供帮助功能。
• 高效使用系统：系统可以采取哪些措施使用户在操作中更加高效？这可能包括用户能够在发出命令后重新定向系统。例如，用户可能希望暂停一个任务，执行多个操作，然后恢复该任务。
• 减小错误的影响：系统可以采取哪些措施，以使用户的错误产生最小的影响？例如，用户可能希望取消错误发出的命令。
• 使系统适应用户需求：用户（或系统本身）如何适应以使用户的任务更容易？例如，系统可以基于用户过去的输入自动填充URL。
• 增强信心和满意度：系统可以采取哪些措施来让用户相信正在采取正确的操作？例如，提供反馈，指示系统正在执行长时间运行的任务以及任务完成的程度，将增加用户对系统的信心。

优使性总体情景包括以下部分：

• 刺激源（Source of stimulus）：刺激源始终是最终用户（可能是专业角色，如系统管理员或网络管理员），用于优使性的刺激总是来自最终用户。
• 刺激（Stimulus）：刺激是最终用户希望高效使用系统、学习使用系统、最小化错误的影响、适应系统或配置系统。
• 环境（Environment）：优使性关心的用户操作总是发生在运行时或系统配置时间。
• 构件（Artifact）：构件是用户正在与之交互的系统或系统的具体部分。
• 响应（Response）：系统应该要么提供用户所需的功能，要么预测用户的需求。
• 响应度量（Response measure）：响应可以通过任务时间、错误数量、已完成的任务数量、用户满意度、用户知识的增加、成功操作与总操作的比率，或在发生错误时丢失的时间或数据量来衡量。

表11.1列举了表征优使性的一般情景的元素。

优使性策略

请注意，优使性关注用户完成所需任务的难易程度，以及系统为用户提供的支持类型。人机交互领域的研究人员使用“用户主动性”、“系统主动性”和“混合主动性”这些术语来描述人机对中哪一方采取主动执行某些操作以及交互如何进行。优使性情景可以结合来自两种视角的主动性。例如，当取消命令时，用户发出“取消用户主动性”，系统做出响应。然而，在取消期间，系统可能会显示一个进度指示系统主动性。因此，取消可以展示混合主动性。我们使用用户和系统主动性之间的区别来讨论架构师用于实现各种情景的策略。

图11.2显示了运行时优使性策略集的目标。

分离用户界面！

架构师为了提高系统的优使性，最有帮助的做法之一是通过构建快速原型来促进用户界面的实验。构建原型，或者多个原型，让真实用户体验界面并提供反馈，将产生巨大的回报。要做到这一点，最好的方法是设计软件，使用户界面可以快速更改。

在第7章中，我们看到的可修改性策略完全支持这一目标，特别是以下策略：

• 增加语义连贯性，封装和定位相关职责，将用户界面职责局部化到一个地方
• 限制依赖关系，当用户界面发生变化时，最小化对其他软件的涟漪效应
• 推迟绑定，使您可以在无需重新编码的情况下进行关键用户界面选择

推迟绑定在这里尤其有帮助，因为您可以期望在测试期间甚至在上市后，您的产品的用户界面将面临改变的压力。用户界面生成工具与这些策略是一致的；大多数生成一个具有与软件的其余部分的抽象接口的单个模块。许多提供了在编译后更改用户界面的能力。如果以后决定采用不同的工具，您可以通过限制对生成模块的依赖来做出自己的努力。

在20世纪80年代和90年代，不同的用户界面分离模式中发生了很多工作。随着Web的出现和模型-视图-控制器（MVC）模式的现代化以反映Web界面，MVC已成为主导的分离模式。现在MVC模式内置在各种不同的框架中。 （有关MVC的讨论，请参见第14章。）MVC使提供数据的多个视图变得容易，支持用户主动性，正如我们下面所讨论的。

许多时候，质量属性之间存在冲突。然而，优使性和可修改性通常相辅相成，因为提高系统的优使性最好的方法之一是使其可修改。然而，这并不总是如此。在许多系统中，业务规则驱动用户界面，例如，规定如何验证输入。为了实现此验证，用户界面可能需要调用服务器（这可能会对性能产生负面影响）。为了规避这种性能成本，架构师可能会选择在客户端和服务器中复制这些规则，这将使演化变得困难。然而，架构师的工作并不总是轻松的！

优使性和可修改性之间存在联系。用户界面设计过程包括生成然后测试用户界面设计。设计中的缺陷会得到纠正，然后该过程重复进行。如果用户界面已经构建为系统的一部分，那么系统必须进行修改以反映最新的设计。因此，与可修改性之间存在联系。这种联系已经导致了支持用户界面设计的标准模式（见边栏）。

支持用户主动性

一旦系统开始执行，通过向用户提供系统正在执行的反馈信息并允许用户做出适当响应，可以增强优使性。例如，接下来描述的策略——取消、撤销、暂停/恢复和聚合——可以帮助用户纠正错误或提高效率。
架构师通过列举和分配系统对用户命令的响应责任来为用户主动性设计响应。以下是一些用户主动性的常见示例：

• 取消。当用户发出取消命令时，系统必须监听它（因此需要具有不会被正在取消的操作阻塞的常驻侦听器）；正在取消的命令必须终止；被取消命令使用的任何资源必须被释放；与被取消命令协作的组件必须被通知，以便它们也可以采取适当的操作。
• 撤销。为了支持撤销的能力，系统必须保留足够多关于系统状态的信息，以便可以还原先前的状态，即使是在系统已经在运行之后。这种记录可以采用状态“快照”的形式，例如检查点，或者作为一组可逆操作。并非所有操作都可以轻松撤销，例如，将文档中的所有字母“a”更改为字母“b”的操作无法通过将所有“b”的实例更改为“a”来撤销，因为其中一些“b”的实例可能是在原始更改之前存在的。在这种情况下，系统必须保持更复杂的更改记录。当然，某些操作，例如响铃，无法撤销。
• 暂停/恢复。当用户启动长时间运行的操作时，例如从服务器下载大文件或文件集，通常有必要提供暂停和恢复操作的能力。有效地暂停长时间运行的操作需要能够暂时释放资源，以便可以将它们重新分配给其他任务。
• 聚合。当用户执行重复操作或以相同方式影响大量对象的操作时，将较低级对象聚合成单一组，以便可以将操作应用于该组，从而使用户不必重复执行相同操作（以及潜在错误）。例如，将幻灯片中的所有对象进行聚合，并将文本更改为14磅字体。

支持系统主动性

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

• 维护任务模型。任务模型用于确定上下文，以便系统能够了解用户试图做什么并提供帮助。例如，知道句子以大写字母开头，可以让应用程序在该位置更正小写字母。
• 维护用户模型。此模型明确表示用户对系统的知识、用户行为以及与用户或用户类别相关的预期响应时间等方面的知识。例如，维护用户模型允让系统控制鼠标选择的速度，以便在需要滚动时不会选择文档的全部内容。或者模型可以控制系统自动为用户提供的帮助和建议的数量。用户界面定制中通常找到这一策略的一个特殊情况，用户可以明确修改系统的用户模型。
• 维护系统模型。在这里，系统维护其自身的显式模型。这用于确定预期的系统行为，以便向用户提供适当的反馈。系统模型的常见体现是预测完成当前活动所需时间的进度条。 

图11.3总结了实现优使性的策略。

设计优使性的检查清单表

11.2是一个支持优使性设计和分析过程的检查清单。

总结

支持优使性的体系结构既涉及允许用户在各种情况下采取主动行动，例如取消长时间运行的命令，撤销已完成的命令以及聚合数据和命令。

为了能够有效地预测用户或系统的响应，系统必须维护用户、系统自身和正在执行的任务的明确模型。

此外，支持用户界面设计过程和支持可修改性之间存在着重要的联系。这种关系通过强制用户界面与系统的其余部分分离的设计模式（例如Model-View-Controller（MVC）模式）得到强化。