http://book.csdn.net/bookfiles/552/

大师品软件——软件之痛与应对之道 1.1 计算机软件的历史
http://book.csdn.net/ 2007-11-6 14:28:00
图书导读 当前章节:1.1 计算机软件的历史·目录·前言·译者序·1.2 为什么到现在还是如此糟糕·1.3 控制能力和易用性·1.4 用户不需要了解程序的工作原理

“这样的书肯定卖不出去，”我嘲笑书店中的那些书名，“有谁会公开买一本要读者宣称自己是个笨蛋的书？这就像让成年男性去买一支标有‘加小码’的安全套一样。”

我们都知道这是如何造就的，不是吗？《DOS傻瓜书》(DOS for Dummies)及其姊妹篇《Windows傻瓜书》(Windows for Dummies)成为史上最畅销的计算机类图书。这种概念已经远远超出了计算机的范畴，很多稀奇古怪的书名出现了：Wine for Dummies、Saltwater for Dummies以及Breast Cancer for Dummies。为了寻找能够出版本书的出版社，我购买了Getting Your Book Published for Dummies，根据书中的数据，这个系列的书籍累计销售量已经超过了1亿册。

计算机让用户感觉到自己很愚蠢。文明的有识之士不能让计算机执行他们的命令，他们不去讨伐微软公司和比尔·盖茨，却反而谴责自己，“我一定是个笨蛋。”在这个社会中，如果做错事的人都没有责任，如果顾客自已不小心泼洒了咖啡反而投诉所在的餐厅，那么使用户不分青红皂白地怪罪自己就应该算是一项非凡的成就，尽管它可能并不是软件厂商追求的主要目标。为什么程序员设计出来的应用程序会让人们有这种感觉？为什么人们这么温顺地接受自己计算机的虐待？

1.1 计算机软件的历史
最早的计算机程序设计师们并不在乎自己的软件是否好用。解决手头上的问题(比如让打印机正确地将文字打印在纸上)已经非常困难了，没有人能够挤出时间或者资金来改善程序的易用性。计算机的计算成本非常高，远比用户的时间宝贵。为了降低成本，就强迫人类用户记住复杂的命令，而不利用计算机给用户提供一个方便的菜单。而现在，两者的相对成本颠倒过来了，但是这个行业中大部分年龄超过30岁的人都在这种环境中成长起来。现在，这个经历不能帮助我们，反而左右了我们的思维习惯，不管我们多么努力地试图摆脱它的影响。想想那些经历过20世纪30年代大萧条时期的长辈们，他们甚至在今天都不忍心丢掉只有一个破洞的袜子。

就像在20世纪最初几年驾驶汽车一样，计算机的早期用户都知道使用计算机是一件麻烦的事情，但是我们很少因此感到失望。因为几乎所有的用户自身就是程序员。很少有人会发现需要或者期望计算机更加好用。我们接受了各种困难：机时配给制、神秘的命令、晦涩的文档等，就像机械工程师们能够接受手摇引擎和经常出现的轮胎破损一样。计算机在当时算是最好的东西。我们很高兴完成了一些重要的计算工作(人口普查、破译敌人的密码等)，机械工程师们(有了机械行业的新工作，虽然不是很舒服)非常高兴再也不用打扫牲口棚。我们喜欢摆弄自己的程序，按照程序设计师预想之外的方式使用这些程序，就像早期的“有车族”喜欢自行修理引擎。如果某人告诉亨利·福特想在自己的T型汽车上安装一个茶杯架，这个人一定会被福特取笑。

那时候，普遍存在着一种认识，即让程序易于使用很明显就是错误的想法。如果程序难以编写，那么就应该难以使用，因为只有那些能够通过艰苦的脑力思考证明自己够格的人才配得上从程序员的劳动中获取益处。我曾记得，(1975年刚上大学的时候)当我发现在我所使用过的第一台大型机上打印文档的命令不是Print或者P而是字母Q(因为打印文档的时候需要将其放入打印队列［Queue］)，我是多么的自豪。我学会了一个术语。我正成长为“圈内人”。我多聪明！

但是随着硬件越来越便宜，计算机已经从放在高档的玻璃空调房由专职人员伺候的阶段，发展到技术爱好者的工作台，继而摆到了企业和普通老百姓的桌面上，它们必须变得更加易于使用。所以应用程序的开发人员不得不开始花时间和金钱来设计用户能够实际使用的程序。那么为什么未能奏效呢？

