第3章 规则

2010年10月,苹果在“Back to the Mac”大会上宣布了当时最新版的桌面操作系统Mac OS X Lion(10.7版),但直到9个月后的2011年7月才真正发布。系统发布当天就销售100万套,随后又卖出600多万套。在这个操作系统中,苹果内置了最新版的Calendar、Mail和Address Book应用。与此同时,也有一个微交互博得了不少关注,主要原因在于苹果认为它不再必须,因而删除了它。到底是哪个微交互呢?就是“另存为”。

20世纪80年代初,“保存”通常意味着“保存并离开”(施乐Star),或者“保存并离开”及“保存并继续”(苹果Lisa)。(“离开”的意思是“关闭”。)“保存并继续”最终变成了“保存”,而“保存并离开”最后就消失了。可能是因为设备内存容量更大了,能够容纳多个文档同时打开,而且处理器也不会抗议。“另存为”大约出现在80年代,与“保存副本为”一样,都是能让用户不必重命名即可保存一个文件的新版本。后来,有些软件同时支持“保存”“另存为”和“保存副本为”。随着时间推移,“另存为”已经深入人心,特别是在“撤销”命令得到广泛采用之后,“保存副本为”几乎绝迹。

在苹果决定去掉“另存为”之际,这个微交互的规则已经深入人心长达30年之久:

  • 修改文件;
  • 换个名字保存文件;
  • 后续修改只影响新文件,之前的文件保持最后一次保存时的状态。

在Mac OS X Lion中,苹果好像觉得“自动保存”既然支持用户回溯到之前的版本,那么它就可以取代“另存为”了。Lion的保存规则大致如下。

  • 修改文件。
  • 每5分钟自动保存一次改动。
  • 后续修改只影响文件最新的版本。
  • 通过“恢复到上一版”命令可以返回文件之前的版本。
  • 可以“浏览所有版本”,这个命令触发另一个微交互:浏览版本。
  • 两周之后,文件被锁定;如果不解锁或复制它,就不能再修改。

如果想另外创建一个文件,必须通过“复制”,这又是一个完全不同的微交互。

  • 使用“复制”命令创建另一个文件(副本)。
  • 新文件出现在当前文件旁边。
  • 重命名新创建(复制)的文件。
  • 后续修改影响新创建的文件;之前的文件保持最后一次(自动)保存时的状态。

新规则实际上颠倒了之前的规则:如果用户想在不同的文件中进行修改,那么他必须在修改之前就意识到这一点并做出决定。遗憾的是,这并不符合大多数人的习惯(或者更准确地说,并不符合过去30年来我们已经习以为常的思维方式)。这个变化彻底颠覆了既有的思维模型,取而代之的并非是更好的微交互,而是两个难以理解并且与大多数人的习惯背道而驰的微交互。大多数人在打开修改之后的文档时,根本用不着再打开之前的版本。版本控制是程序员的思维方式,而不是普通大众的思维方式。如果用户(偶尔)需要文档的早期版本,他们自己会手动打开。

一石激起千层浪。一时间,质疑、声讨声此起彼伏:“把Pages '09、TextEdit都有的‘另存为……’命令去掉,我看纯属多此一举。这样完全破坏了创建新文件的一个非常普遍的工作流程,即打开一个文件,然后换个新名字保存。”怒不可遏的Mac博主Pierre Igot在他的文章“Mac OS X 10.7 (Lion): Why ditch the 'Save As' command?”(http://t.cn/zHg19f5)中如是说。“我真心实意地希望那是个正确的决定,可几个月过去了,事实证明它是错误的。“Web开发者Chris Shiflett在他的文章“Apple botches 'Save As'”(http://t.cn/zHg19fG)中这么说。

苹果对这件事的回应,是在2012年发布的操作系统10.8版Mountain Lion中悄悄地恢复了“另存为”。为什么说是“悄悄地”?因为苹果没有把它恢复到菜单里,而是将其变成了一个看不见的命令,或者说一个不可见的触发器。即使如此,仍然破镜难圆,因为这一次规则又变了。Mac Performance Guidehttp://macperformanceguide.com/)的作者Lloyd Chambers在“OS X Mountain Lion: Data Loss via 'Save As'”(http://t.cn/zW0UagS)中总结了这些变化和问题:

如果你修改了文章,选择“另存为”,那么包括编辑后的原始文档和另存的副本在内,都会保存修改。这就意味着,另存的不仅是一个新文件,就连原始文件也悄无声息地保存了同样的修改。假如你注意到了这个自动操作,可以手工“撤销”保存,恢复原始版本;假如你注意不到,那么将来有一天很可能会大惑不解:“这他妈怎么回事!”(想象一下客户收到货之后发现发错了。)

也就是说,在Mountain Lion中,“另存为”的规则大致是这样的:

  • 修改文件;
  • 用新名字保存文件;
  • 后续修改影响新创建的文件,而对原始文件的修改也会被保存;
  • 可以使用“恢复到上一版”(Revert to Last)命令恢复到之前的版本。

这意味着在“保存”和“复制”之外又增加了新规则。就这样,一个简单的、深入人心的微交互,被替换成了三个不好理解的微交互,而且没有任何解释和说明。最终,苹果在Mountain Lion的一次更新中,又在“保存”对话框中增加了“在原始文档中保存修改”复选框。你说有多乱吧。

通过这个案例,我们可以吸取一些教训。如果你自己都不能轻易写出或画出一个微交互的规则,用户就更难建立它的思维模型了,除非你能够给出反馈,营造一些“虚拟”的模型,让用户知道都发生了什么。其次,除非你的规则确确实实很新颖,否则用户总会带着某种心理预期去使用它。你可以违背用户的心理预期(事实上最好的微交互都是通过颠覆那些根深蒂固的心理预期才让用户感到惊喜的),前提是你的微交互必须明显要好很多,这样它对用户的价值才明显——理想情况下,应该让用户感到有立杆见影的效果。苹果其实经常能带给人们惊喜,仅举一个小例子:填写电子邮件地址时,iOS设备的键盘上就会出现“@”符号。可是,如果你的价值反馈不能立杆见影,那么你的微交互就会让人觉得是故弄玄虚。“仅仅为了不同而不同很少能做好,而做得更好通常才会让人觉得不同。”Dieter Rams说。注1

注1:据说是1993年说的,见Klaus Kemp所著的Dieter Rams: As Little Design as Possible(Phaidon Press,2011)。Rams的话很可能是受了18世纪德国哲学家Georg Christoph Lichtenberg这句话的启发:“我不知道不同会不会更好。但我知道如果更好一定会不同。”