（这一章的内容很多涉及开发编程的知识，比较难懂）

一、重新思考数据输入

本章讨论现有方法处理数据输入时的问题，提供一些方法让这个过程更以人为本，而不是专注于数据库的需求。

1.1数据完整 vs 数据免疫

程序往往希望用户输入的数据洁净，以达到洁净输出的目的。但是在物理世界中填表时，人们不可能达到程序希望的洁净程度，也就造成了人为计算机工作的现象。

想要计算机为人工作，就要让程序具有数据免疫。在设计程序时，让程序相信用户的输入是用户所希望的。用户想改正，无需反复提醒就能改正。而程序需要在其他地方寻求帮助：是否有模块知道如何将字母解释为文本？（真的有这种方法吗？！！）是否有修改历史记录可以解释用户的意图？

如果上面的措施都失败了，程序可以为数据添加注释，以使用户检查问题，能找到准确描述发生的事情和程序举措的完整记录。

当用户输入不正确的数据时，数据往往接近正确，程序应该提供尽可能多的帮助来纠正

1.2处理丢失数据

程序应该更加灵活，想要用户注意到有必填字段的确实信息，可以通过丰富的无模态反馈。

程序还应该帮助用户校验，数据条目必须输入有效，可以通过自动完成字段或者下拉菜单等有界控件输入。并且提供无模态来反馈输入。

只为保护少数笨蛋，就把全体当笨蛋，只会降低所有人的生产力（说得好）

1.3数据输入和规避机制

让计算机记录用户的动作，以供日后检查。

1.4审核与编辑

用户永远是对的，出错可能不是程序的问题，但是程序的责任。程序要以不唐突的方式告知用户错误，最终依靠用户自己的能力解决问题。程序应该记住用户的每个动作，确保能够明确撤销，这就是审核，但是不编辑。正面例子拼写检查。

程序应该设计的更符合人类思考事物的方式。（并能及时避免人为错误的后果）

二、重新思考数据存储

计算机要求人们区分缓存和永久存储，不够人性。基于数据库、云的网络应用自动存储，免去了用户的麻烦。iOS解决存储问题的方法是 把文件和创建文件的应用紧密联系起来，用户处理起来更简单。

2.1数据存储的问题

（本节列出问题，下节给出解决方案）

从技术上讲，每一个运行的应用程序同时存在 内存和硬盘上。而大部分人的心理模型认为 我们直接创建和修改的是单一文档。

1、保存更改--用户点击保存的概率远远大于不保存，应该默认保存不在询问是否保存（sketch软件会自动保存）。iOS Android系统已经消灭了明确保存的概念。(mac os 的保存弹框把把保存放在左边  左边和取消放在右边 一定程度上避免了误操作)

2、关闭文档但不保存--使用关闭不保存来达到撤销更改的效果不合理。（提供回到某个时间点的文件版本比较可取，可参考sketch、mac os 的备份 ）

3、另存为--用户首次使用另存为有两个功能：命名文件、选择存放文件的目录。这里要求用户熟悉文件系统，为今后的检索做好准备，否则就容易找不到文件。一旦另存为以后，想要再修改名字又会冲突，在Windows系统中。（mac os系统允许在文档界面修改文档的名称，但不能解决同时命名和选择存放目录的问题）

4、存档--另存为是复制或者管理副本的错误工具，用户另存后，如果不保存原来的文档，继续在另存的版本上进行编辑，那么其实用户一直在一个文件上进行编辑，很危险。

2.2用统一文件模型修复数据存储

设计合理的软件应该始终把文档当做一件事来处理，而不是磁盘或内存中的一个副本。

1、自动保存--废除让用户分辨缓存和硬盘的区别。自动保存的方式：一、每次操作后都自动保存。二、内存中追踪小幅改动，经过一段时间就保存到硬盘。保存在后台进程，或者用户操作的停顿期进行保存。同时给喜欢手动保存的用户提供控件。（据我观察 简书是每操作一步就保存一下）

2、创建副本--副本文档应该自动被赋予一个标准形式的名字，比如 xx副本，xx副本 2 等，同时配上时间戳。（网盘一类产品会特别需要吧）不要用你确定要创建副本这种对话框打断用户

3、命名和重命名--让用户不需要退出程序，进入文件夹来管理文件名。（mac os 中的pages sketch等都能直接在标题栏修改。对网页或者app的启发是，用户看到内容最好就能修改，不要到别的页面才能修改）

4、在文件系统中存放和移动文档--把文件放在用户能找到的地方

5、指定文档的格式--指定文件格式不应该和保存文件的操作关联起来。它放在文档属性对话框中更合适。对于绘图程序，导出更合适。