1.2 为什么到现在还是如此糟糕
与人类用户打交道的计算机程序被称为“用户界面(user interface)”，它的作用是从用户那里获取命令和输入数据，并将消息和输出数据显示给用户。跟计算的其他领域一样，用户界面需要很高的专业技能，而大多数程序员并不知道这些技能。他们之所以成为程序员，是因为他们擅长与微处理器—— 计算机的心脏—— 沟通。但是按照定义，和用户界面进行沟通的对象与硬件和软件完全不同：他是活生生的人。这很好理解，与那些没有错误、呆板的逻辑芯片交互所需的技巧跟与容易犯错、智能的感性人类沟通所需的技巧完全不同。但是人们往往自动假设精通前一种技巧的人也同样擅长后者。但事实往往不是这样，而且他们几乎从来不明白自己不擅长此类沟通。这就是程序员设计的用户界面为何如此糟糕的原因，至少在一个使用过这些垃圾软件的可怜的笨蛋看来确是如此。

为什么会这样？程序员必须具备一定的智力水平才能胜任程序设计工作。大多数程序员擅长于跟芯片打交道，否则他们就会被炒鱿鱼，并鼓励他们从事其他更加有利于社会的行业，比如维修房顶。那么为什么在设计用户界面的时候，他们就变得如此白痴呢？其中一个简单的原因就是，他们不了解自己的用户，同样，这也是隐藏在所有沟通失败背后的原因。

每个程序员都认为自己完全了解用户想要什么。毕竟，他们整天都在使用计算机，而且每天都在使用，所以他们理应知道。他告诉自己，“如果我按照自己喜欢的风格设计用户界面，用户也一定会喜欢。”这是一个严重的错误！除非他的程序的用户是一个计算机技术天才，否则他的用户绝对不可能理解他。我要求上我讲授的计算机程序设计课程的学生将下面这句话以及“无用输入，无用输出(Garbage In, Garbage Out)”和“总是洗牌(Always cut the cards)”这两个短语铭记于心：

认真了解用户，用户并不是您自己。

这是我在用户界面设计上的第一条、最后一条也是唯一的一条准则。

举一个最简单的例子，考虑个人理财程序，比如Quicken或者微软的Money。通常是在几个星期之内只需使用几个小时的时间。希望用户像使用每天都用到的应用程序那样去记住前一次使用过程中执行过的那么多程序操作，用户做不到，而且他们也不愿意这样做。因此，他需要更多的提示和指导，而对于每天都在使用这些软件的用户(比如程序员)来讲，这些提示和指导就是让人讨厌的干扰信息。不可能让程序员削足适履去适应普通用户的习惯。程序员对程序的细节了解太多，没有办法想象出那些对该程序没有多少了解的用户的感受。

程序员认为用户跟自己一样，在此错误观念之下进行用户界面设计，就会犯下两类主要的错误。他们把控制能力看得比易用性更加重要，集中精力制造复杂的程序，而不是让容易的事情简单化。而且他们期待用户学习并了解他们的程序的内在工作机制，而不是采用其他的方式。这两种错误我都曾经犯过，而现在为曾经采用的愚蠢而幼稚的方法感到后悔。

1.3 控制能力和易用性
每次给软件公司的员工讲课时，我都要问有多少学生开车的时候使用手动换挡变速器(我自己就是这样开车的)。通常有半数左右的学生使用手动换挡。然后我问他们，如果妻子要求他们手动换档或者因为快成了像我这样的老头而需要驾驭手动换档的小型车，又有多少人会这样做。通常剩下的那些学生中又有一半的人举起手来。我又问道，“现在你是否同意，比起自动换挡驾驶，手动换档需要更多的时间和精力去学习和使用，但是如果处理得当，你就能够获得更多的控制能力和更好的性能？”他们知道自己正在被带往某个他们并不想去的地方，但是他们并不是总能够回避这个结论，所以他们将信将疑。“那么你认为手动换挡的汽车在美国汽车销售总量中所占的百分比是多少？”他们在下面不自信地嘟囔着，“我打赌它一定比较低，少于30％？”他们希望是这个比例。汽车销售统计表明，这个比值大概在10％~14％之间变动。为了方便比较，就让我们假设是12.5％，也就是1/8。

这就意味着有3/4的程序员在花大笔钱购买汽车的时候，更加重视控制能力和性能，他们愿意在该产品的生命期内不断地付出更多努力来争取更多的控制并发挥更高的性能。而面临同样选择的时候，一般大众中只有1/8的人会做出这样的选择。而且，实际上这个数字还要更低一些，因为程序员中所有的这3/4部分也属于这1/8大众。愿意付出额外努力的普通老百姓的比例基本上就是零。程序员更加看中控制能力。而用户更加看中易用性。您的用户并不是您自己。

