程序员如何进行用户界面设计

程序员设计的用户界面，其实大多数并不是一个好的界面，很多人写代码时，以为这样的功能比较强大应该加上去，那样的接口比较灵活应该加上去，可是往往到头来用户只用其中的一点功能，并且会有很多用户认为很难懂、很难用、容易操作失误，这是为什么呢？

我认为主要是程序员编码的思想影响到了对用户界面的设计，很多程序员都有钻牛角尖、猎奇的倾向，喜欢所有东西都DIY，这也就促使他们在设计软件时，希望它非常灵活，很多功能都能DIY。没错，功能很强大，用在一些特殊的设计软件上，非常好，但是如果做一些大众化的商业软件，却并不太适合。

大家都用过播放器，拿播放器来看碟，只要它不是很占CPU、比较好看、操作简单、能够播放大多数片子，对大多数人来讲已经足够了，为何要加那么多功能，举个例子，KMPLAYER很强大吧，有没有在市面上很流行？

我要是写个系统管理程序自己用，肯定是写得很强大很灵活，恨不得什么都能管理，什么都能DIY，但是做商业软件却不能如此。

现在很多公司都开始注重软件的用户界面，为什么？

一个好的产品，并不是功能够强大就好卖，市面上很多类似产品，稳定、安全、美观很重要，不知道大家有没有注意到日本货，其实有些产品并不是功能很强大，或者是很稳定，而是因为它很好看，日本鬼子很注重外观，好的外观与好的界面，可以在第一时间打动消费者。

我刚开始工作时，给客户做个节目信息录入软件，功能已经完成，并且我觉得界面非常好看了（以自绘的listctrl列出所有信息项，双击就可以编辑内容），结果客户反映非常难用，为什么，信息录入软件，是个高效的东西，用户一整天就在打字录入，你界面做得再好看，每次还要双击一次才能编辑，是不是很麻烦，这时候就应该操作为主，在此基础上尽量美化界面。

我讲这些主要是说明一点，用户界面不是美观就好，功能强大就好，要站在用户角度去看，所以在此我转载了几篇文章，希望可以给大家一点启示

 

程序员的用户界面设计手册

第1章: 控制你的环境使你快乐

 

作者: Joel Spolsky 约耳.斯珀儿斯奇

译： 梅普华

2000年4月10日

大多数我认识的C++程序高手都厌恶写用户界面的程序. 这让我觉得相当惊讶,

因为我觉得用户界面程序设计的本质既容易又直接有趣.

 

说它容易, 因为用到的算法不会太复杂, 最多只是让在某个矩型正中央画出另一个矩形. 说它直接, 因为有错误时马上就能看到并且立即修正. 说它有趣,

因为工作的成果马上就能看得到. 感觉起来就像是直接雕塑出程序.

 

我认为大多数程序员会害怕撰写用户界面的程序, 其实是害怕用户界面设计本身. 他们认为用户界面设计就像美术设计一样:

是那些全身黑衣喝着拿铁极富创造力的家伙创作出艺术品的神秘过程.程序员自认是分析性逻辑性的思考家: 擅于推理而缺乏艺术判断力.

所以认为自己无法做用户界面的设计.

 

事实上我发现用户界面设计是相当容易而且合理的. 它并非那么神秘, 不一定要拿到艺术学位还要偏爱染亮紫发才会. 用户界面是有合理的方法的,

利用一些简单符合逻辑的准则就可以改善程序的界面.

 

我并不是要写"用户界面设计之道". 用户界面不是艺术也不是佛教, 它只不过是一套规则. 一种有方法合乎道理的思考方式. 这本书是为程序员设计的.

所以我会假设不必教你如何建立菜单,而是要你思考要在功能表里面放些什么(或者是否需要菜单). 我会告诉你一个所有良好用户界面设计共通的通则,

而且非常容易理解

 

我第一份真正的工作是到一家大型的面包工厂做事. 这家工厂的设计有六条面包生产线. 每两条生产线有一个生面团搅拌机,

可以搅拌出180公斤的面团再送到左边或右边:

 

不过这只是原本的设计. 实际上搅拌机C还有生产线3和生产线5都还没弄好.

所以实际的安排如下:

<>(注：这里有张图片，不过没办法粘过来，抱歉，不过还好，并不太影响文章整体内容)

 

细心的读者可能会觉得奇怪"面团怎么能由搅拌机B送到生产线6呢?". 没错, 这就是约耳我出场的地方. 你可能不会相信,

我的工作就是站在搅拌机B的左边, 用推车接住搅拌机吐出来的180公斤巨大面团, 再把车推到生产线6, 然后用类似绞车的装置把面团抬起来放上生产线6.

由下午10点起到凌晨4点, 我每十分钟就要重复一次这个动作.

 

麻烦还不只这样. 生产线6实际上并不能一次处理180公斤的面团, 所以我得用一份大刀把面团切成10份. 我根本不想描述这有多么辛苦.

 

当然啦, 工作前几天我很痛苦. 这事看起来根本是不可能做到的. 我全身每根骨头都在痛. 水泡一直消不了. 全身没有一个地方不痛的.

 

最初我根本没办法持续把面团送到生产线6. 当面团来不及送到时, 生产线上就会出现一个大缺口. 等缺口流到炉子时,

炉子(在较少的面团上消耗相同的能源)的温度就开始上升并且把面包烧焦. 有时候生产线6会乱成一团停止动作, 可是搅拌机却还在不停的制造面团,

这时推车可能全都装满面团. 这时候我就得把地板清干净然后上油, 再把面团倒在地上, 等会再刮起来. 这个作法其实相当有用,

因为当面团放超过约30分钟后就会发酵, 发酵后就做不出好的面包. 这时候只能把面团切成5公斤的小块, 等新面团来时每次混进一块.

 

过了一个多星期我渐渐熟悉整个过程. 如果没记错的话, 在每次10分钟的面团处理过程中我可以休息到2分钟. 我把整个时间弄得非常清楚,

还学会在生产线停摆时让搅拌机停一次.

 

于是我开始思考为什么啤酒广告会说some days are better than others.

 

某一天想着这个问题的时候, 我注意到有一架堆车的轮子很脏, 没法子转得很顺. 有时候根本不朝我推的方向走然后撞上东西. 有件事有点讨厌.

就是在拉链子要把推车吊起来时, 有时会被链条上的金属刺刮伤(只是轻伤). 另外还有一件事, 当我推空车去装搅拌机射出的面团时, 可能会踩到地上的油渍滑倒.

只是一点小困扰, 算不上什么大麻烦.

 

有时也有些小小的胜利. 我学会精准地计算面团产出的时间, 让新面团刚好在旧面团刚用完后几秒送达. 这样就能确保有最新鲜的面团并且制作出最好的面包.

另外还有些更微细的胜利: 搅拌机有时会溅出小粒面团粘在墙上. 这时我会用插在后口袋的油漆刮刀把面团刮下来丢进垃圾桶. 没错! 就只是这样.

当我把面团切成小块时, 有时会切到很棒很顺. 当我能控制我周遭的世界时, 即使是以再微不足道的形式控制, 还是能获得小小的满足.

 

这就是那一段日子的情形. 很多小小的挫折还有很多小小的成功. 不过这些挫折和成功都是会累加的. 即使微不足道的挫折也会影响你的心情.

看起来人的情绪并不在意事件的大小, 反而着重在事件的数量.

 

于是我开始注意到, 我最快乐的时候都是遇到很多小成功而挫败的次数很少.

 

多年以后当我上了大学, 我学到一个重要的心理学理论, 就是由Dr. Martin E. P. Seligman发展的习得无助感(Learned

Helplessness). 这个理论有着多年的研究结果支持, 是说很多次的沮丧会累积成一种无助感 (也就是无法控制环境的感觉).

 

你愈觉得自己能控制环境, 而且所做的动作确实有效, 就会觉得愈快乐. 当你发现自己沮丧愤怒烦乱时, 很可能是发生了某些你无法控制的事,

甚至是很微细的事情. 键盘上的空格键不太正常. 结果打字时几个字接在一起. 这会让人沮丧, 因为你按了空格键可是什么都没有. 大门的钥匙不对劲,

转动的时候就卡住了. 这又是另一个挫折. 这些事会累加起来; 日复一日就让我们变得闷闷不乐. 虽然这些事实在微不足道,

不应该挂在心里操心(我是说非洲还有人在挨饿, 看在老天份上我实在不能为空格键烦心), 可是就是会影响我们的心情.

 

让我们休息一分钟, 然后把主题拉回计算机.

 

我们要虚构一个典型的窗口高阶用户"皮特". 当你在考虑用户界面时, 想象一个虚构的用户会很有帮助. 虚构用户愈真实, 考虑他们使用产品时效果就会愈好.

皮特是在某家技术性书刊出版社里工作的会计师, 使用窗口有六年经验, 主要在办公室用, 偶而也会在家里用. 皮特很能干而且很技术性. 他会自己安装软件; 会阅读

PC Magazine, 甚至还能写些简单的Word宏协助办公室的秘书开发票. 他家里有装缆线调制解调器. 皮特从来没用过麦金塔.

"太贵了"他会告诉你说"128MB RAM的700 Mhz PC才多少钱..." 好了, 这就是皮特. 我们都知道了.

 

有一天皮特的朋友珍娜有计算机问题找他帮忙. 珍娜有台麦金塔iBook, 因为她喜欢那种半透明的外壳. 当皮特坐下来试着用麦金塔时, 很快就遇到挫折了.

他说:"我恨死这些玩意了". 到最后皮特还是能帮上珍娜的忙, 不过却变得暴躁不悦. 他说:"麦金塔的用户界面怎么这么烂."

 

烂? 他在说什么啊? 大家都知道麦金塔有个优雅的用户界面, 对不对? 这可是最容易使用的典范?

下面是我对这个问题的分析.

 

