通过软件架构来达到易用性

Bass在2001年写了一篇论文《Achieving Usability Through Software Architecture》,如果想看原文，地址在这里。里面列举了影响易用性的26个场景、易用性的好处、涉及易用性的软件策略以及26个场景分别对应的架构设计。时间久远，可能里面的知识已有更新，如果谁觉得有问题，不妨告知，不甚感谢！其实我一直在找同类的资料，比如开发中遇到一个问题，那么这些问题，前人都是怎么解决的，都有什么办法，罗列出来，1是什么，2是什么......虽然说现在搜索工具很强大，但是找不到这些，估计很多人跟我一样，遇到问题,自己先想一个，就开始动工了，下次遇到同样的问题，估计又要想一遍，所以造成了脑力浪费。当然自己也可以总结，把这个列表做出来，但是毕竟每个人想问题的思路不一样，所以大家如果能把自己的列表贡献出来，那整个软件行业就会获益良多，比什么开源软件不知道强多少倍，为什么这么讲？因为代码是需要看得，是有门槛的，看了1000行代码，还不知道作者想干什么，费时费力。

因为那篇论文很长，所以今天只翻译易用性的好处。并且有些地方精简了，不保证一字一句的翻译。以下就是翻译内容了：

为了构造易用性的系统，设计者必须首先保证他们的产品提供了用户工作中真正需要的功能而不是市场或者开发团队自己想象的功能。也就是说，系统的功能必须适应工作场景下的个人、组织和社会的需要。尽管识别和确定需要的功能是开发过程中最基本的一步，但是他们一般情况下都不涉及架构，所以我们这里不讨论它。

假设系统的用户所需要的功能都很好地确定了，但是这并不能保证系统的易用性也很好，在极端情况下，系统可能根本不能用。下面来谈谈易用性给系统带来的好处。

提高用户个人的效率

如果使用恰当，包括这个好处的易用性场景将改善用户的工作效率。从个人来看，这个改善可能很小，但是从整个公司或者组织来看，并且随着时间推移，这个量就会越来越大。

改善例行工作效率

在例行性工作中，用户识别条件、知道下一个目标是是什么，并且知道怎么做完成这个目标。不需要解决什么问题，所有的工作只是回忆并执行一些命令来完成任务。

在做例行性任务的时候，即使熟练的用户可能快一些但是并不会发明新方法来完成这些任务。这和问题解决性或者学习条件下的任务完全不一样，在这些情况下，用户可能需要自己想出或者需要学习一个方法来完成任务。

虽然用户知道怎么做来完成例行性任务，但是他们仍然可能犯错。实际上，观测熟练用户做例行性任务的情况显示：大约用户20%的时间是在犯错、复原中度过的。这些错误，都是因为不小心操作错了（比如按错键或者选择了旁边的菜单）而不是因为缺少知识（比如不知道按哪个键）。这些操作错误不可能全部阻止，但是有一些设计比其它设计更能减少这些错误。

(一) 加速无错任务的效率

例行性任务的时间主要花在识别条件、回想下一步目标和方法、执行命令完成任务。我们把完成任务所需要的最少时间，其中没有错误，叫做无错任务。

在现实中，实际上任务花的时间是无错任务时间加上犯错时间、复原时间。系统应该设计成最大化无错任务时间的比例，降低执行例行性任务的时间、提高用户的效率。

(二) 减轻操作错误的影响

减轻操作错误的消息影响有两个方法。首先，减少接触这些错误的机会；其次，系统可以设计成提供足够的恢复方法来容错。

提高非例行性任务效率

在非例行性任务中,用户并不非常明确该怎么做。在这种情况下，用户可能通过随机点击按钮，然后看它们的效果来体验系统。用户也可能基于以前的经验来猜这些动作命令。他们也有可能需要一个指南、一个帮助系统或者文档。

(一) 支持问题解决