下面这个示例就在这方面犯了错误。AT&T的查号服务(Directory Assistance)曾经非常简单好用。在您询问某人的号码之后，自动应答会说，“您所查询的号码是555-1212。请记录。”如果您不挂机，它就不停地重复这个号码，这样就可以确保您正确地记下号码。非常简单，且非常好用。绝对不可能把事情搞得一团糟。这样做很好。之后，AT&T增加了自动拨打功能。语音提示，“您所查询的号码是555-1212，再加50美分就可以自动接通这个号码。接受按1，拒绝按2。”这件容易的事情曾经是多么简单，而这项较新的更加强大的功能是为那些愿意为此项服务付费的人准备的。任何不需要这项新功能的人可以简单地挂机。于是，某些笨蛋(idoit，原文如此，参见下面的注解)想出了一个非常愚蠢的方法。上次我试用了一下AT&T的查号服务，它的语音提示为，“您所查询的号码可以自动接通，费用为50美分。接受按1，拒绝按2。”语音提示并不会告诉您查到的号码，除非您按键选择。于是我不得不将电话从我的耳旁拿开，眯起眼睛找到键盘(过了45岁之后视力下降，做这件事就比较困难了)，然后放下另一只手中拿着的准备用来记录电话号码的铅笔，按下正确的号码，然后再次拿起铅笔，把话筒再次贴到耳旁。这个时候，语音提示才会告之所查询的号码是555-1212。这为那些功能强大的复杂操作提供了可能性，但也使得一件本该很容易的事情变得不再简单。很明显这个系统的设计者更加偏重控制能力，而不是易用性，但是我敢保证他的用户并不这样认为。应该强迫那些将这项功能强加给这个世界的人每天完成500次这样的操作。他周末一定会吞枪自尽。

与之形成鲜明对比的是，移动运营商Verizon公司将易用性提高到一个新的水平。Verizon发现绝大部分用户呼叫查号服务的原因是他希望立即拨打这个人的电话，那么为什么不直接接通呢？当我使用移动电话拨打查号服务时，自动语音提示为，“您所查询的号码是555-1212。现在就为您接通。”这个动作会自动发生，没有任何提示，甚至不需要我进行任何思考。刚查到的新号码将会自动保存到手机的“已拔电话”列表中，如果我需要这个号码的话，我就可以将其添加到我的通讯录中。少数只想记下号码的人可以简单地挂机，正如平时所做的一样。让容易的事情保持简单。而且还让具有强大功能的复杂事情也简单化了。这个设计非常好，而AT&T的设计却相当糟糕。

1.4 用户不需要了解程序的工作原理
程序员在设计用户界面时所犯的第二个错误是，强迫用户理解他们的程序的内部工作机制。程序员不去调整用户界面适应用户的思维过程，而是强迫用户适应他的思维方式。而且，他往往看不到这种方法存在的问题。他会说，“我的程序就是这样工作的”。这让任何想询问用户界面为什么按照这种方式运行的人倍感困惑。

这里有一个示例很好地说明了我的意思。打开Windows记事本，或者任何其他类型的编辑器程序，然后随便输入一些文字。现在，在主菜单中选择“文件”|“退出”，或者单击标题栏右上角的X按钮。您将会看到一个消息框，如图1-1所示。



图1-1 记事本程序询问用户是否保存修改

这个对话框所询问的到底是什么意思？它似乎在说某些文件被修改了，但是我没有在任何地方看到文件。“保存修改”到底是什么意思？

答案就是记事本通常用来编辑存放在计算机硬盘上的文档(计算机技术人员通常这样称呼文件)。当您打开某个文档的时候，记事本将其从硬盘上复制到内存中。当您通过键盘添加或者删除文字时，程序修改的是内存副本的内容。(在这个示例中，我们没有打开已有的文档，但是程序在内存中创建了一个名为“无标题”的文档。)当您完成了这份文档的编辑工作之后，程序就将内存副本写回到硬盘上去，这个操作被称为“保存文件”。否则，您所做的工作将会被丢弃，那时候追悔莫及。

之所以按照这种方式(将文档从硬盘复制到内存，然后编辑内存副本，最后写回到硬盘)编写程序，是因为对程序员来说这样做最简单。并且这样编写程序并不坏。从硬盘上读写字符(旋转硬盘的可移动部件)的速度要比内存操作(电子以光速移动)慢上数千倍，所以对于这种简单的程序内部工作这可能是最好的方式。

但是程序员设计的用户界面直接将这些工作机制暴露出来。为什么这样做不好呢？他正在强迫您理解他正是按照这种方式编写这个程序。要想成功地使用程序，用户本不应该去了解或者关心程序的内部工作机制，就像为了开动汽车并不需要去了解或者关心汽车引擎是使用燃料喷射还是汽化器。