在麦金塔上要移动窗口时, 用鼠标抓住窗口任何一边就可以移动. 而在Windows上一定要按住标题列才行. 如果你按到窗口框边, 就会改变窗口大小.

皮特在帮珍娜时想拖拉窗口右框边把窗口变宽. 结果却移动了整个窗口, 而非照他预期的改变大小.

 

Windows显示讯息框时, 可以按enter键或空格键把讯息框清掉.  而在麦金塔上按空格键是无效的. 通常必须用鼠标来点.

当皮特在看到警告时, 他照着过去六年来潜意识的动作想按空格键清除讯息, 按第一次没有用. 皮特不自觉地更用力的按空格键.

因为他认为问题一定是空格键按得太轻,以致于麦金塔没有侦测到按键. 事实上 麦金塔是有侦测到按键的 -- 可是这个键当时没有作用! 最后皮特改用鼠标.

这又是另一个小挫折.

 

皮特也知道按Alt+F4可以关闭窗口. 不过这在麦金塔上却是更换磁盘驱动器. 皮特想点选桌面上的Internet Explorer图标,

不过图标却被另一个窗口遮到了.   所以他按Alt+F4关闭窗口并且立即在图标所在位置连按两下.

Alt+F4并未关闭窗口而是叫出计算机上的碟碟机, 所以他的连击就按到原先想关闭窗口上工具列中的Help按钮, 然后开始叫出求助窗口.

他想关闭一个窗口结果却还有两个窗口开着.

 

又是一个小挫折. 不过老兄你要知道, 挫折是会累积的. 等那天结束的时候, 皮特已经变得暴躁不悦了. 当他试着控制事物却徒劳无功.

空格键和Alt+F4键都"没有反应" -- 简直就像这些键坏掉一样. 想把窗口拉宽时窗口也不听话, 只会像开玩笑般到处动, 完全没有变宽. 真是烂窗口.

虽然整个过程都是潜意识的, 失控的微妙感觉却会变成无助感,让人觉得很惨. "我喜欢我的计算机,"皮特说. "我都设定好了, 会照我喜欢的方式作业.

可是这些麦金塔又烂又难用. 根本是在折磨人. 如果苹果公司这些年专心做MacOS而不是去乱搅什么Newton PDA, 他们的操作系统才不会这么糟呢."

 

没错, 皮特. 我们很能了解. 虽然麦金塔真的很容易使用(就Mac用户而言), 皮特还是会有这种感觉. 要按什么键关闭窗口完全是随意的.

微软的程序员(假设是抄麦金塔界面的那批人) 可能认为自己增加了一个很酷的新功能, 可以拖拉任何一个边框改变窗口大小. 而MacOS

8.0的程序员可能认也觉得自己加了一个很酷的新功能, 让你可以拖拉任何一个边框移动窗口.

 

大多数看到有关用户界面的论战都弄错重点了. 因为Windows提供更多方法可以改变窗口大小, 所以比较好. 那又有怎样? 这根本不是重点.

重点是用户界面是否依照用户所期望的方式反应? 如果没有, 用户会觉得无助失控, 就像我想推推车却撞上墙壁的状况一样.

 

用户界面重要是因为它会影响感觉,情绪以及用户的心情. 如果用户界面不好,让用户觉得他们无法控制你的软件, 他们绝对不会高兴,而且会怪罪你的软件.

如果用户界面很聪明, 让事情都能照用户所想的进行, 他们完成一件小事时就会很高兴. 嘿! 我拷好一片光盘了! 这个程序 可以用耶! 真是个好软件!

好耶!!!

 

你必须让人们觉得他们似乎能控制环境, 才能使他们快乐. 要达到这个目的, 你必须正确地 解释他们的动作. 界面必须依照他们所期望的方式作用.

 

因此所有用户界面设计的通则就是:

如果程序的行为与用户的期望完全一致,

就是一个设计良好的用户界面.

 

希列(Hillel,犹太思想家)说过:"除此之外全部都只是注释(everything

else is commentary)". 同样的, 良好用户界面设计的其它所有规则也都只是演译所得.

 

程序员的用户界面设计手册

第2章: 找出用户的期望

 

作者: Joel Spolsky 约耳.斯珀儿斯奇

译： 梅普华

2000年11月4日

新用户在操作一个程序时, 心里绝不会一片空白.

他们会先预设程序会如何运作. 如果他们以前曾用过类似的软件, 就会假设这个程序的动作应该与其它软件一样. 如果他们以前没有用过任何软件,

就会假设你的软件会遵循某些常规. 他们还可能很聪明, 会猜测整个用户界面的运作模式. 这被称作用户模型:

也就是用户心中对程序所做的事的认知.

程序本身也有一个"心智模型", 不过这个模型是用数字方式编码, 并且由CPU确实地执行. 这被称作程序模型,

而且是固定不变的. 我们在第一章说过, 如果程序模型与用户模型一致, 就能拥有成功的用户界面.

我们来看一个例子. 在Microsoft

Word(及大多数文书处理器)中, 如果在文件里放一张图片, 图片会被储存在该文件同一个档案内. 你可以建立图片并把图片拖入文件内, 然后删除原图片文件,

而文件内的图片依旧存在.

不过HTML却不能这样做. HTML文件一定得把图片放在分开的档案里. 如果找个惯用文书处理器却完全不懂HTML 的用户来,

请他用FrontPage等还不错的所见即所得HTML编辑器, 他几乎一定会认为图片将会存在同一个档案里.

这就叫用户模型惯性(如果你愿意这样叫的话).

所以用户模型(图片会嵌入在同一个档案)与程序模型(图片必须分开存盘)间就有个讨厌的冲突,

这样用户界面一定会产生问题.

如果你正在设计一个类似FrontPage的程序, 这就是你会发现的第一个用户界面问题. 你不可能改变HTML.

所以一定得做些事让程序模型符合用户模型.

你有两个选择. 你可以尝试改变用户模型. 不过这点将会非常困难. 你可以在手册里面解释清楚,

不过大家都知道用户根本不看手册, 而且他们可能也没必要看. 你也可以显示一个小对话框说明图片文件不会被嵌入, 不过这又有两个问题: 熟练的用户会觉得很烦,

另外用户也可能根本不看对话框. (我们会在第六章深入讨论).

所以呢, 山不转路转... 最好的选择通常都是改变你的程序模型而不是用户模型.

或许你可以在插入图片时产生一个图片复本, 存到文件文件所在处的子目录中, 这样至少能符合用户认为图片已复制

(可以安全地删除原图)的印象.

我要怎么知道用户模型呢?

这件事其实很容易. 只要问他们就好了! 在你的办公室里随便抓五个人或是找朋友或家人,

然后用普通的说法说明你的程序(这是个制作网页的程序). 接下去描述状况: "你正在编一个网页, 现在有张图叫Picture.JPG. 你要把图插入到网页内."

然后问几个问题来猜测他们的用户模型. 比如"图片会放在哪里?", "如果你删除Picture.JPG,

这个网页还能正常显示该图片吗?"

我有个朋友正在做一个相簿型式的应用程序. 当你把照片加进去之后, 程序会显示一堆小图: 也就是每张图的缩图复本.

由于产生小图要花很长一段时间(如果照片很多时时间更长), 所以他想把小图存在硬盘某处, 这样小图只要产生一次就好了. 有很多方法可以达成这个目的.

可以把所有小图存在一个叫小图的大档案中. 也可以把各个小图分别存盘, 不过放在同一个叫小图的子目录内. 小图也可以在操作系统内标示成隐藏文件不让用户发现.

我的朋友选了一种自认最妥当的方法: 把各张图片picture.JPG的小图另存成名为picture_t.JPG的新檔, 放在原图的目录中.

如果你本的图片有30张, 完成后该目录含小图就会有60个档案.

讨论各种图片储存机制的优缺点可以吵上几个星期, 不过还是有比较科学的作法可以用.

只要问问用户对小图存盘的想法就好了. 当然会有很多用户不清楚或不在意或是根本没想过, 不过如果你问过很多人, 就会开始看到某些一致的意见.

常见的选择就是最佳的用户模型, 至于程序模型是否要和用户模型一致就是你自己的事了.

接下来你得测试自己的理论. 替你的用户界面建一个模型或原型,

然后请大家用它完成某些工作. 在他们完成的过程中问他们期望发生什么事. 你的目标是找出他们所期望的东西. 如果工作内容是"插入一张图片",

而你看到他们尝试把图片拖进你的程序里, 你就知道程序最好能支持拖放功能. 如果他们去点"插入"菜单, 你就知道"插入"菜单下最好能有一个"图片"选项.

如果他们把"字型"工具列里的"细明体"换成"插入图片", 你就知道这是个没碰过图形化用户界面,

试图使用命令列界面的老古董.

那么要找多少人来测试你的界面呢? 你的直觉可能会认为愈多愈好(对科学实验来说完全正确). 不过你的直觉错了.

几乎每个靠做可使用性测试为生的人似乎都认为五个或六个人就够了. 超过这个数字之后就会看到结果一直重复,

所以继续做其它用户只是浪费时间.

你并不需要一个正式的可使用性实验室, 也不必真的去街上随意挑用户来说--你可以做个"5毛钱可用性测试",

也就是叫住下一个遇到的人, 请他帮忙做个快速的可使用性测试就可以了. 不过要注意别说溜嘴先告诉他要怎么做. 应该要他"好好想清楚",

然后再尝试用开放性的问题找出他们的心智模型.

如果你的程序模型不单纯,

可能就不是用户模型.

我6岁时爸爸买了一台世界上第一批的口袋型计算器(HP-35)回家, 他努力告诉我那里头有一台计算机. 我觉得不可能.

星舰迷航记里所有的计算机都是整个房间大小而且都有巨大的碟带机. 我认为只不过是按键的键和LED显示上各个段落有很巧妙的连接关系, 才会产正正确的数学答案.(嘿,

我才6岁而已).

有个很重要的经验法则, 就是用户模型不会非常复杂. 当人们必须猜测程序的运作方式时, 答案通常是简单的而非复杂的.