6、还原所作更改--撤销、或者还原版本

7、放弃所有更改--主菜单放一个简单的“放弃更改”，实际是“还原版本”

8、创建版本--系统自动有规律地为用户创建版本，还应该清楚地告诉用户，可以返回到每个版本创建时的文档状态。点击一下，用户就能选择一个版本，正在操作的版本也记录下来。

9、新型“文件”菜单--（整合了上面所说的几条，存储模型）

（感觉用属性来修改文档类型，总有些理解不上去）

10、文件菜单的新名字--电脑应用程序的文件菜单就该改名了，可以根据需要叫表单、发票、文档等

11、传递状态--如果文档打开，文档在文件夹中的状态应该标出来。（这个不错）

2.3是时候要改变了

按照用户心理模型而不是呈现模型重塑文件系统的好处：

1、让用户更有效率

2、无需解释界面无法呈现的行为

3、交互设计师不必在产品中融入混乱的文件系统意识，能够按照用户目标，而不是操作系统的需求安排程序中的命令。

三、重新考虑数据检索

3.1存储与检索

存储系统由容器和工具组成。在物理世界中，存储和检索密不可分。但在数字世界中，物理世界的隐喻有局限，数字系统有更好的方法寻找信息。

3.2物理世界的检索

1、按位置检索--存储系统就是检索系统。受限于记忆水平

2、基于索引的检索--图书馆是个例子。给每本书唯一编号，通过这个编号链接存储系统和检索系统。人们通过书的主题来使用检索系统找到这本书。管理员根据这本书的编号在存储系统中找到书，把书拿给读者。（所以在图书馆的计算机上找书用的是索引系统，再根据编号去书架上找到这本书，就是存储系统了）

3.3数字世界的检索

1、数字检索方法--三种基本方式：一、记住位置。二、记住名字。三、关联或者基于属性的检索。记住位置和名字是现在计算机常用的方法。但是没有使用起来关联的方法。（目前mac 系统允许用户自行为文件设置颜色标签，算是一种关联）

2、基于属性的检索系统--能够让用户根据文档的内容或者有意义的属性找到文档。mac os中的Spotlight提供了基于属性的有效检索。允许用户自己加标签也是个好方法。通过设置标签实现的检索机制通常也被称为“分众分类法”，微博中的# 就是一个案例。

3.4关系数据库 vs 数字汤

使用数据库软件对用户有两个要求：用户必须预先定义数据形式。用户必须遵循该定义。（意思是需要先定义好数据库的字段，每个字段只能代表一个属性，比如用户名就是一个字段，但是一个账号只有一个用户名）

用户的有两个事实：用户很少能提前表达自己想要什么。即使能表达，也会经常改变主意。（用户无法使用数据库的方式，因为让用户自己预先定义“字段”是一件不容易的事，用户不知道自己想要什么，或者定义后，又想改注意）

1、组织难以组织的事物--互联网提供的信息有多种维度，因此无法通过单一维度对这些信息进行分类、组织、管理

2、数据库的问题--？

3、基于属性的替代方案--分离存储和检索系统。

提出把存储看成数字汤，意思是什么信息都能往里放，然后给每个输入记录一个用于检索的令牌，然后创建一套索引，里面放上令牌的副本和键值。

有了上面的原理，在实际使用过程中，系统必须能够阅读信息，自动提取和索引信息，然后系统必须让用户非常容易地添加特殊的消息指针。

键值（key）是windows中注册表中的概念。键值位于注册表结构链末端，和文件系统的文件类似，包含当前计算机及应用程序执行时使用的实际配置信息和数据。键值包含几种数据类型，以适应不同环境的使用需求。

注册表中，是通过键和子键来管理各种信息。同时，在注册表里面的所有信息是以各种形式的键值项数据保存下来。在注册表编辑器的右窗口中，保存的都是各种键值项数据。键值项由键值名、数据类型和键值三部分组成，其格式为：“键值名：数据类型：键值”。

3.5受限的自然语言输出

除了基于属性的替代方案，还可以使用首先得语言输出的方式。

自言语言会涉及方言、口语、歧义等，因此要使用受限的自然语言。

例子：

从开发角度来说，自然语言最棘手的部分是，在很多情况下，从左侧的控件中选择选项，改变右侧控件的内容。这意味着1、为了有效实现自然语言输出，选择的语法必须提前映射好。2、控件必须根据其他控件中选择的内容动态地改变或者隐藏。3、控件本身必须能够显示数据，或者至少能够动态地加载数据。

另一个关注点是语种。

基于属性的检索引擎和自言语言输出界面两者都需要在设计和编程上付出巨大努力。但用户在管理数据能效和灵活性上获得极大好处。