人们通常不会按照程序工作的方式思考。大多人认为编辑计算机文档与使用笔和纸的方式类似。使用铅笔做记号，这些记号将留在纸上面。如果您不想要了，还可以将这些记号擦除。如果全部内容都不想要了，可以将纸揉成一团扔掉。您所做的工作将会被永久性地保存下来，除非您花费额外的精力将其消除。但是记事本并没有给您这样的机会。每个计算机新手都遇到过这种情况：选择“否”，于是记事本将其所做的工作全部丢弃，只能寄希望于这些工作并不是很多。最终，用户学会了像计算机程序那样思考，更加确切地说，是像编写这个糟糕程序的程序员那样思考。用户界面设计专家艾伦·库珀这样定义“懂电脑的用户(computer-literate user)”：被伤害过无数次的用户，以至于他们的伤疤足够厚，已经感觉不到任何疼痛。

如果这个对话框的问题改成“放弃您刚才所做的所有工作吗？”，那么问题本身及其答案就会更加清晰。这实际上是同一个问题，但它站在用户的角度来问这个问题，而不是站在程序员的角度。但是程序员只考虑自己程序的操作，即写回磁盘，并询问用户是否执行这项操作。他要求用户适应他的思维习惯，而不曾考虑过用户的习惯。如果曾经考虑过用户习惯的话，他就会采用不同的处理方式。他可能会发现自己的询问方式非常可笑，并会设计一套更好的用户界面，即使底层的程序还是按照原来的方式工作。

微软的Money个人理财软件就是一个比较好的示例。它的设计人员了解到用户的思维模型就是支票簿，程序的屏幕显示看上去就像是一张支票簿(图1-2)。这会让新用户感觉熟悉和(相对)舒服。当前正在处理的支票使用一种不同的颜色显示。填写支票的各项详细信息并按下回车键。这张支票就被上移，颜色也变成跟其他支票一样的颜色，工作区域出现一张新的空白支票。如果您开启了音效的话，就会听到收银机那样的“咔叮”响声。程序不会询问是否保存支票。按下回车键就告诉程序您想保存信息。如果之后改变了想法，希望修改某张支票的数据，或者将其完全删除，只需要在支票簿中单击这张支票，然后键入新的信息。程序何时将数据从硬盘读取到内存？又在何时将其写回硬盘？我们并不知道，也不需要关心。没有人想这样做。程序的用户界面是按照您的思维模型设计的，而不会强迫您去学习并考虑程序员的内部设计决策。



图1-2 微软的Money用户界面，看上去像一本支票簿

这是一种好得多的用户界面设计方式。作为一名用户，我并不希望考虑程序本身。我希望考虑的是程序能够为我做的事情，举例来说，是否有足够的钱来支付账单？另一位用户界面设计专家唐纳德·诺曼在他的一本著作的书名中很好地表达了这个意思：The Invisible Computer(译者注：《看不见的计算机》，该书由麻省理工大学出版社1999年出版)。理想情况下，用户完全不需要考虑到程序。

这是导致程序如此糟糕的主要原因，也是让用户感觉自己愚蠢的主要原因。用户被迫像程序员那样进行思考，即使用户并不从事也不想从事程序设计工作。用户本不该如此。人们不像机械师那样思考也照样能够驾驶，不像医生那样思考也照样可以服用阿司匹林，不像面包师那样思考也照样能烤汉堡包。用户拿自己辛辛苦苦挣来的钱购买了这些软件产品。程序员的工作就应该调整以适应用户的思维习惯，而不是其他的方式。

1.5 糟糕的设计和优秀的设计
还有一个例子用来说明程序员将用户界面设计得一团糟，让用户感觉很蠢。在Windows桌面上，随便选择一个文档。然后按“删除(Delete)”键。除非您知道如何禁用该功能，否则您将会看到如图1-3所示的确认对话框，询问您是否真的想删除这个文件。



图1-3 Windows回收站弹出的毫无用处的确认对话框

您是否曾经说过，哪怕只有一次，“哦！我并不想这样做。谢谢您的提醒。”然后单击“否(NO)”？您看见过或者听说过别人这样做吗？反正我从来没有。确认机制被大量滥用，其结果非常具有讽刺意味：它变得完全没有用处。这个对话框不断地扮演着“狼来了”的角色，就像伊索寓言中的牧羊童，没有人会注意到它，即便它提醒您不要删除自己真的不想删除的文件。如此频繁地看到这个对话框，导致它已经起不到任何警示作用了。人们在处理这些对话框的时候，总是无意识地单击“确定(Yes)”。它不能为您提供任何安全性。但是，还好我们能够关闭这个对话框。然而，还有很多这样的对话框根本去不掉，这些对话框完全没有必要存在，无论是在任何地方，任何时候，都不应该存在。

日常生活中的其他事情都不需要确认。当您将要转动汽车发动机钥匙的时候，它不会问您，“您真的打算开启引擎吗？”。当您把选好的杂货放到超市的收银机前时，超市的收银员不会问您，“您确定要买这些东西吗？”。想想在您发现Amazon.com自创的1-Click订购功能之后，您从它这里购买了多少本图书。

