软件随想录(local.joelonsoftware.com/wiki)-2000年04月12日 使用介面设计手冊第三章 - User Interface Design for Programmers

2000年04月12日 使用介面设计手冊第三章 - User Interface Design for Programmers Chapter 3

 

The Joel on Software Translation Project:使用介面设计手冊第三章

From The Joel on Software Translation Project

Jump to: navigation, search

程序员的使用介面设计手冊 第三章：选择

作者：周思博 (Joel Spolsky)
译：Paul May 梅普华

Wednesday, April 12, 2000

A part of Joel on Software, http://www.joelonsoftware.com

---

当你进餐厅时看到一个告示写著「不得带狗进入」，你可能会认为这个告示就只是单纯的禁止：餐厅老板不喜欢有狗跑来跑去，所以开餐厅时就加上那个告示。

如果事情只是这样，应该也会有「不得带蛇进入」的告示；毕竟没什么人是喜欢蛇的。另外也要有「禁止大象进入」告示，因为大象一坐下来就会压坏椅子。

出现这个告示真正的原因其实是历史性的：这是个历史性的标记，表示以前人们试图把狗带进这个餐厅。

大多数禁止告示的出现，都是因为建物所有人受不了有人一直做某件事，所以就做了一个标示要求大家别那样做。如果你到一家50年以上的老餐厅，会看到墙上掛满各种「请不要把背包放在柜台上」之类的告示，从人类学来看，这表示大家曾经很习惯把背包放在柜台上。你还可以由告示的年代知道当地的学生是在什么年代流行使用背包。

有时候要找出原因会比较困难。「请不要把玻璃瓶带进公园」一定是表示有人曾经赤脚走在草地上，结果踩到碎玻璃割伤了，而且很有可能这些人因此控告政府。

软件也有类似的人类学记录：一般称之为「选项」对话框。叫出「工具」下的「选项」对话框，你就会看到软件设计者 对该产品设计的争议历史。我们是不是应该自动打开使用者最后所用的文件呢？要！不要！这件事吵了两个星期，大家都不想伤害别人的感觉。当设计者在争执时，程序员为了自保就先用#ifdef把这段程序框起来。最后大家只好把这变成一个选项。

这甚至不必是两个人间的争议：有可能只是在心中盘算的两难状况。我就是无法决定 要针对大小还是速度来最佳化数据库。不管是哪一种形式，最后都会以「精灵」对话框收场。而「精灵」对话框无疑是Windows操作系统史上最低能的发明。这个对话框愚蠢到应该获颁某个奖，一个全新种类的奖。当你试图从辅助说明中找资料时会出现下面的对话框：

这个对话框的第一个问题是会让人分心。你本来是想从说明档里找救兵，根本没空去管数据库是大是小是要微调，还是要涂上一层巧克力。可是这时候却跑出这个烂对话框在那里跩文说它得建立一个清单(或数据库)。里面有大约三段文字，其中大部份都会让人愈看愈糊涂。里面有段很糟糕的字眼"your help file(s)"。你看看，这表示你可能有一个或多个文件。意思好像这个时候你会在意可能有一个以上的档。俨然一个或多个档间是有著极微细的差异。其实显然是写这个对话框的程序员相信说明档可能不只一个，并且烦恼怕写成单数是不对的。我说的对不对？

我实在懒得再说了，别说大部份要查说明档的人不懂这种深奧文字，连进阶使用者也不会懂的。就是有电脑科学博士学位精通全文检索的程序人员也搞不清楚这里究竟要选些什么。

更低级的是这还不只是个对话框...这是个精灵(下一页只会说些废话，大意是「感谢你在这里杀时间」)。很显然设计者已经心里有底知道哪个选择最好；毕竟他们还花工夫推荐了其中一个选项。

这让我们得出使用介面设计的第二项准则：

你每多提供一个选项，就等于要求使用者多作一个决定。

要求使用者下决定本身并不是件坏事。能自由选择是非常美妙的。人们喜爱到星巴克点咖啡类饮料，因为得做很多很多的选择。来一杯大杯低咖啡因脫脂摩卡，要加瓦伦西亚糖浆加奶泡。还有要特别热的！

问题在于要他们做一个他们根本不在乎的决定。以上面的说明档为例，人们是因为遭遇困难，无法完成真的要完成的事(如制作生日邀请卡)，才会去看说明档。他们没办法把汽球图案倒过来印或是有别的状况，只好暂停制作生日邀请卡改去查说明。结果微软里某个负责说明档索引引擎的工程师却过度膨胀他自己的烦恼，无礼又厚脸皮地再度中断使用者，而且开始教使用者要制作列表(或数据库)。这种二次中断与生日邀请卡完全无关，保证只会打扰使用者甚至让使用者掉头离去。

相信我，其实使用者所在意的事并没有你所设想的那么多。他们是利用你的软件去完成某件工作。他们比较在意工作本身。如果这是个绘图程序，他们可能希望能以最细微的程度控制每一个画质。如果这是个建立网站的工具，可以肯定他们一定会很坚持要做出的网站和他们的设计一模一样。

