郑州鲁能公馆户型图:弄清楚别人期待什么

弄清楚别人期待什么

    当一个新用户坐下使用你的软件，他们对于软件的认识并不是一片空白。他们对于程序应该怎么工作有自己的预期。如果他们以前用过相似的软件，他们就会认为这个软件也将那样工作。如果他们以前用过任何软件，他们会认为你的软件应该会符合一些通常的惯例。他们也会聪明的猜出这些UI将会怎么工作。这叫做用户模型：他们对于程序做什么的心理理解。

    程序也有"心理模型"只是以位的形式编码并且会被CPU忠实地执行。这个叫做程序模型，这就是定律。我们从第一章知道，如果程序模型与用户模型相符合，你就有了一个成功的用户界面。

    我们来看一个例子。微软的Word（和大多数文字编辑器），当你把图片放进你的文档里，那个图片实际上被嵌入进同一个文件中。我可以创建图片，拉进文档，然后删除原来的图片文件，当时那张图片还是会保留在文档中。

    现在，HTML不能让你这么做。HTML文档必须和他们的图片分开存储。如果你有一个会使用文字编辑器的用户，但是完全不知道HTML，他坐在一个所见即所得的HTML编辑器前，类似FrontPage，他们就会想当然的认为图片会被存进那个文件中。把这个叫做用户模型惰性。

    因此我们的用户模型（图片会嵌入到文件中）和程序模型（图片必须分开存储）有了一场不愉快的冲突，而且UI必定会引起问题。

    如果你要设计一个类似FrontPage的程序，你会发现你的第一个UI难题。你不能改变HTML。必须想办法协调程序模型和用户模型。

    你有两个选择。你可以改变用户模型。这已经被证明非常困难。你可以在用户手册上解释，但是地球人都知道用户不会去读用户手册，而且他们并不是必须去看。你可以弹出一个对话框解释图片文件并不会嵌入进文件，但是这里会有两个问题：这样会使熟练的用户恼怒，而且用户也不会去看对话框（我们会在第六章详细说明）

    那么，既然改变不了世界那我们就...你最好的选择就是改变程序模型，而不是用户模型。也许当他们插入图片的时候，你可以把那张图片复制进文档文件的子目录里，这样至少你可以用户的想法一样，图片已经被复制了（而且原始图片可以安全的删除）

    我怎么知道用户模型是怎么样的？

    这个被证明是相对简单的。只要询问他们就行了！从你办公室，或者朋友，或者家庭成员中随机挑选5个人，用通用术语告诉他们你的程序是干什么的（"这是一个制作网页的程序"）。然后向他们描述情况："你在做一个网页，一个图片文件Picture.jpg。你把这个图片插入到网页中。"然后问他们一些问题以试着猜测用户模型。"图片到哪里去了？如果你删除了Picture.jpg，网页里的图片还存在吗？"

    我的一个朋友在做照片专辑的应用程序。在你插入照片之后，应用程序会向你显示一组缩略图：每个图片产生一个小图片。生成缩略图需要很长时间，特别是有很多照片的情况下，因此他想要把缩略图保存在硬盘的某个地方，这样缩略图只需要生成一次。这样做可以有很多方式。它们可以存储在一个大的叫Thumbnails 的文件中。它们可以分开存储在Thumbnails的子目录中。它们也可以做个隐藏文件，因此用户就不知道它们了。我的朋友选了一个他认为最佳性价比的方式：把每个图片picture.jpg的缩略图picture_t.jpg放在同一个目录中。如果你做一个有30张图片的专辑，当你这么做了，你的目录下包括缩略图就有60个文件。

    你可以对各种储存照片方式的利与弊争论几个星期，但还有更科学的方式。只需要询问一组用户他们认为缩略图存储到那里了。当然，他们中很多人不知道也不关心，或者他们没有考虑过这个问题，但是如果你问了很多人，你会了解到某种共识。大多数人的选择就是最佳的用户模型，怎么做一个符合的程序模型取决于你。

    下一步，你必须测试你的意见。做一个用户界面的原型，给别人一些任务。他们通过做任务，问他们认为会发什么什么。你的目的是总结出他们什么是他们期待的。如果任务是"插入图片，"你会发现他们会把图片拖进你的软件里，你就会意识到最好支持拖放功能。如果他们找插入菜单，你就会意识到最好在插入菜单中有插入图片选项。如果他们找到字体工具栏，把"Times New Roman"改成"Insert Picture"，那么你发现了还不会使用GUI的原始人，他想要一个文字界面。

    测试你的界面需要多少用户？你的直觉可能是"越多越好，"这在科学实验中说得通。但是这个直觉是错误的。几乎所有以可用性测试的为生的人都认为5-6个人足够了。多于这个，你就会一边又一遍得看到重复现象。任何多余的用户只是浪费时间。

    你不需要专业的可用性测试实验室，你不需要把用户隔离起来-你可以做"50美分可用性测试"，你可以简单的抓一个你看到人然后让他们做一个快速的可用性测试。确定你没有透漏给他们如何做。要求他们想到什么说什么而且要问他们开放式的问题以探索他们的心理模型。

    如果你的程序模型是特立独行的，这个可能就不符合用户模型。

    当我6岁的时候我爸爸带回来世界第一个口袋计算器，HP-35，他想让我相信这里面有一个计算机。我觉得不太可能。星际迷航中所有的计算机都有一个房间那么大而且有盘式磁带录音机。我认为这只是按键和LED显示器的各个元素之间的相互关系产生数学上正确的结果。（嘿，我才6岁）。

    有一个重要的经验心得用户模型通常不会很复杂。当人们不得不猜测程序如何工作的时候，他们倾向于猜测简单的东西，而不是复杂的。

    坐在一台Macintosh前。打开两个Excel文档和一个Word文档。几乎所有的初学者会猜测窗口都是独立的。它们看上去是独立的：

    用户模型说点击Spreadsheet 1会使它显示在前面。实际上发生的情况是Spreadsheet2显示到了前面，几乎给了每个人意外的挫折：

    实际上是这样的，Microsoft Excel的程序模型说"你有这些可视化的表格，每一个对应一个文档，且窗口把这些可视化的表格粘在一起。当你把Excel显示在前端，那么Excel中的所有窗口也都移到前端。"

    是的。可视化表格。用户模型有多大的几率包含了可视化表格的概念？大约是零。因此新用户会对程序的行为但到惊讶。

    另外一个来自Microsoft Windows的例子是Alt+Tab这个切换到下一个窗口的组合键。大部分的用户都假设这个只是简单的在所有窗口中轮流切换。如果你有窗口A，B和C，激活了A，Alt+Tab会切换到B。在按Alt+Tab会切换到C。实际上会发生的事情是，第二次按Alt+Tab会切回到A。切换到C的唯一办法是按住Alt不放，按Tab两次。对于反复切换两个应用程序是很好方法，但是没有人能弄明白，因为这是比轮流切换窗口模型更复杂的模型。

    当用户模型简单的时候，使程序模型和用户模型相符合已经足够难了。当用户模型变得复杂，使两者相符甚至变得不可能了。因此挑一个尽可能简单的用户模型吧。

文章源：CSDN

by Joel Spolsky

Tuesday, April 11, 2000

User Interface Design for Programmers 第二章