为什么程序员总是要求确认呢？他们这样做的理由是，他们认为用户糊涂了，用户不知道自己刚才命令程序所做的事情所导致的后果。假设其他部分的用户界面也同样糟糕，这个理由或许能够成立。但是要求用户进行确认并不能解决这个问题。如果用户输入了一些触发该对话框的什么命令，他会感到困惑，但是当他看见这个确认对话框的时候会更加感到困惑。既然程序似乎不情愿执行用户交给它的命令，用户就会认为自己做错了某些事情。程序员使用确认对话框就可以不做以下几件事情：(1)清晰地向用户解释他在做什么，这样用户就不会试图做那些他不想做的事情；(2)如果用户确实做了一些后来感到后悔的事情，就为他们提供一项恢复措施。

但是用户真的做错某件事情怎么办？假设您在超市里面挑选了一只手电筒，但是所附带的电池型号不对。那么细心的店员会不会询问您，“您确定要买这些吗？”优秀的用户界面难道不应该让用户不去犯这样的错误吗？当然应该这样做，而且计算机程序的一大优势就是能够做到这一点。但是如果每次都盲目地询问用户 “您确定要执行刚才告诉我的那些事情吗？”，这就达不到预期的效果。相反，优秀的用户界面应该在最开始的时候就防止问题的出现。在销售手电筒的网页上面，或许可以添加一个复选框：“包含电池”。在默认情况下，这个复选框处于选中的状态，因为如果没有电池，手电筒就不会亮。而对于那些已经有很多电池的买家来说，可以将这个选项去掉。或者更好的办法是，将电池放到手电筒的包装里面，这样在拆开包装之后就可以立即使用，根本不需要考虑电池的问题。聪明的用户界面设计者应该在开始编写程序之前就想好怎么设计界面。如果程序员认为需要确认框，那么我敢向您保证，他一定把用户界面的其他某个部分搞砸了，这部分如果做得好的话本来可以消除对确认框的需求。他可能从未尝试过这样做，但是他本来应该如此。确认机制是为那些懒惰的或者粗心的程序员准备的，而每位用户都要为此付费。而且这种机制根本没有任何实际效果。

但是难道您不希望对那些具有破坏性的动作(比如删除某个文件)进行确认吗？不，确实不想这么做。启动汽车或者购买杂货不需要确认，因为这些事情都很简单，如果您突然发现自己犯了错误，也很容易反悔。您只需要熄灭点火器或者退还不想要的货物。计算机程序能够快速而又容易地复制文档和内存。这可以让程序员能够为用户提供反向执行已经完成的操作。这种撤销(Undo)功能是用户界面设计人员所拥有的最棒的武器之一。我认为，它是自鼠标发明以来用户界面设计中最大的一处改进。

如果单击了图1-3所示的确认框中的“确定(Yes)”按钮(或者已经彻底关闭这个对话框)，Windows并不会将该文档从计算机上完全删除。它会将这个文档移动到磁盘的另一个被称为“回收站”的地方，跟Macintosh操作系统上那个著名的垃圾桶类似。如果事后改变了自己的想法，想要取回这份文档，只要还没有清空回收站，您就可以从回收站中取回。一般删除文件时都是真正想把文件删除掉。当出现一些意外情况时再采取办法补救(比如，鼠标的滑动导致选择了错误的文件，我昨天就碰到了这样的事情)，而不是试图通过使用确认对话框来打扰每位用户的方式防止这些错误，前者的效率要高得多，而且，由于过度使用后者已经没有任何效果。此时，一点补救措施胜过一大堆预防。

“撤销(Undo)”功能不仅可以用于文件操作，而且可以用在应用程序中。这个命令通常放置在“编辑”菜单项下面，同时还对应有“恢复(Redo，作用就是撤销‘撤销’命令的执行结果)”。如果没有撤销功能的话，我没有办法连续写作5分钟时间，可能会输入很傻的句子，或者将文字移动到错误的位置上。编写这项功能的程序员为所有的用户做了一件非常有意义的事情。所有的用户都应该感谢他们。要想很好地实现这个功能，以便让用户无须费力思考它，只需要按下“Ctrl+Z”，就可以取回前面的结果，这需要很大的工作量(这验证了那句话“容易的事情不简单”)。只有那些不能撤销的操作，程序才应该进行确认。除此之外，所有的操作也都应该可以撤销。

撤销功能的真正好处在于它让用户能够探索程序。根据菜单项上的简单标签和工具栏上的小图标，用户并不总能够理解一个新的程序。但是由于这个程序具备撤销功能，用户就可以尝试各种不同的操作，而且知道这样做不会破坏任何东西，因为万一操作错误只需几次单击动作就可以还原。您可以四处移动某一段落，看看把它放在其他地方的效果如何，如果不满意的话，可以立即撤销修改。程序员经常把不正确的用户输入看作是傻瓜的作为，这个傻瓜应该坐下来阅读使用手册。事实并非如此。这是人类学习的主要途径。具备撤销功能的应用程序使得人们可以进行探索，而不会让人感觉恐惧。它认识到用户的人性并使其得以提升。如果不能正确实现这项功能就是一种道德过失。