当用户不知道该怎么做的时候，就需要问题解决行为。这种行为可以描述成在问题域内的搜索。当我们遇到一个新问题的时候，首先会结合以前的经验去猜解决办法，然后任意的试或者为了特定的效果而去搜索、查找。

在这里，我们假设用户理解任务的目的，但是用户需要从系统所有命令中查找自己想要的命令来达到自己的目的。

测算一个系统支持问题解决的，包括这几个方面：

l 完成一个新任务需要的时间

l 做一个新任务的时候，用户犯错的次数

l 做一个新任务的时候，用户的犯错的类型（有些类型有不可预测的副作用，有些可能只是增加了问题解决的时间）

l 从错误中恢复需要的时间（比如说支持undo的系统在这方面就比较占优势）

总的来说，减少用户犯错时间，一个设计良好的系统增加了问题解决的能力，提高了工作效率。

(二) 方便学习

人在做事的时候是一直在学习的。即使在例行工作中，人们也在每次重复中提高速度，最终达到一个高度，进一步的改进很难察觉而已。在非例行工作情况下，人们通过培训、查找说明书、自己摸索、以前的经验、推理来学习怎么做。他们也通过错误来学习，比如说错误的命令导致不该有的结果，他们就会记住而不再做这些错误的命令。

测算一个系统是否对学习支持的好包括：

l 一个任务在执行成功之前，犯错的次数（通过情况下，调查者应该排除幸运因素，比如说，用户必须连续成功执行该任务n次，才认为任务被用户掌握了）

l 用户能连续成功执行任务之前所花的时间

l 附带学习的测算。比如用户做一个任务到了一定的掌握程度，然后转向另一个新任务。第二个任务就是附带学习。

减轻因为缺少知识而导致错误的后果

用户除了不知道怎么做导致错误之外，还可能因为不知道做什么。比如，用户不知道当前情况和以前的情况有什么区别，导致用户还用以前的知识来处理，所以就导致了问题。

设计不能完全排除错误，但是可以阻止其中一部分。比如说把一些不能用的菜单变灰。因为总是有各种错误发生，所以系统应该能容纳它们。

(一) 防止错误

下面是一些平时测算一个系统是否防止错误的参数：

l 用户完成一个任务的时候，犯错的数目

l 犯错类型（有些错误可能有严重后果，有些可能没什么）

这些参数和上面测算问题解决是否支持的好的几个方面差不多，但是侧重点不一样，问题解决侧重帮助用户回到正确的路径上来，避免错误侧重帮助用户远离错误的路径，有细微的差别。

(二) 容错

因为用户有可能离开正确的轨道，错误不可避免，所以系统需要容错能力。测算的参数包括：

l 回到出错之前状态的概率

l 恢复需要的时间（如果支持Undo，则时间需要的就很少）。这个时间也包括为了恢复到之前的状态而保存数据或者状态花的时间。

减轻系统异常的影响

系统总是带有一定的异常。网络不好了，断电了，程序死了。设计不能杜绝所有的异常，但是仔细的设计可以防止其中一些。所有的系统都应该设计成能容忍异常。这一节和上面测算方法虽然没变，但是对象变了，这里的对象是系统。

避免系统异常

有关避免系统异常的测算和上面一样，可以通过用户做一件任务的时候所发生的错误类型和数目来计算。

容忍系统异常

因为系统异常总是会发生的，所以系统应该容忍他们。异常容忍的测算包括：

l 系统从错误中恢复成功的概率。

l 恢复需要的时间。这个时间也包括为了恢复保存数据或者系统状态花的时间。

提升用户自信和愉悦感

包含这个好处的场景涉及到用户对系统的感觉，有些架构决议的确可以促进或者抑制用户的自信和愉悦感，在有些组织，这个可能就是他们价值的一部分。自信和愉悦感的测量没有前面提到的基于时间或者错误的测量直接，通常可以通过问卷、面谈、或者购物行为的分析得到。