找台麦金塔坐下来用. 打开两个Excel电子表格文件和一个Word文件档. 几乎所有生手都会猜测这些窗口间没有关连. 他们看起来就是没有关系:

 

从用户模型来看, 点Spreadsheet 1应该会把该窗口叫到最前面. 可是实际发生的却是Spreadsheet 2 跑到前面,

几乎对所有人来说这都是个让人挫折的意外:

 

实际的情况如下. Microsoft Excel的程序的程序模型认为"你有一些隐藏的电子表格, 每个电子表格都属于某个应用程序,

而窗口是连到这些隐藏的电子表格的. 当你把Excel叫到最前面时, 所有Excel的窗口也会被移到前面."

没错. 隐藏的电子表格.

不过用户模型里具有隐藏电子表格的机会有多少呢? 大概可能是零吧. 所以新的用户总是会被这个行为吓到.

Microsoft Windows上有另一个例子,

就是按Alt+Tab键可以切到"下一个"窗口. 大部份的用户可能都会假设这个键是在所有可用窗口间循环. 如果你有A,B,C三个窗口, A窗口是在作用中.

按Alt+Tab应该会切到B窗口. 再按一次Alt+Tab会切到C窗口. 实际上第二次的Alt+Tab会切回A窗口.

要切到C窗口一定要按住Alt后再按两次Tab键. 这在切换两个应用程序时还不错, 不过几乎没人了解这个方法, 因为比起在多个可用窗口间循环的模型来说,

这个模型稍嫌复杂.

要让程序模型遵循简单的用户模型已经够难了. 当用户模型更为复杂时简直不可能做到. 所以要尽可能挑选最简单的模型.

 

第3章: 选择

作者: Joel Spolsky 约耳.斯珀儿斯奇

译： 梅普华

2000年4月21日

当你进餐厅时看到一个告示写着"不得带狗进入", 你可能会认为这个告示就只是单纯的禁止: 餐厅老板不喜欢有狗跑来跑

去,

所以开餐厅时就加上那个告示.

如果事情只是这样, 应该也会有"不得带蛇进入"的告示; 毕竟没什么人是喜欢蛇的. 另外也要有"禁止大象进入"告示,

因

为大象一坐下来就会压坏子.

出现这个告示真正的原因其实是历史性的: 这是个历史性的标记,

表示以前人们试图把狗带进这个餐厅.

大多数禁止告示的出现, 都是因为建物所有人受不了有人一直做某件事, 所以就做了一个标示要求大家别那样做.

如果你

到一家50年以上的老餐厅, 会看到墙上挂满各种"请不要把背包放在柜台上"之类的告示, 从人类学来看,

这表示大家曾经

很习惯把背包放在柜台上. 你还可以由告示的年代知道当地的学生是在什么年代流行使用背包.

有时候要找出原因会比较困难.

"请不要把玻璃瓶带进公园"一定是表示有人曾经赤脚走在草地上, 结果踩到碎玻璃割伤了,

而且很有可能这些人因此控告政府.

软件也有类似的人类学记录:

一般称之为"选项"对话框. 叫出"工具"下的"选项"对话框, 你就会看到软件设计者对该产品

设计的争议历史. 我们是不是应该自动开启用户最后所用的档案呢?

要! 不要! 这件事吵了两个星期, 大家都不想伤到别

人的感觉. 当设计者在争执时, 程序员为了自保就先用#ifdef把这段程序框起来.

最后大家只好把这变成一个选项.

这甚至不必是两个人间的争议: 有可能只是在心中盘算的两难状况. 我就是无法决定 要针对大小还是速度来最佳化数据库

.

不管是哪一种型式, 最后都会以"精灵"对话框收场. 而"精灵"对话框无疑是Windows操作系统史上最低能的发明. 这个对

话框愚蠢到应该获颁某个奖,

一个全新种类的奖. 当你试图从辅助说明中找资料时会出现下面的对话框:

这个对话框的第一个问题是会让人分心. 你木来是想从说明档里找救兵.

根本没空去管数据库是大是小还是要微调,或是要

涂上一层巧克力. 可是这时候却跑出这个烂对话框在那里跩文说它得建立一个清单(或数据库).

里面有大约三段文字, 其

中大部份都会让人愈看愈胡涂. 里面有段很糟糕的字眼"your help file(s)". 你看看,

这表示你可能有一个或多个档案.

意思好象这个时候你会在意可能有一个以上的档. 俨然一个或多个档间是有着极微细的差异.

其实显然是写这个对话框的

程序员相信说明文件可能不只一个, 并且烦恼怕写成单数是不对的. 我说的对不对?

我实在懒得再说了,

别说大部份要查说明档的人不懂这种深奥文字, 连进阶用户也不会懂的.

就是有计算机科学博士学位

精通全文检索的程序人员也搞不清楚这里究竟要选些什么.  

更低级的是这还不只是个对话框...这是个精灵(下一页只会说些废话,

大意是 "感谢你在这里杀时间"). 很显然设计者已

经心里有底知道哪个选择最好;

毕竟他们还花工夫推荐了其中一个选项.

这让我们得出用户界面设计的第二项准则:

 

你每多提供一个选项, 就等于要求用户多作一个决定.

要求用户下决定本身并不是件坏事. 能自由选择是非常美妙的.

人们喜爱到星巴克点咖啡类饮料, 因为得做很多很多的选

择. 来一杯大杯低咖啡因脱脂摩卡,要加瓦伦西亚糖浆和加奶泡.

还有要特别热的!

问题在于要他们做一个他们根本不在乎的决定. 以上面的说明档为例, 人们是因为遭遇困难,

无法完成真的要完成的事(如

制作生日邀请卡), 才会去看说明档. 他们没办法把汽球图案倒过来印或是有别的状况, 只好暂停制作生日邀请卡改去查说

明.

结果Microsoft里某个负责说明文件索引引擎的工程师却过度膨胀他自己的烦恼, 无礼又厚脸皮 地再度中断用户, 而

且开始教用户要制作列表(或数据库).

这种二次中断与生日邀请卡完全无关, 保证只会打扰用户甚至让用户掉头离去.

相信我, 其实用户所在意的事并没有你所设想的那么多.

他们是利用你的软件去完成某件工作. 他们比较在意工作本身.

如果这是个绘图程序, 他们可能希望能以最细微的程度控制每一个画质.

如果这是个建立网站的工具, 可以肯定他们一定会很坚持要做出的网站和他们的设计一模一样.

不过他们才不会在乎程序的工具列放在窗口上面还是下面.

他们不在意说明文件是否有用索引. 很多东西他们都不在意, 而设计者有责任做这些选择好让用户不必多费心. 替用户添这种麻烦选项是软件设计者的傲慢自大,

因为设计者不够努力思考决定哪个选项比较好. (还有更糟的情况, 就是像WinHelp成员那样, 明明把难题丢给用户选择, 却把选项转成精灵型式企图隐瞒过去.

俨然把用户当作低能儿, 必须针对这个烂选项上小小两堂课(两页的精灵)才能做出被教出来的决定.)

有人曾说设计是个做选择的艺术.

当你设计一个放在街角的垃圾桶时, 必须在多个互相冲突的需求间做决择. 垃圾桶必须

重才不会被吹走. 可是要轻才能让垃圾工方便清理. 要大才能装很多垃圾.

可是要小才不会占住人行道. 如果你在设计时

想逃避责任而强迫用户决定某些事情, 十之八九你并没有尽到本份. 其它人会写出一个更简单的程序,

不必那么烦人就能

完成相同的工作, 结果大部份的用户都会喜欢用这个程序.

当1990年Microsoft Excel 3.0出现时,

它是第一个具备工具列这个新功能的应用程序. 这是个很聪明的功能, 大家都很喜

欢, 而且所有人都在抄这个功能 ---

抄到最后几乎看不到没有工具列的程序.

工具列非常的成功, 所以Excel团体还对少数人发行特别版本的Excel, 以进行客户端使用的研究;

这个版本会统计最常用

的命令并把结果传回Microsoft. 然后他们在下一个版本再加了另一列的工具列按钮, 里面包括最常用到的命令.

真是棒啊

.

问题是他们一直没有解散工具列小组, 而这个小组似乎也不知道见好就收. 他们要让你能订制你自己的工作列.

他们要让

你能把工具列拖到画面上任何位置. 接下来他们又开始想到, 菜单列其实只是个用文字代替图标的工具列,

所以也让你能

把菜单列拖放到画面上任何一个位置. 这种订制化的能力已经离谱了. 它的问题是没有人会在意!

我从没看过有人会把菜

单列放在窗口顶端以外的位置. 这里要讲个(烂)笑话: 如果你想拉出档案菜单, 可是不小心拉到菜单边,,

结果就把整个菜

单列拖到你不要的地方, 然后挡到正在用的文件.

这种事你遇过多少次? 另外一旦不小心弄错, 实在不清楚自己做错什么或要怎么修复.

所以这里又会多出现一个选项(是否

能移动菜单列), 没人要(或许会有0.1%的人会要吧)却又干扰到所有人.

有一天有个朋友打电话给我.

她遇到问题没法子送出电子邮件. 她说半个画面都是灰的.

半个画面都是灰的?

我在电话上花了五分钟才弄清楚怎么回事.

她不小心把Windows工具列拖到画面右边, 然后又不小心把工具列拉宽:

这就是那种没人会故意做的事. 而外头有很多计算机用户不知道怎么解决这种鸟事.

当你不小心改变了程序的选项, 你并

不知道如何重新设定. 有件事令人非常惊讶, 很多人会在程序出问题时移除或重装软件, 因为这是他们唯一会做的事.

(他

们得先学会移除软件, 否则所有错误的设定重装完后依旧存在).

"可是先等一下!" 你会说 "对想要调整环境的进阶用户来说选项非常重要!"

事实上这并没有你想得那么重要. 这让我想起