如果完全正确地实现了撤销功能，那么在整个系统中就只有一个具有破坏性的操作，这个操作就是清空回收站。某些人可能会认为这项操作应该有一个确认对话框，就像Windows系统现在所做的这样。但是即使在这里，确认对话框的作用是为了防止另一个不好的设计：在上下文菜单中，“资源管理器”菜单项下面紧挨着“清空回收站”菜单项。滑动鼠标，在上下文菜单中下移3个位置，而不是两个位置，就会执行后者而不是前者。这是一种不好的设计。既然清空回收站是系统中唯一具有破坏作用的操作，那么它就应该有一个别无他用的特殊动作，可以是一次性同时按下鼠标的左右键(这个操作被称为“chording”)，或者在用鼠标单击的同时按住某个键。更好的方法是让回收站自动清空，当回收站中的文件存放时间超过某个时限(可以是一个月，但用户可以配置)之后，就删除这些文件，这样基本上就不需要手动清空它了。您难道不想让自己家的垃圾桶也具备这个功能吗？不管在什么条件下，您都不应该在任何地方看到确认对话框。显示对话框的程序员逃避了自己应尽的职责，他们不应该再从事用户界面设计这项职业。

1.6 “以白痴的言行停止进行”
向用户展示程序的错误信息，绝对算得上程序员设计用户界面时最薄弱的环节。就在今天，我在撰写本章之余浏览了CNN.com网站主页，想把它保存到我的硬盘上去。我在Web浏览器的菜单中选择“文件”|“保存”。这个时候出现了一个显示这个操作的进度的对话框：5%已完成；15%已完成；等等，直到99%已完成。这时候进度对话框突然不见了，弹出了如图1-4所示的窗口。



图1-4 十足愚蠢的对话框

这个窗口是出自一个十足的笨蛋之手的杰作。为什么不能保存这个页面，我能够做些什么才能纠正这个错误？是因为页面内容受保护的缘故吗？就像一些职业艺术家的网站有时候采取的保护措施样。还是因为服务器不可访问？如果操作不能成功的话，为什么进度条会到达99%？进度对话框告诉我已经保存了99%，这些内容存放在什么地方？虽然不是100%那么完美，但是总比什么也没有强。进度对话框为什么不见了？错误提示说明页面不能保存到所选择的存放位置，那么是否能够保存到其他某个地方？如果是这样的话，应该放在哪里？我怎么知道是否可以存放在哪里？如果不能的话，为什么这个对话框提到“存放位置”？浏览器已经成功地向我显示了这个页面，也正因为如此我才会去保存这个页面。为什么不能保存浏览器所显示的内容呢？对话框没有告诉我到底如何找出问题所在，或者到哪里了解更多的信息。此外，它却只给出了一个让我能够响应的“确定(OK)”按钮。但对于我而言，我并没有什么可以“确定”的东西，这个保存页面的操作并没有成功执行，而且程序并没有向我解释失败的原因。这个对话框的标题“保存网页错误(Error Saving Web Page)”甚至也有问题。我并没有做错什么。我只是做了程序允许我做的事情。在程序不能保存我的页面时，它犯了第1个错误，而它不能解释错误的原因则是它犯下的第2个错误。只用了寥寥数字就引出了这么多的疑惑，这实在算得上我所见到的“idoicy(笨蛋)”们“最伟大的”作品。

我们前面曾经提到过一位用户界面设计专家艾伦·库珀，他将这种情况称为“以白痴的言行停止进行(stopping the proceedings with idiocy)”，这是一句很好的短语，只是它没有使用我发明的那个单词拼写(idoicy)。如果我真的不能保存这个页面，浏览器应该知道这个结果，应该阻止我尝试保存，并向我解释原因，理想情况下不应该再在我面前弹出一个愚蠢的对话框。在我浏览这个页面的时候，或许可以将菜单项“保存”变灰，或者将菜单项的文字改成“禁止保存/受保护内容”，这样用户就知道是怎么回事及其原因。如果不能保存完整的页面，它应该尽其所能地保存可以保存的内容，并通知我哪些内容没有保存下来，再次声明，不要再让用户去单击那些愚蠢的对话框。在被保存下来的那部分页面中，或许可以在那些未被保存下来的地方放置一些占位符，如果没有找到某项被请求的页面元素，在浏览器显示页面中给出一个小的红叉。