不过他们才不会在乎程序的工具列放在视窗上面还是下面。他们不在意说明档是否有用索引。很多东西他们都不在意，而设计者有责任做这些选择好让使用者不必多费心。替使用者添这种麻烦选项是软件设计者的傲慢自大，因为设计者不够努力思考决定哪个选项比较好。(还有更糟的情况，就是像WinHelp成员那样，明明把难题丟给使用者选择，却把选项转成精灵形式企图隐瞒过去。俨然把使用者当作低能儿，必须针对这个烂选项上小小两堂课(两页的精灵)才能做出被教出来的决定。)

有人曾说设计是个做选择的艺术。当你设计一个放在街角的垃圾桶时，必须在多个互相冲突的需求间做决择。垃圾桶必须重才不会被吹走。可是要轻才能让垃圾工方便清理。要大才能装很多垃圾。可是要小才不会占住人行道。如果你在设计时想逃避责任而强迫使用者决定某些事情，十之八九你并没有尽到本份。其他人会写出一个更简单的程序，不必那么烦人就能完成相同的工作，结果大部份的使用者都会喜欢用这个程序。

当1990年Microsoft Excel 3.0出现时，它是第一个具备工具列这个新功能的应用程序。这是个很聪明的功能，大家都很喜欢，而且所有人都在抄这个功能，抄到最后几乎看不到没有工具列的程序。

工具列非常的成功，所以Excel团体还对少数人发行特别版本的Excel，以进行用户端使用的研究；这个版本会统计最常用的命令并把结果传回微软。然后他们在下一个版本再加了另一列的工具列按钮，里面包括最常用到的命令。真是棒啊。

问题是他们一直没有解散工具列小组，而这个小组似乎也不知道见好就收。他们要让你能订制你自己的工作列。他们要让你能把工具列拖到画面上任何位置。接下来他们又开始想到，功能表列其实只是个用文字代替图示的工具列，所以也让你能把功能表列拖放到画面上任何一个位置。这种订制化的能力已经离谱了。它的问题是没有人会在意！我从没看过有人会把功能表列放在视窗顶端以外的位置。这里要讲个(烂)笑话：如果你想拉出文件功能表，可是不小心拉到功能表左边，结果就把整个功能表列拖到你不要的地方，然后挡到正在用的文件。

这种事你遇过多少次？另外一旦不小心弄错，实在不清楚自己做错什么或要怎么修复。所以这里又会多出现一个选项(是否能移动功能表列)，没人要(或许会有0.1%的人会要吧)却又干扰到所有人。

有一天有个朋友打电话给我。她遇到问题没法子送出电子邮件。她说半个画面都是灰的。

半个画面都是灰的？

我在电话上花了五分钟才弄清楚怎么回事。她不小心把Windows工具列拖到画面右边，然后又不小心把工具列拉宽：

这就是那种没人会故意做的事。而外头有很多电脑使用者不知道怎么解决这种鸟事。当你不小心改变了程序的选项，你并不知道如何重新设定。有件事令人非常惊讶，很多人会在程序出问题时移除或重装软件，因为这是他们唯一会做的事。(他们得先学会移除软件，否则所有错误的设定重装完后依旧存在)。

「可是先等一下！」你会说「对想要调整环境的进阶使用者来说选项非常重要！」事实上这并没有你想得那么重要。这让我想起我曾经想改用Dvorak键盘。结果发现我不只用一台电脑。我用的电脑五花八门什么都有。我也会用其他人的电脑。通常我在家里会用三台电脑，在工作时也会用到三台。我还会用到实验室里的电脑。订制环境的问题是无法转移，所以干脆不要改变省掉这个麻烦。

大多数进阶的使用者通常都会用好几台电脑；他们每隔几年就会把电脑升级，每三个星期就会重装操作系统。他们第一次知道Word的按键可以完全重订时，的确把所有东西依照自己喜好重新设过。不过当他们升级到Windows 95并发现以前的设定都不见了，工作环境也不一样了，最后就会放弃，不再重新设定环境。这件事我问过很多算是「高阶使用者」的朋友；除了要让系统正常运作的必要修改外，几乎没有人会进行额外的调整。

每当你提供一个选项，就等于要使用者下一个决定。这表示他们得考虑某些事并作决策。这并不一定是坏事，不过一般而言，应该要持续努力把使用者必须做的决策数目降到最少。

这并不是要你消除所有的选择。无论如何使用者都得做很多的选择：文件的外观如何，网站要如何运作，还有其他和使用者工作內容密不可分的项目。在这些部份就可以尽量发挥：这时候有选择是很好的，而且当然是愈多愈好。另外还有一类选择很受欢迎：就是不影响行为只更改事物外观的功能。大家都喜欢WinAmp的换壳功能；大家都会把桌布设成图片。因为这些选择改变了视觉外观，可是完全不会影响任何功能，另外也因为使用者能完全自由地忽略选择直接完成工作，这就是选项的良好应用。

下一章：情境支持(Affordances)与隐喻

这些网页的內容为表达个人意见。
All contents Copyright 1999-2002 by Joel Spolsky。All Rights Reserved.