我曾经想改用Dvorak键盘. 结果发现我不只用一台计算机. 我用的计算机五花八门什么都有.

我也会用其它人的计算机.

通常我在家里会用三台计算机, 在工作时也会用到三台. 我还会用到实验室里的计算机. 订制环境的问题是无法转移,

所

以干脆不要改变省掉这个麻烦.

大多数进阶的用户通常都会用好几台计算机; 他们每隔几年就会把计算机升级, 每三个星期就会重装操作系统.

他们第一

次知道Word的按键可以完全重订时, 的确把所有东西依照自己喜好重新设过. 不过当他们升级到Windows

95并发现以前的

设定都不见了, 工作环境也不一样了, 最后就会放弃,不再重新设定环境. 这件事我问过很多算是"高阶用户"的朋友;

除了

要让系统正常运作的必要修改外, 几乎没有人会进行额外的调整.

每当你提供一个选项, 就等于要用户下一个决定. 这表示他们得考虑某些事并作决策.

这并不一定是坏事, 不过一般而言,

应该要持续努力把用户必须做的决策数目降到最少.

这并不是要你消除所有的选择. 无论如何用户都得做很多的选择:

文件的外观如何, 网站要如何运作, 还有其它和用户工

作内容密不可分的项目. 在这些部份就可以尽量发挥:   这时候有选择是很好的,

而且当然是愈多愈好. 另外还有一类选择

很受欢迎: 就是不影响行为只更改事物外观的功能. 大家都喜欢WinAmp的换壳功能; 大家都会把桌布设成图片.

因为这些

选择改变了视觉外观, 可是完全不会影响任何功能, 另外也因为用户能完全自由地忽略选择直接完成工作,

这就是选项的良好应用.

程序员的用户界面设计手册

 

程序员的用户界面设计手册

第4章: 情境支持与隐喻

 

作者: Joel Spolsky 约耳.斯珀儿斯奇

译： 梅普华

2000年4月18日

要发展一个程序模型与用户模型一致的用户界面并不容易. 有时候用户可能对程序运作并没有具体的期望. 这时候你得想方法提示用户,

告诉他们程序如何运作. 对图形化界面来说, 要解决这个问题有个常见的隐喻作法. 不过隐喻并不是都一样的, 而且要先了解隐喻为何有用,

才能知道自己是否用了好的隐喻.

最著名的隐喻就是Windows和麦金塔所用的"桌面"隐喻. 桌面上有些小资料夹, 资料夹里面有些小档案.

你可以把资料夹和档案拖来拖去. 你可以把档案由一个资料夹拖拉移到另一个资料夹里. 就这种作用而言这个隐喻的确有用,

因为这些小数据夹图案真的会让人们想到真正的资料夹, 并且让人们了解可以把文件放在里面.

下面是由Kai's Photo Soap撷取的画面.

你能猜到要如何放大吗?

 

这不是很难吧. 放大镜就是真实世界的隐喻. 大家都知道该怎么做, 而且也不会担心放大功能会改变影像的大小,

因为放大镜并不会改变东西的真实尺寸.

即使是不甚完美的隐喻也比完全不用隐喻好得多. 你能找出在Microsoft Word里要如何放大吗?

 

Word的界面中有两个小放大镜, 不过其中一个是在"预览打印"钮上(原因不明), 而另一个则是在"文件引导模式"按钮(不知道是啥).

要改变放大倍率的正确方法是用写着"100%"的下拉列表. 这里并没有要用隐喻的意图, 所以用户比较难猜出要如何放大. 这并不一定是缺点;

考量到Kai有那么多的画面空间, 放大对文字处理软件来说可能并没有那么重要. 不过可以确定的是Kai用户中,

会用放大功能的用户比率一定比Word用户高.

不过选得不好的隐喻可比完全不用隐喻更糟糕. 记得Windows 95的公文包吗?

这个可爱的小图标在每个人的桌面上霸占约一平方吋的空间, 一占就是好几年, 直到Microsoft搞清楚没人要它才消失. 而没有人要用是因为它用的隐喻不好.

这应该是个可以把档案放进去带回去的"公文包". 可是当你要把档案带回家时, 还是得把它们拷进磁盘. 所以啰, 你究竟是把档案放在公文包还是放在磁盘里?

我不确定. 我搞不懂公文包, 我从来都不会用这个东西.

情境支持(Affordances)

设计良好的对象一看就知道要怎么用.

有些门在大约手的高度装有大片金属片. 对这片金属片唯一能做的是就是推它. 以唐纳.诺曼(Donald Norman)的话来说,

金属片对应产生(afford)推. 别的门会有个大圆把手让你只想去拉. 它们甚至还暗示你该如何握住把手. 所以把手就对应产生拉的动作.

它让你想要去拉.

其它对象的设计没这么好, 所以你就不知道该怎么做. CD盒就是个很典型的例子. 你必须把大姆指在正确位置 然后向某个方向拉.

可以盒子的设计本身完全没有指示要怎么做. 如果你不知道诀窍会很沮丧, 因为根本打不开.

要建立情境支持的最佳方法就是在"负空间"配合人手的形状.

我们仔细看看(优越的)柯达DC-290数字相机的前后盖:

 

前方有一个大橡皮把手, 看起来可以把右手手指很舒服放在这里. 后方左下角的设计更是聪明, 这里有一个超像姆指印的凹洞. 当你把左手拇指放在这里,

左手食指会很舒服的弯到相机前方镜头和另一个橡皮块间. 它提供了一种舒适的感觉, 就像在吸吮大拇指(并把手指沿着鼻子弯起来).

柯达的工程师只是试图诱使你用双手握住相机, 这样可以确保相机更稳, 而且也能避免手指乱放不小心遮到镜头. 这些橡皮并没有其它功用,

唯一的作用就是鼓励你正确地握住相机.

良好的计算机用户界面也会应用情境支持. 大约十年前起大部份的按钮都变成"3D"的. 加上各种灰阶色调后,

按钮看起来会突出屏幕. 这不光是看起来酷而已. 它的作用非常重要, 因为3D按钮对应产生了推的动作. 它们看起来就是突出来的,

会让人感觉要操作的方法就是去点它们. 不幸的是, 现在很多网站(没有注意到情境支持的价值)偏好看起来比较酷 而不是看起来可以按的按钮;

结果就是有时候会找不到该按哪里. 看看下面这个网页横栏:

 

"GO"和"LOG ON"按钮都有突出, 看起来就像可以点的样子. "SITE MAP"和"HELP"按钮看起来就不太像能按.

事实上它们和不能按的"QUOTES"卷标长得一模一样.

大约四年前, 很多窗口开始在右下角长出像是把手的三条小凸纹.

看起来像是刻在滑钮上增加摩擦力的东西. 它对应产生拖拉动作. 它只是在叫 你拖拉它来改变窗口大小.

最后要说一个最好的情境支持范例,

就是众所周知的"活页式对话框". 记得旧式的Mac控制面板吗?

 

它的想法是让你从左的列表(可卷动)选一个图标. 点了图标之后画面右方就会改变. 虽然原因不明, 不过这种迂回方式对原本设计的程序员来说非常合理,

可是很多用户完全搞不懂. 很少有人知道如何卷动列表显示其它图标. 不过比较严重的是, 大多数人都不知道图标和右边对话框是有关连的.

因为图标看起来只是个选项.

这种界面从大约1992起就开始消失不见, 取而代之的是一种叫活页式对话框的新发明:

 

活页式对话框是个很好的情境支持. 从图案上可以很清楚地知道你有六个活页; 也很明确地呈现你在哪一个活页.

当Microsoft开始测试活页式对话框的使用性时, 数值由约30%(旧式麦金塔作法)变成100%. 也就是说每一个受测者都能理解活页式对话框.

这个隐喻实在是非常成功, 另外Windows还内含支持活页式对话框的程序代码, 而且可以免费使用. 实在很难想象还看得到应用程序没有运用这个功能.

这些程序因为不想赶时髦, 结果却产生了真正可度量的可使用性问题.

 

程序员的用户界面设计手册

第5章: 一致性及其它怪东西

作者: Joel Spolsky 约耳.斯珀儿斯奇

译：

梅普华

2000年4月22日

Microsoft Office中的主要软件Word和Excel, 都是在Microsoft内部从无到有开发出来的,

而其它软件则是从外界公司买进来的, 特别是FrontPage(向Vermeer买的)和Visio(向Visio买的). 那这两个程序有什么共通点呢?

答案是他们在原始设计上就是要像Microsoft Office的应用程序.

决定要仿真Office的用户界面,

并不只是要"讨好"Microsoft或是打算把公司卖出去那么单纯; 事实上开发FrontPage的Charles

Ferguson绝不会犹豫承认他对Microsoft的厌恶; 他一再地请求司法部对 Redmond巨兽做些处置(直到他把公司卖给Microsoft,

之后他的立场变得复杂多了). 事实上Vermeer和Visio抄袭Office的用户界面 , 主要原因似乎是为了方便:

照抄比起重新发明轮子更容易更快速.

Microsoft的事业群程序经理Mike Mathieu从Vermeer的网站下载FrontPage试用,

发现这个程序和Word非常像. 由于程序与他所期望的动作非常像, 所以使用起来更加容易.

而这种易用度让他马上对这个程序有非常好的印象.

而当某个程序能立刻让Microsoft有很好的印象时, 他们就会掏出一亿五千万美元.

你的目标或许没那么大; 只是希望客户喜欢然后掏出大概39美元吧. 不过想法却都是一样的: 一致性会产生容易使用的感觉, 然后会产生好感觉,

最后就能赚更多钱.

一致性对人们学习使用各种软件的帮助无法低估. 在图形化用户界面出现之前, 每个程序都会重新发明一套很基本的用户界面.

甚至连"离开"这种每个程序必备的单纯操作都完全无法一致. 那时候大家至少都会背下常见程序的离开命令, 这样才能跳出原有程序去跑自己要的东西.