通过仔细查找背后的原因，最终我找到了发生上面保存失败的原因所在。我曾经设置浏览器屏蔽掉一些讨厌的特定类型的内容。浏览器在屏幕上显示为空白区域，这些地方曾经大量出现一些愚蠢的浮动广告(dancing advertisement)。(另一章将专门讨论浮动广告。)当程序在保存网页的时候，遇到页面中的这些部分，发现内容被屏蔽了，它并不会像程序显示页面时那样忽略掉这些内容。相反，它不会尽其可能保存页面内容，而会被这些已屏蔽内容阻塞，导致整个保存进程都中止了，并以我刚才描述过的白痴言行让活动停止。

当您碰到这么一个让人费解的对话框时，您怎么不会觉得自己是个傻瓜？要知道这并不是用户的过错，而是程序员未能尽到他的职责。要明白任何一个用户都没必要去理解这样一个愚蠢的沟通方式。想象自己用双手卡住这名程序员的脖子，用膝盖猛击他的裤裆。建议您按照本章的后面以及本书最后一章中所推荐的方式行动起来。

1.7 活物测试
在测试某款产品的内部操作之前，程序员绝不会(也不应该)发布该产品。那么为什么在未进行用户界面测试的情况下就认为自己可以搞清楚用户真正能够使用它？因为程序员知道自己喜欢它，并觉得它好用，其他人为什么不也这样想呢？正如我们所见到的，这类潜意识假设几乎总是错误的。如果用户搞不懂如何使用，计算机就是一堆昂贵的废铜烂铁。测试用户界面(称为“可用性测试［usability testing］”)比较困难，且成本较高，但是非常有必要。

程序员不能只是把程序交给用户，然后问他们是否喜欢。用户通常不会记住自己做过什么事情；他们也不想把自己遇到的问题告诉程序员，因为他们觉得自己太笨没能解决问题；他们不想侮辱程序员，经过几年的职业磨砺他们居然还编写得出如此糟糕的程序。(但是我会这样做的，这一点您目前可能已经猜出来了。)要搞清楚哪些方法管用，程序员必须仔细地观察用户在使用用户界面的过程中执行了哪些操作。他们首先尝试什么？然后执行什么操作？需要尝试多少次才能真正搞明白某项功能？要想让他们注意到某项功能，通常需要多长时间？

同时，在观察用户使用的过程中，还要保证不能影响到用户的习惯。这就意味着用户必须呆在一个与外界隔绝的房间里，能够访问他们在现实生活中使用的任何支持材料(比如在线文档或者Google)。必须通过单向镜(one-way glass)观察用户，用录像带记录他们的反应，同时还要使用日志软件，这样就可以精确地了解用户在使用应用程序的过程中曾经使用哪些按键和鼠标单击。有些可用性实验室甚至使用跟踪耳麦，它可以用来报告用户正在查看屏幕的哪个部分。

当您做这件事情的时候，事情就出现了转机。正如艾伦·库珀在他的经典著作About Face：The Essentials of User Interface Design(IDG Books出版社1995年出版。译者注：此书第二版中译本《软件观念革命—— 交互设计精髓》，由电子工业出版社出版)中所写的：“［可用性专家］把程序员拖进暗室，在这里他可以通过一个单向镜观察那些倒霉的用户如何与他编写的程序进行搏斗。起初，程序员可能怀疑测试者脑袋有问题。最终，在经历了大量痛苦的观察之后，程序员被迫向实际证据屈服。他们承认自己的用户界面设计需要改进，并发誓修正问题。”

但是可用性测试往往被放到了开发过程的晚期进行，也就是在刚要发布产品之前。而且项目进度总是会发生变化，所以可用性测试常常被彻底忽略了。即便是可用性测试真的发现了一些有用信息，项目进度往往无法安排时间根据它相应地修改程序。应该尽早地进行可用性测试，在理想情况下，应该在开始任何程序设计任务之前进行。

有些公司认为在发布产品之前进行大量测试可以改进产品的可用性。举例来说，微软采用了一项称为“dog-fooding”(这是“先行尝试［eating our own dog food］”的简写)的方法。微软在向大众发布某款产品之前，会把它分发给公司内部的真实用户使用，比如说，让所有的秘书都切换到新版本的Word。这可以捕获到一些bug，这里指的是程序的逻辑错误，程序员忘记处理这些bug，从而导致程序崩溃。但是对于捕捉设计错误而言为时已晚，特别是可用性方面的设计错误。在发布“狗粮”之前将其发给内部员工品尝，可以帮助稍微改善“狗粮”的质量。但是它不会变成“猫粮”，并且已经做成“狗粮”之后才发现用户实际上是“猫”或者“长颈鹿”，这一切为时已晚。

