本章讲了防止错误和通知决定的三种策略：1、运用富视觉非模态反馈。2、撤销、恢复和可逆的历史操作。3、假设：对比和预览。
一、运用富视觉非模态反馈
本节讨论视觉信息以非模态的方式显示在应用程序的主视图，怎么做才能不打断用户，才能几乎消灭烦人的对话框。
1.1富视觉非模态反馈
富视觉非模态反馈可能是最重要的一种非模态反馈方式了。它的“富”在于能够深入全面的信息，让人了解一个进程的状态或者属性，或者当前应用程序的对象。它的“视觉”是指按习惯方式利用屏幕上的像素。它的“非模态”在于信息能够及时轻松地显示出来，既不需要用户做特殊动作或者转换模式，就能看到和理解这些反馈。
富视觉非模态反馈不适合初学者。 用户需要菜单和对话框帮助理解。（有的很好理解，初学者也能上手，比如及时对用户输入的信息给出反馈）
用来代替警告和严重错误警示的富视觉非模态反馈必须得让用户格外清楚其含义才行，确保这一类状态能传递更多信息，但不那么重要的富视觉非模态反馈得到视觉上的强调。
1.2听觉反馈
1、避免负面听觉反馈--在正常关系中，不需要像警报器一样吓人的负面声音
2、提供正面声音反馈--在物理世界中，几乎每一个对象和系统都是用声音提示成功而不是失败的。触屏键盘按键时的音效就是一种正面反馈。
二、撤销、恢复和可逆的历史操作
2.1撤销应当遵循心理模型
因为计算机不会犯错，人会犯错，所以撤销这个人专用功能，最应该贴近用户的心理模型。
1、“犯错”的用户心理模型--用户不想承认自己犯错，所以设计的时候意味着，用户做的任何事，都是他们认为正确正当的，不要责备用户。
2、撤销让人敢于探索尝试--从开发角度看 一系列的探索就是错误，但是从人文角度来看，探索是正常的。所以应用中要么断然阻止这些可预见的错误，要么协助用户探索。 撤销让用户可以安心探索。 通常用户不到用时想不起这个功能。
3、设计撤销功能--撤销不能帮助用户实现目标，但能防止意外事件将用户的努力毁掉。不同的用户会以不同的方式设想撤销。 成功的撤销能够确保支持常用工具，并且避免暗示用户操作失败。 撤销最好是整个应用通用的功能，不管是已经保存的文件，还是内嵌的文件的编辑。
2.2共同的撤销类型
1、渐增动作和过程动作--包含数据部分的操作成为渐增动作。无数据转换的动作成为过程动作。
2、隐蔽撤销和解释性撤销--用户知道，出发这一习惯用法可以撤销上一个操作，但并没有迹象指明该操作是什么，这就是隐蔽撤销。 如果习惯用法里包含了特定操作的文本或视觉描述，那么该撤销就是解释性撤销。
3、单次撤销和多次撤销
单次撤销的局限性--用户不小心覆盖了可以拯救自己的唯一撤销机会，问题出现时用户不能立即意识到错误。
多次撤销的局限性--必须按照逆向时间顺序进行撤销，不能跳跃式撤销。
4、撤销和恢复--撤销过头后，再恢复一些操作。
5、分组多次撤销--（就是把操作们都列出来，用户直接选择从哪一步开始撤销或者恢复，同样不能实现跳跃式撤销。）
2.3撤销的其他类型
1、不连续的多次撤销--可以选择撤销之前操作中的某些步骤，而不是全部撤销。这需要解释性撤销功能，这个解释会很棘手。
2、分类撤销--撤销某些类型的操作。比如退格键只能撤销文字，而不能撤销样式的操作。
3、已删除的数据缓冲区--（很多产品提供删除后，XX天后再彻底删除的功能，就是提供这种缓冲）
4、版本控制和还原--（sketch）谷歌文档支持多人协作，每次用户保存修改，都会创建一个新的版本，用户也能看到不同的版本。版本控制应该提供一份已保存版本的清单，其中包括每个文档的部分信息，供用户理解不同版本的区别，还原的时候，文档当前状态作为版本保存下来。
5、冻结--锁住数据，不能更改。在图形文档中更有用。
2.4撤销可撤销的
有的记录受商业规则或者政策的限制，不适合撤销。但是仍然可以提供给用户撤销和更改的途径，但是要留下审计痕迹。
不太相关例子：Gmail在用户点击发送后的几秒内，并未真的发出邮件，留给用户少量中止发送的时间。
三、假设：对比和预览
撤销和恢复之间的切换，实现了对比或者假设分析的功能。很多产品通过缩略图“预览”图像来进行不同操作之间和前后的对比。