Emacs迷会背":q!"(只记这个)以防自己卡在vi里出不去, 而vi用户则是背"C-x C-c" (Emacs甚至自有一套控制字符的表示法).

在DOS时代, 如果键盘上不套一个蠢胶片提醒Alt+Ctrl+F3怎么用, 根本没办法使用WordPerfect.

我只记得可以按F7离开.

影响还不只这样, 即使是像预设打字行为(覆盖或插入)这样微小的不一致也会让你受不了. 我很习惯按Ctrl+Z,

这在Windows程序里是表示"还原". 可是在用Emacs时就常常会不小心按到而把窗口最小化(也是按Ctrl+Z).

(有趣的是Emacs用Ctrl+Z当最小化的原因正是为了与烂用户界面csh(UNIX的C shell)一致)

这就是那些加起来让人不快乐的微细挫折之一.

再举个更细微的例子, Pico和Emacs都用Ctrl+K删除一行文字, 不过两者的行为有着些许不同.

这个小差异却常常让我在Pico里的文件乱掉. 我敢保证这种经验你自己也有一堆.

在麦金塔早期Microsoft Windows还没出现的年代,

狂热的Apple支持者会对每个人说, 一般而言Mac用户比DOS用户能运用更多的程序完成工作. 我不记得确实的数字了,

不过我相信大概是说一般DOS用户会用一两个程序, 而Mac用户会用12个程序. 理由是说由于Mac的软件操作的方式都一样,

所以在Mac上很容易学会用新程序.

一致性是良好用户界面设计的基本原则, 不过它也只是"让程序模式符合用户模型"公理的推论结果之一,

因为用户模型可能会反映用户看到其它程序的行为. 如果用户学到连按两下表示选取单字, 他们拿到从未看过的新程序时, 也会猜测选取单字的方法就是连按两下.

所以现在的程序最好在用户连按两下时选取单字(而不是做其它动作, 比如到字典里查被点到的字), 否则就会有可使用性的问题.

既然一致性的好处如此显著,

为什么我还要浪费你我的时间去强调呢? 问题在于外头有股黑暗势力在反对一致性, 而且设计者和程序员的天性就是创新.

我很不愿意告诉你"不要创新",

问题是要让用户界面容易使用, 就得把创意放在别的地方. 在大部份的使用设计案例中, 你在从头设计前绝对要先看看其它热门程序怎么做, 并且尽可能的仿真它们.

如果你在制作某种文件编辑程序, 最好能长得和Microsoft Word一模一样, 连菜单里相同项目的快速键都照抄. 有些用户可能习惯按Ctrl+S存盘,

有些人可能习惯用Alt+F,S, 而其它人可能会按Alt,F,S(先放开Alt键). 还会有一类用户会去程序左上方区域找磁盘图标去按. 这四种方法最好都能用,

否则用户就会遇到他们不想要的结果.

我看过有些公司的管理阶层很自豪的说, 他们故意把东西做得和Microsoft不同.

他们会夸耀说"只是因为Microsoft这样做, 并不表示这是对的", 然后去建立一套没有依据, 而且与大家习惯不同的用户界面.

在你开始高唱"只是因为Microsoft这样做, 并不表示这是对的"的咒语之前, 请先考虑两件事:

1. 假设Microsoft的作法真的不对,

可是他们已经在Word, Excel, Windows, 或Internet Explorer这些普遍的软件上这样做了,

所以数百万人都会认为这是对的(至少也会认为这样做正常), 而且他们会假设你的程序也会这样做. 虽然你可能认为(显示和Netscape

6.0的工程师一样)Alt+左键不适合作为"上一页"的快速键, 可是外头有好几百万人都会试着按Alt+左键回到上一页,

所以如果你为了某些信仰理由(比尔盖茨是个很邪恶的大法师)而不这样做, 那么你只是为了满足自己的虚荣而毫无理由地毁掉自己的程序,

而且用户也不会因而感谢你的.

2. 另外就是别那么确定他们是错的. Microsoft在可使用性测试上花的钱比你多,

他们还有累积几百万通电话支持服务的详细统计资料, 另外也很有可能是因为较多人指出要这样做,

Microsoft的人才会这样做.

要制作一个具有好用用户界面的优良程序, 你得把自己的信仰留在家里. Microsoft可能不是唯一要抄的对象:

如果你正在制作一个线上书店, 可能也得确定你的网站至少在意思上和Amazon一样. Amazon会把你的购物车资料保留90天. 你可能认为自己绝顶聪明,

所以24小时后就把资料清掉了. 当Amazon的客户把资料暂存在你的购物车内, 他们会认为过两星期回来购物车内的资料应该还在. 如果你24小时后就把资料清掉,

就会损失一个顾客了.

如果你正在制作一个针对绘图专业人士的高阶相片编辑器, 我确信你的用户中有90%都知道Adobe Photoshop,

所以你最好让程序在功能重叠部份表现得非常像Photoshop. 如果不这样做, 大家会说你的很难用, 虽然你自己 觉得它比Photoshop容易,

这就是因为你的程序的运作与用户的期望不同.

另外还有一种常见的倾向, 就是重新发明Windows所附的共享控制组件. Netscape 6就不用提了.

有一阵子你光看外表就知道某个程序是用Borland's C++编译器写的, 因为上面有巨大的OK按钮和超大型核示框. 不过这还没有Kai's Photo

Soap那么糟糕:

没错, 这东西的确是漂亮的很, 不过O上面跨条线(其实是"不"的意思)会让我想到"OK", 而Windows的标准是把OK放在左边,

所以我时常会按错钮. 这样用漂亮符号取代"OK"及"Cancel"只有一个好处, 就是夸耀你多有创意. 如果人们因为Kai的创意而出错, 那没啥问题,

那只是为了突显某位艺术家所必须付出的代价. (这个"对话框"还有另一个问题, 就是没有标准的标题列, 无法把对话框移开.

所以如果对话框挡到某些回答所需信息时就惨了.)

有个酷又漂亮的用户界面好处很多. 像Kai这样优良的绘图设计非常讨喜, 能吸引人来用你的程序.

个中诀窍在于不要违反规则. 你可以稍微改变对话框的视觉外观, 不过不要影响功能.

当Juno的第一版出来时, 有个标准的登入对话框提示你输入姓名和密码.

当你输入姓名之

后, 应该按TAB键跳到密码栏输入密码

当时Juno有个发神经病的程序经理, 他用UNIX的经验比用Windows多很多,

所以他习惯输入姓名后按ENTER键(不是TAB键)跳到密码栏. 当你写一个针对一般Windows用户的程序时, UNIX程序员可能并不能代表一般用户,

可是这个经理却非常坚持按ENTER键要跳到下一个字段而不是执行Windows标准的"确定"动作. 他尖叫着说:"只是因为Microsoft这样做,

并不表示这是对的."

所以程序员花了很多很多时间, 绕过Windows预设行为写出了非常复杂的对话框处理程序. (要做得与众不同,

几乎一定会比依照平台规矩去做花更多的工夫). 这段程序成为很大的维护梦魇; 我们由16位移到32位窗口时移植得很不顺. 它没有照大家的期望运作.

而当新的程序员加入团体时, 都无法理解为什么会有这么奇怪的对话框处理.

还有很多程序员试图重新制作各种常用的Windows控制组件, 由按钮, 滚动条,

工具列到菜单(Microsoft Office团队最喜欢重做的东西) 什么都有. Netscape 6.0最夸张,

它把每个共享的Windows控制组件都重做了. 这样通常都会有些无法预见的坏处. 最好的例子就是编辑框. 如果你重新写一个编辑框,

可能会有很多你根本没听过的东西(如中文编辑附加工具,还有支持由右至左文字的双向版Windows)都不能用了, 因为它们不认得你写的非标准编辑框.

有些记者在检视Netscape 6.0的抢鲜版时, 就注意到URL输入框(运用Netscape自制的非标准编辑框) 不支持标准编辑控制组件功能,

无法按右键叫出内容菜单.

和反Microsoft的基本教义派或创意绘图设计师争论时, 他们常常会错用爱默生的话: "一致是渺小心智的妖魅...".

正确的句子是"愚蠢的一致是渺小心智的妖魅." 好的用户界面设计者会明智地运用一致性, 虽然这样无法夸耀他们的创意, 从长远来看却会让用户更快乐.

 

第6章: 为节省大家的麻烦所作的设计

 

作者: Joel Spolsky 约耳.斯珀儿斯奇

译： 梅普华

2000年4月26日

当你在设计用户界面时,

最好能记住两个原则:

1. 用户是没用手册的, 即使他们有手册也不会去读.

2. 事实上用户是不会去读任何东西的,

就算有东西可以查他们也不想去查.

严格讲起来这并非事实, 不过你应该假设这是事实并照着去做, 因为这样能让你的程序更容易而且更亲近用户.

设计时心存这个想法就叫做尊重用户, 意思就是不要太尊重用户. 看不懂吗? 让我来解释吧.

怎么样才算是让东西容易使用呢?

度量方法之一就是看看真实世界中的用户有多少比例能在指定时间内完成工作. 举例来说, 假设你程序的目的是让人们把数字相机的照片转成网络相本.

你可以找些一般用户来, 请他们用你的程序完成这项工作. 如果你的程序愈好用, 就会有愈多的用户能成功地建立一个网络相本. 用科学的方法来说,

就是假设有100个真实世界的用户. 他们不一定要熟悉计算机. 他们各有所长, 不过其中有些人是不太会用计算机的. 有些人在用你的程序时还会分心.

电话会突然响起. 喂. 什么? 小孩在哭. 什么? 猫跳上桌子追老鼠. 我听不清楚啦!

虽然我没有看着这个实验进行, 我有相当的把握敢说,

有些用户就是无法完成工作或者要花非常长的时间才完成. 我并不是说这些用户是笨蛋. 相反的他们可能非常聪明, 他们也可能是很高超的运动员, 不过对你的程序而言,