这里有一个处理得非常好的例子。我曾经在一家保险公司作顾问，该公司正在编写一个Windows程序来取代某些昂贵的IBM终端。对于一家保险公司而言，不同寻常的是，他们真正执行了我刚才讲过的可用性测试。而且他们做得也很正确，使用录像带记录，并让程序员通过单向镜观察。他们发现用户基本上喜欢这款应用程序，并觉得可用性良好。但是用户习惯于使用回车键从当前输入框移动到下一个输入框，就像IBM终端所做的那样，而不是像多数Windows应用程序使用Tab键。他们问开发方不能修改吗？经过周密的考虑，开发方决定，尽管在技术上修改非常容易，但是这并不会取悦用户，即使用户认为如此。当然，他们能够让这款应用程序按照原有的方式工作。但是用户马上将要使用的所有新款商业Windows应用程序都不会按照这个方式工作，并且用户每天都要来回切换很多次，这样的话他很快就会得精神分裂症。所以开发人员说服用户改变自己的习惯。在经历了一段必然的诉苦时期之后，用户冷静下来并慢慢接受了新的操作方式，当然，该行业当时恶劣的就业环境也帮了不少忙。我的观点并不是说，程序员应该反复规劝用户，让他们相信这些功能对他们有好处。通常不能这样做，但是这是一个特例。我讲这个事例是为了说明我的一个客户完成了一次很好的可用性测试。他们执行了所需的测试，发现了待发现的问题。并且，他们根据自己的发现做出了正确的判断。我希望更多的公司能够做到这样。

1.8 小结及应对措施
我们这些可怜的用户被摆在什么位置？现在总结一下我目前的观点：

(1) 用户并不笨。用户界面确实糟糕，而它们本不该如此。

(2) 它们之所以糟糕是因为它们是由程序员设计的，这些程序员并不明白一个道理：自己的用户并不是他们自身。

(3) 由于第2条，他们很容易将程序的界面设计得非常复杂，并且他们期望用户也能够喜欢这样的界面，但是用户并不喜欢(参见第1条)。

在每个软件项目的初期就让可用性专家参与进来，这样可以设计出优秀得多的用户界面。普通的程序员在这方面往往做得很不够，甚至是起到了负面作用。必须要有一个人为那些沉默的大多数用户说话，这些用户并不关心技术本身，他们只希望完成自己的工作，这样就能够早点回去过自己的生活。每次出席设计评审会议的时候，我总是试图扮演这个角色。“你们就像那些设计电钻并在家得宝(译者注：Home Depot，全球最大的装潢零售公司，也是美国第二大零售公司)销售的人”我告诉程序员，“你们在这里讨论着电钻的这个或者那个内部细节：球轴承、滚子轴承还是气垫轴承，你们所讲的每一项内容都不是你们的顾客想要了解的信息。这是一种错误的方法。客户并不关心你们的电钻。他们从未关心过，将来也不会。他不是因为需要电钻才去家得宝，他去家得宝是因为想在墙壁上打洞。如果他能够直接买一些现成的洞回去直接安装在墙壁上，而不需要使用电钻，他会更加高兴。电钻只是用户为了打洞而不得不借助的一个工具而已。现在问您自己如下问题，然后如实回答：“您的用户真正想要的是哪些类型的洞？您的程序如何让他更快更省劲地打出更好的洞？”

现在您已经读完了本章的内容，您已经跟其他人一样够资格去告诉软件公司，您喜欢什么，不喜欢什么。程序的用户界面的结构并非像西奈山(译者注：Mount Sinai，基督教《圣经》中记载上帝授予摩西十诫的地方)上的摩西十诫代代流传下来。它是根据程序员和其他开发人员的设计决策制作出来的，他们还可以非常容易地制作出其他的不同界面。给他们发送大量电子邮件。告诉他们自己喜欢什么，不喜欢什么。告诉他们去掉确认对话框，并提供更好的撤销功能。

像世界上的其他人群一样，程序员也不喜欢被看扁。您说他们长相丑陋、脾气暴躁，残忍地对待小孩和小动物，他们并不介意，但是说他们太笨？也许仁慈的上帝会怜悯我们。他们非常在乎别人如何评价他们的智力，其程度要远远超过其他方面。如果您需要让某个程序员做些事情但是他没有完成的话，一定要让他出丑。

所以，当您下一次看到某个设计得很糟糕的用户界面时，要停下来仔细看看。玩味一会儿，搞清楚自己为什么不喜欢它，力求精确和具体，并且怎样做才能让您觉得更好一些。到“耻辱堂(Hall of Shame)”网站上去发一个关于这个丑陋界面设计的通告，这个网站就是专门为这个目的而设计的。本书的网站www.whysoftwaresucks.com也是一个很好的发布地方。然后发一封电子邮件给这个应用程序公司，向其显示您已经将其公开曝光。您越让他们觉得没有面子，就越能够让其明白公开化对他们的名誉的负面影响。然后他们可能最终会明白自己的用户并不是他们自己。