他们就是无法把他们的运动技巧和脑细胞用上去. 你可能只抓住他们30%的注意力, 所以你必须与一个显然不是全心投入的用户打交道.

用户不读手册.

首先用户是真的没有手册. 可能是根本没有手册. 就算真有手册, 用户也可能因为各种原因拿不到: 人在飞机上;

正在用由网站拿下来的试用版; 人在家可是手册在公司; 他们的信息部门从来不提供手册. 说实在的, 就算可以拿到手册, 除非他们别无选择, 否则就是不会去读.

只有极少数的例外, 才会有用户抱着手册读一遍后再去使用软件. 通常你的用户都是想完成某项工作, 而且他们认为阅读手册是浪费时间, 就算不是浪费时间,

至少也会让他们分心而阻碍他们完成工作.

 

你能读这本书, 表示你是高等知识分子中的精英. 没错, 我当然知道能用计算机的人通常都能阅读,

不过我敢保证其中很多人都会觉得读东西是很烦的. 手册所用的语言可能不是他们的母语, 也有可能他们还不够精通. 他们也可能只是小朋友! 如果真的必要,

他们还是能搞懂手册内容, 不过没必要的话他们是绝对不会去看的.  用户只有在绝对需要时, 才会临时去看手册.

所以结论就是你可能没有选择,

只能把软件设计得不用手册就可以上手. 唯一我能想到的例外就是用户缺乏领域专业知识时 -- 他们根本不懂这个程序的功用, 不过却知道自己最好要去学.

Intuit极受欢迎的小企业会计软件QuickBooks就是个很好的例子. 这套软件有很多用户都是对会计完全没概念的小企业主.

而QuickBooks的手册就假设它得教大家会计原则. 这是一定要的. 不过如果你已经懂会计,

即使没有手册QuickBooks还是很容易用.

事实上用户根本不会读任何东西.

这听起来可能有点刺耳, 不过你很快就会懂了,

当你在进行可用性测试时, 会有相当数量的数用者根本不看画面上的字. 不管你在画面上显示什么样的错误讯息, 他们根本都不看. 这可能会让身为程序员的你惊惶失措,

因为你想象自己正与用户对话. 嗨, 用户! 你不可以开启这个档案, 我们不支持这种档案格式! 不过经验显示, 对话框里放的字愈多,

愈少人会实际去读.

用户不读手册这个事实, 让很多软件设计者认为程序应该在事情发生当时加以叙述以教育用户. 所以你会在程序各处都看到说明.

理论上这是可以的, 不过实际上由于人们讨厌阅读, 所以这招还是很不通的. 有经验的用户界面设计者会努力把对话框内的字数减到最少, 以增加用户看内容的机会.

当我还在Juno的时候, 负责用户界面的人懂这个道理所以试图写出简短清楚的文句. 可惜的是公司总经理以前在长春盟名校主修英文;

他没受过任何用户界面设计或软件工程的训练, 却深信自己是个优秀的文字编辑. 所以他否决了用户界面设计专家的文句, 反而加了很多他自己的长篇大论.

Juno典型的对话框如下:

 

与Windows对应的对话框比较:

 

你在直觉上会认为说明有80个字的Juno版本会比只有5个字的Windows版本更"优秀"(也就是更易使用).

不过等你对这类事情做过可用性测试后就知道正确答案了.

* 进阶的用户会跳过说明. 他们假设自己懂得使用方法, 没时间去读复杂的说明

*

大多数生手会跳过说明. 他们不喜欢看太多字而且希望默认值就能用

* 其它认真的生手会尝试阅读说明(其中有些人只是因为在做可用性测试, 觉得应该要去看),

却常被恐怖的字数和概念搅乱了. 所以即使用户很有把握第一次能会用这个对话框, 这些说明还是会让他们更迷糊了.

不管怎么说,

Juno的老板显然都管太细了. 讲明白点, 如果你在哥伦比亚大学主修英文, 那么你的读写能力和一般人根本是完全不同的,

而且你应该要非常小心去写那些似乎很有帮助的对话框内容. 尽量把文句缩短简化, 把括号里的复杂子句都拿掉, 并且进行可用性测试.

不过千万别写得像长春藤联盟的教学备忘录一样. 在对话框里甚至连加上"请"这种似乎礼貌而有用的字, 都还是会把用户拖慢: 增加字数会减少阅读文字的人数,

而且影响是可以测量得出来.

另一个重点是很多人都怕计算机. 这一点你大概已经知道了, 对不对? 不过你可能还不了解其中的暗示.

我曾经看着某个朋友要跳出Juno. 不知道为什么她一直遇到问题. 我注意到当要跳出Juno时会出现下面的对话框:

 

我的朋友会去按No, 然后就有点惊讶Juno竟然没有结束. 这个对话框是在询问用户选择, 却让她马上认为自己做错事了. 通常程序会要你确认某个命令,

是因为你正在进行某些你可能会后悔的动作. 所以我朋友就认为既然计算机在质疑她的决定, 那么计算机一定就是对的, 因为计算机毕竟是计算机而她只不过是个人,

所以就按了"No".

要求人去读11个无聊的字会不会太过头了? 显然是会. 首先由于离开Juno并不会产生伤害, 所以Juno应该不需要提示确认,

像现有的其它图形用户界面一样直接离开就好. 不过即使你深信在结束前必须要人们先确认, 也可以用两个字而非11个字:

 

少了完全不必要的"thank you"和鼓励后悔的"are you sure?", 这个对话框就不太会产生问题了. 用户一定会看这两个字,

对着程序说声"嗯?"后就按"Yes".

你会说Juno的离开确认对话框只会困扰少数人, 不过有这么严重吗? 每个人到最后总有法子跳出那个程序的.

不过个中差异在于可以用还是容易使用. 即使是经验丰富又聪明的高阶用户, 还是会感谢你为慌张无经验生手所作的简化. 旅馆的浴缸都有很大的扶手.

它们的用途只是要帮助残障者, 不过大家都会用这些扶手离开浴缸. 即使对身体健康的人来说, 这些扶手也能让生活更轻松.

下面一章我要讨论一些关于鼠标的事.

就像用户不会/不想/不能阅读一样, 有些人也不擅长使用鼠标, 所以你必须配合他们.

 

程序员的用户界面设计手册

第7章: 为节省大家的麻烦所作的设计, 第二部份

 

作者: Joel Spolsky 约耳.斯珀儿斯奇

译： 梅普华

2000年4月27日

 

当麦金塔刚出来时,

Bruce "Tog" Tognazzini 在Apple的开发者杂志写了一个关于用户界面的专栏. 大家写了很多有趣的用户界面设计问题到这个专栏让他回答.

这些专栏一直持续至今, 现在已经是放在他的网站上. 同时也被修润后收录在许多好书里, 像是 Tog on Software Design ,

这本书非常有趣而且对用户界面设计有很好的介绍(Tog on Interface更棒,

不过已经绝版了.)

 

Tog创造了哩高菜单的概念来解释,

为何麦金塔菜单(总是在屏幕最顶端)比Windows菜单(放在各个应用程序窗口内) 好用许多. 当你要在Windows里叫用档案菜单时,

必须点到一个宽约半吋高约1/4吋的目标区域. 你必须在水平和垂直两个方向精确地把鼠标移到定位.

可是在麦金塔上可以把鼠标猛向上推到屏幕顶端,

不必费心要推多高, 鼠标自然会在屏幕顶端(也就是使用菜单的正确垂直位置)停住. 所以实际上虽然目标区域的宽还是只有半吋, 不过高度却有1哩.

现在你只要注意光标的水平位置, 不需要管垂直方向, 所以点选菜单的动作变得容易许多.

基于这个原理, Tog出了一题随堂测验:

屏幕上最容易用鼠标抓到(点到)的五个点在哪里? 答案: 屏幕的四个角落(基本上只要把鼠标猛推过去, 完全不必定位), 再加上鼠标目前的位置,

因为已经到位了.

哩高菜单的原理相当有名, 不过一定还不够容易理解, 因为Windows 95团队设计"开始"按钮时完全搞错重点了.

"开始"按钮几乎是放在屏幕的左下角, 不过并没有放得刚刚好. 事实上是放在屏幕由左由下算各2个像素的位置. 所以只因为这几个像素,

Microsoft就变成弄巧成拙了(Tog如此形容), 结果让"开始"按钮变得很难使用. 本来宽高都有一哩, 用鼠标随便按都可以.

却因为我不知道的原因变成这样子. 我的天啊.

我们在前一章说过, 用户有多么讨厌阅读, 除非完全无法完成工作否则尽量避免阅读.

同样的:

用户没办法把鼠标控制得很好.

我说的并不是字面上的意思. 我真正的意思是, 你应该把程序设计成不必常常灵活操控鼠标就能正常使用.

这里列出六个主要的原因:

 

1. 有时候人们并没有用最好的指向装置, 他们可能在用轨迹球或轨迹板, 或是ThinkPad上的红色小东西,

这些装置都比真正的鼠标难控制.

2. 有时候人们使用鼠标的环境并不好: 拥挤的桌面; 滚球脏了所以鼠标会跳动; 也有可能用的是只值5块美元的仿制品,

动作根本就不正常.

3. 有些人刚接触计算机, 还没有发展出正确使用鼠标的技巧.

4. 有些人根本就没有精确使用鼠标的技巧, 而且永远都不会有.

他们可能有关节炎, 手抖, 腕道症状; 他们也可能很小或很老; 或是有其它的残障.

5. 很多人发现连按两下又不动到鼠标是非常困难的.

而动到鼠标会让激活应用程序变成拖放对象. 这种人很容易认, 他们的桌面都会乱成一团, 因为他们想激活程序时常会变成移动图标.

6.

即使是在最佳的状况下, 人们用鼠标时还是会感觉慢很多. 如果你强迫人们用鼠标进行多个步骤, 他们会觉得自己被卡住了, 结果会让用户界面感觉起来反应迟钝,

然后会让他们不快乐(这点你应该会知道).

以前我在Excel团体时, 手提电脑还没有附指向装置,

所以Microsoft造了一个卡在键盘旁边的夹式轨迹球. 要知道鼠标是由手腕和多根手指操控. 用起来很像写字, 而你可能在小学就已经发展出很精准的写字技巧了.

可是轨迹球完全是用姆指控制的. 所以要把轨迹球用到像鼠标一样是很困难的. 大部份人可以把鼠标控制到只差一两个像素, 不过用轨迹球就会变成3或4个像素了.

我在Excel团体里一直主张大家要用轨迹球来测试他们的新用户界面, 不可以只用鼠标,

这样才能理解无法把鼠标移到所想位置的感觉.

下拉式组合清单是困扰我最深的用户界面组件之一. 就是长相如下的组件:

 

当你点到向下箭头时, 清单就会展开:

 

想想看要选一个项目(假设选Times New Roman好了)得要多少个精确的鼠标点选动作. 首先得按向下箭头. 然后要用滚动条小心的向下卷,

直到看到Times New Roman为止. 这种下拉列表常会不小心设计成只能同时显示二或三个项目, 所以这个卷动操作也不太容易, 如果字型很多时更是困难.

你必须小心的拖动滚动条(移动范围这么小, 实在不可能做到), 或者重复按第二个向下箭头, 或是点卷动标记和向下箭头间的区域(如果卷动标记很低时也不能用,

只会让你更烦). 最后当你好不容易看到Times New Roman之后, 还必须点到它才行. 如果点错了就要从头来过.

如果你想把著作里每一章的第一个字母都设成某个美观的字体, 你真的会很不爽.

正因为有着很简单的解决方法, 所以我觉得这个该死的下拉式控制组件更讨厌了:

只要让下拉列表长到能容纳所有项目就好了. 可是外头90%的组合框根本没有运用所有可以的空间来显示清单内容, 这实在是不象话.

如果主编辑框到屏幕底没有足够空间用的话, 下拉列表应该要往上长到能容纳所有选项, 长到顶到屏幕上下边缘也没关系. 如果这样还放不下所有项目,

当鼠标接近边缘时清单就会自动卷动, 而不是要可怜的用户去用那个小得可怜的滚动条.

更重要的是, 显示清单时不要点编辑框右边那个袖珍箭头,

应该按组合框上任何一处都可以. 这样要按的区域就会变大约十倍, 用鼠标应该就能很容易地点到目标.

让我们看看另一个鼠标使用的问题: 编辑框.

你可能已经注意到了, 在麦金塔上几乎所有的编辑框都是用一种名叫Chicago的肥胖粗体字, 这种字看起来有些丑, 会让绘图设计师痛苦得不得了.

绘图设计师(与用户界面设计者不同)被教导的是细瘦而间距不固定的字比较美观优雅而且好读. 这当然都是对的. 不过绘图设计师的技巧都是在纸上而非在屏幕上学到的.

当你要编辑文字时, 与间距不固定的字相比, 等间距字有个很大的优点: 就是像"l"和"i"这种很细的字比较容易阅读或选取.

我是在可用性测试中看到一位60岁老人很辛苦地试着编辑街名(好象是Fillmore Street之类的)时才学到这件事. 我们用的是8点的Arial字体,

所以编辑框的长相如下:

 

注意字母I和L都只有一个像素宽. 小写I和小写L间只差一个像素.(另一个类似状况是几乎不可能分辨出小写"RN"和"M"间的差异,

所以编辑框的内容其实可能是Fillrnore).

只有极少数人会注意到自己把Fillmore错打字Flilmore或Fiilmore或Fillrnore,

即使注意到了, 要用鼠标选到打错的字母并且修正可能也要花很多的时间. 事实上要用闪烁光标(两个像素宽)选取单一个字母也是非常困难.

看看如果用肥胖字体(这里用Courier Bold)会有多简单吧:

 

这样就好了. 没错, 对绘图设计师来说这样会占用较多的空间, 看起来也不够酷. 认了吧! 这样好用多了; 当用户打字时会显示锐利清晰的文字,

感觉还会更好, 而且编辑起来容易多了.

 

程序员有一个常见的思考模式: 数字只有三种: 0, 1, 还有n. 如果有n的话(非0或非1的数), 所有n大概都一样. 会有这种思考模式,

可能是因为深信程序代码中不应该有0和1以外的数值常数. (0和1以外的常数被视为"魔术数字". 我才不要那么偏执呢.)

举例来说, 程序员习惯上认为,

如果程序允许开启多个文件, 就必须允许开启无限多个文件 (只要内存足够), 否则至少也要有2^32个(程序员唯一勉强接受的魔术数字).

程序员习惯以鄙视的眼光看待只能开启20个文件的程序. 20是什么意思? 为什么是20? 20甚至还不是2的乘幂!

所有的n大概都一样的想法还有另一个证据,

就是程序员习惯上认为如果用户可以移动窗口并改变窗口大小, 应该就可以完全自由地控制, 可以移到或用到屏幕最边边. 所以把窗口放在离屏幕顶端2个像素,

和刚好放在屏幕顶端"似乎是一样的".

不过这并不是事实. 结果显示, 有很多好理由可以说明为何应该把窗口放到屏幕最顶端(把屏幕可用区域放到最大),

可是却完全没有理由要在窗口上缘和屏幕顶端留2个像素的空隙.

所以实际上0比2合理多了.

Nullsoft(WinAmp的创造者)的程序员终于避开了这个禁锢我们十年之久的思考模式. WinAmp有个很棒的功能.

当你把窗口拖到靠近屏幕边缘时(距离几个像素内), 窗口会自动贴齐屏幕的边缘. 这可能正是你要的状况, 因为0实在比2合理多了.

(Juno的主窗口也有个类似的功能: 它是我看过唯一会"限制在框框内", 不能移超过屏幕边缘的应用程序.)

你少了些许的弹性,

不过却因而得到一个能体会精确鼠标操控不易的用户界面, 为什么不用呢? 这种创新(每个程序都可以用到)以聪明的方式简化了窗口管理的负担. 仔细检视你的用户界面,

让大家暂停一下. 假装我们都是大猩猩或是聪明的长臂猿, 而且真的不会用鼠标.

 

程序员的用户界面设计手册

第8章: 为节省大家的麻烦所作的设计, 第三部份

 

作者: Joel Spolsky 约耳.斯珀儿斯奇

译： 梅普华

2000年5月8日

图形用户界面有一个老原则,

就是不应该要人们去记计算机可以记的东西. 最典型的例子就是开启档案的对话框, 它会显示档案的列表, 而不是要求用户回想并输入正确的文件名称.

人们在有线索时更能记住东西, 所以总是喜欢由列表中挑选而不想单靠记忆.

另一个例子就是菜单本身. 看看过去,

提供可用命令的完整菜单已经取代了必须记忆所用命令的旧式命令列界面. 不论你的UNIX朋友怎么说, 这基本上都表示命令列界面不如图形用户界面.

使用命令列界面就像为了在韩国的麦当劳点餐去学韩文. 而菜单示界面就像指着要的食物猛点头:

不需要经过学习曲线却传达了相同的信息.

考虑一个典型绘图程序中的档案选择过程:

 

很幸运的, Windows 98导入了小图标支持, 所以你可以用下面的方式看档案:

 

这样要开启你要的档案就容易多了; 根本不需要花心思把文字对应成图片.

在自动完成之类的功能中也可以看到最小记忆原理的作用. 即使你必须打字,

有些程序还是会推测你要打的是什么:

 

在这个例子中, 只要你打"M", Excel就会猜你可能是要打Male, 因为你在这一栏输入过Male, 所以就提议用这个来自动完成.

不过"ale"会被标成选取状态, 所以万一你不是想输入Male, 你可以继续打字(或许是"ystery"),

亳不费力地覆盖Excel的猜测.

Microsoft Word在猜测你打字时就有点过头了, 每个在欢乐五月用过Word的人都会发现:

 

为节省大家的麻烦所作的设计, 总结

我在这几章总共带出了三个原则:

* 用户不读东西(chapter 6)

*

用户不会用鼠标(chapter 7)

* 用户记不得任何东西

你可能会开始觉得我是把用户当白痴. 这并不是事实.

如果鄙视用户就会制作出Microsoft Bob这种傲慢的软件 (然后再丢到垃圾桶), 结果没有人会很快乐.

其实在软件设计上还有更傲慢自大的状况:

"我的软件酷得不得了, 酷到大家得来个脑筋急转弯才会用." 这种厚脸皮在免费软件世界中相当常见. 嘿, Linux是免费的! 如果你不够聪明搞不懂这东西,

根本就不配用!

人的资质分布是个钟型曲线. 你的客户可能有98%够聪明到能使用电视机. 大约70%能使用Windows. 有15%能使用Linux.

只有1%能写程序. 不过却只有0.1%能用C++之类的语言写程序. 而只有0.01%能搅懂Microsoft ATL程序设计 (而且他们都 留胡子戴眼镜,

没有例外.)

这种快速下降趋势有个结果, 就是只要你"降低门槛"一点点(比如说容易使用10%好了),

能使用的人数就会戏剧性地增加(比如50%).

所以啰, 我并不是真的认为大家都是笨蛋, 而是认为如果你持续努力把程序设计得很容易, 连白痴都能够使用,

你就能做出一个容易用而且人见人爱的程序. 另外你也会很惊讶地发现, 小幅度的可用性改善如何能换来很多的客户.

要评估一个从未看过的程序或对话框的可用性时,

有个好方法就是装得有点笨地使用. 不要读对话框内的文字. 不加验证地随意假设程序运作的方式. 试着只用一根手指操作鼠标. 犯很多的错并且到处乱按.

看看程序是否照你的想法进行, 或者至少能温和地引导你而不会乱掉. 不要那么有耐心. 如果没法子马上得到要的结果就放弃. 如果用户界面无法接受你笨拙不纯熟的动作,

就需要再改进.

程序员的用户界面设计手册

 

第9章: 一个产品的设计程序

作者: Joel Spolsky 约耳.斯珀儿斯奇

译： 梅普华

2000年5月9日

我们已经讲过良好设计的原则, 不过原则只是提供方法来评估并改善现有的设计.

不过...一开始要如何找出正确的设计呢

? 很多人会先写出一大本功能纲要, 涵盖所有想到的功能. 然后设计各个功能并把功能连到菜单项目(或网页)上.

等他们

完全后, 程序(或网站)就会具备所有要的功能, 不过用起来并不顺畅. 人们会看着程序却不知道它能做什么,

也不知道要

如何完成他们要做的事.

Microsoft对这个问题的解决方法是一种叫"活动式规划"(Activity Based

Planning)的方法. (就我所知, 这个概念是

Excel团体的Mike Conte所发明的, 他后来做烦了就改行去当赛车手).

其关键所在是要找出用户会进行的活动, 然后努力

让这些活动很容易完成. 用下面的例子来解释最为贴切.

你决定要架一个网站让大家可以制作贺卡.

如果选用较简单的作法, 你可能会列出如下的功能列表:

 

1. 把文字加入卡片

2. 把图片加入卡片

3. 由卡片库取得预先设计好的卡片

4.

传送卡片:

            a.

透过电子邮件

            b.

打印出来

如果缺乏较好的方法思考这个问题, 很可能就会做出一个大约1984年代麦金塔的典型用户界面: 一个一开始有张空白卡片

的程序,

有几个菜单选项可以加入文字,图片,由卡片库中加载卡片,以及送出卡片. 用户得坐下来浏览各个菜单, 尝试找出

所有可用的命令,

然后各自找出如何结合这些基本命令制作出一张卡片.

活动式规划要求你必须找出一个用户可能会做的活动清单. 所以你就找可能的用户谈,

结果得出这"前三项"列表:

1. 生日贺卡

2. 宴会邀请卡

3. 结婚纪念卡

现在暂时不要用程序员的想法考虑程序(也就是想着制作一张卡片要哪些功能), 要像用户一样地考虑(也就是用户会做哪些

活动).

主要的活动是:

1. 送一张生日贺卡

2. 计画一个宴会, 然后邀请大家来参加

3. 送一张结婚纪念卡

突然间各式各样的点子都出现在你脑海里. 所以一开始可以显示如下的选单而不需要用空白卡片:

 

你想要做什么?

* 送一张生日贺卡

* 送一张结婚纪念卡

* 送一张宴会邀请卡

* 由空白卡片开始

这样用户会突然发现你的程序变得非常容易上手, 他们不再需要先浏览菜单了. 因为基本上程序会引导他们逐步完成所有

的活动.(这里会有个风险,

如果你没有选对活动, 就会疏远或搞混那些原本会用你的程序的用户, 比如说要送贺年卡却找

不到选项.

所以要小心挑选能涵盖大部份目标市场的活动.)

光看到这三个活动就会出现很多可以加的好功能. 举例来说, 如果你正在送一张生日或结婚纪念卡,

可能希望能在明年提

醒你寄卡片给同一个人...所以你可能会勾选写着"明年提醒我"的选项. 另外宴会邀请卡都会需要回复是否能参加,

所以可

以加个功能让你以电子方式收集回函. 这些点子几乎是光看到用户会做的活动就浮现了,

不过看着应用程序的功能是不会

想到的.

这个例子没什么; 不过对正式的应用程序来说, 活动式规划的好处就更可观了. 当你从头设计一个程序时,

你对用户会做

的活动已经有个想法了. 把这个想法弄清楚一点都不难, 几乎不必费什么工夫, 只要和同事做些脑力激荡, 把可能活动都

写下来,

然后决定把重点放在哪些项目. 强迫自己把这些活动写在纸上, 对你的整体设计帮助很大.

当你在制作现有产品第二版时, 活动式规划会变得更重要.

这时候观察客户样本使用你的程序做些什么事, 可能会是件很

重要的事.

从Excel 1.0到4.0这段期间,

Microsoft里大多数人都认为最常见的用户活动是做财务上的仿真分析, (比如改变通货膨胀

率看看获利所受到的影响).

当我们设计Excel

5.0时开始正式使用活动式规划, 大概看了五个客户使用产品之后, 就了解到有很多人只是用Excel来记

录清单. 他们完全不会输入任何公式或做任何计算!

我们以前根本没有考虑过这件事. 结果发现在Excel中保存清单比其它

活动普遍得多. 而这也让我们发明出许多能更容易地保存清单的功能: 更容易的排序,

自动资料输入, 帮助你看到清单某

一部份的自动筛选功能, 以及多用户功能(能让多人同时编辑同一份清单,

Excel会自动处理所有冲突).

当Excel 5正在设计时, Lotus推出了一套"全新典范"的电子表格Improv. 根据新闻稿说,

Improv是全新世代的电子表格,

能把之前所有的产品都干掉. 由于各种奇怪的理由Improv先推出了NeXT版本, 这对产品的销售当然没有帮功,

不过却有很

多聪明人认为Improv之于NeXT就像以前的VisiCalc之于Apple II: 它会是个杀手级应用,

会让人们为了用一个程序而去买

全新的硬件.

当然啦, Improv现在已经是历史的脚注了. 在网络上搜寻这个名字,

唯一找到的是一位太有条理的仓库经理不知为何所建

的网站, 里面列出他们卖不出去放着积灰尘的存货.

为什么呢?

因为在Improv里几乎不可能只制作列表. Improv设计者认为大家都是用电子表格来建立复杂的多维财务模型.

可是如果他们去调查一下,

就会发现制作列表比多维财务模型常用太多了, 可是在Improv里就算有办法制作出列表,

也是

非常的麻烦.

所以活动式规划不光是能帮助应用程序初版(你必须猜测大家所想做的事), 对于打算升级的程序更是有用,

因为你能了解

客户正在做的事.

另外有一个来自网络的例子, 就是deja.com的演进,

它刚开始是个名为dejanews的庞大Usenet可搜寻索引服务. 最初的界

面只有一个编辑框, 写着"search Usenet for blah,"

就只有这样. 在1999年少量的活动式规划显示, 一般用户的活动是

研究产品或服务, 比如研究"我该卖那一种车子"之类的. 后来Deja整个重新组织过,

现在已经偏向于产品意见搜寻服务了:

Usenet搜寻能力几乎被完全隐藏起来. 这对用该网站搜寻Matrox显示卡是否能用于Redhat Linux

5.1的少数用户来说很烦,

却使得绝大多数只想买到最佳数字相机的用户更喜欢.

活动式规划还有另一个好处, 就是能让你做出一份不要做的功能清单.

不管你是要制作任何种类的软件, 都会发现时间只

允许完成1/3的功能. 而决定功能要做或不做的最好方法之一,

就是去评估哪些功能支持最重要的用户活动.

想象用户.

业界最顶尖的用户界面设计者都同意一件事: 你必须先创造并描绘虚构的用户才能开始设计用户界面.

你可以回想我在本

书介绍中所说的虚构用户皮特:

皮特是在某家技术性书刊出版社里工作的会计师, 使用窗口有六年经验, 主要在办公室用,

偶而也会在家里用. 皮特很能

干而且很技术性. 他会自己安装软件; 会阅读PC Magazine, 甚至还能写些简单的Word宏协助办公室的秘书开发票.

他家里

有装缆线调制解调器. 皮特从来没用过麦金塔. "太贵了"他会告诉你说"128MB RAM的700 Mhz PC才多少钱..." 好了,

这就

是皮特. 我们都知道了.

当你在读这段叙述时, 你几乎可以想象出一个用户. 我也创造了另一类的用户:

派翠西亚是个英文教师,

出过很多广为人知的诗集. 她从1980年起就已经用计算机作文书处理, 不过总共只用过Nota Bene

(一套古老的学术用文书处理器)和Microsoft Word两套软件. 她不想花时间了解计算机运作的理论,

而且习惯把所有文件

不更改目录直接存盘.

很显然的, 设计给皮特用的软件和设计给派翠西亚的软件一定会有相当的差异, 当然也和给麦克 (16岁,

在家里用Linux,

会上IRC聊好几个小时, 另外绝对不用"Micro$oft"的软件)用的不一样.

当你创造出这些用户之后,

要考虑你的设计会变得容易许多. 举例来说, 很多程序员都会高估一般用户弄懂事情的能力.

每次当我写说命令列用户界面很难用,

总是会收到一堆邮件说命令列功能超强, 因为可以完成像'gunzip foo.tar.gz |

tar xvf -'之类的工作.

不过当你想想看要派翠西亚键入"gunzip..."时, 立刻就会明白这种界面永远不会符合她的需要.

考虑一个"真实"的人能让你有移情作用,

让你做出符合这个人需要的功能. (当然啦, 如果你是为纯熟的系统管理员制作

Linux备份软件, 就得创造像"法籣克"这些的角色.

他拒绝碰Windows, 而且"操作系统"形容Windows时总是加个问号, 用的

tcsh是自己改过的版本, 他的机器整天都在执行X11

而且开了四个xterm终端机程序. 另外还同时开了大约11个xperf程序

去监看所有计算机的CPU使用量.

总结起来,

设计良好软件大概需要六个步骤:

1. 创造一些用户

2. 找出重要的活动

3. 找出用户模型 -- 用户期望如何完成这些活动

4.

草拟出初版的设计

5. 一直反复把设计修改得更容易, 直到虚构用户能轻易使用为止

6. 找真人来看着他们试用你的软件. 特别注意人们出问题的部份,

这很可能就是程序模型与用户模型不符的地方.

良好的用户界面能让软件大卖, 不过也会让人们快乐, 因为这是人们完成想做的事时的反应.

这也说明为何用户界面设计

是个能令人满足的领域. 还有什么地方能让你有机会让数百万人更快乐一些呢?