软件用户界面设计规则
--------------------------------------------------------------------------------
用户界面设计基础
不必成为创建用户界面的艺术家--大多数用户界面设计的原则，与任意一门基础艺术课中所讲授的基础设计的原则相同。构图、颜色等的基本的设计原则，就像它们应用在纸张或油画上一样，也能很好地在一台计算机的屏幕上应用。虽然Visual Basic能通过简单地将控件拖动并放置到窗体上而使得创建用户界面非常容易，但是，在设计之前稍微计划一下就能使应用程序的可用性有很大地改观。可能需先在纸上画出窗体开始设计，决定需要哪些控件，不同元素的相对重要性，以及控件之间的关系。
构图
应用程序的观感与感觉窗体的构图或布局不仅影响它的美感，而且也极大地影响应用程序的可用性。构图包括诸如控件的位置、元素的一致性、动感、空白空间的使用以及设计的简单性等因素。控件的位置在大多数界面设计中，不是所有的元素都一样重要。仔细地设计是很有必要的，以确保越是重要的元素越要很快地显现给用户。重要的或者频繁访问的元素应当放在显著的位置上，而不太重要的元素就应当降级到不太显著的位置上。在大多数语言中我们习惯于在一页之中从左到右、自上到下地阅读。对于计算机屏幕也如此，大多数用户的眼睛会首先注视屏幕的左上部位，所以最重要的元素应当放在屏幕的左上部位。例如，如果窗体上的信息与客户有关，则它的名字字段应当显示在它能最先被看到的地方。而按钮，如"确定"或"下一个"，应当放置在屏幕的右下部位；用户在未完成对窗体的操作之前，通常不会访问这些按钮。把元素与控件分成组也很重要。尽量把信息按功能或关系进行逻辑地分组。因为他们的功能彼此相关，所以定位数据库的按钮应当被形象地分成一组，而不是分散在窗体的四处。对信息也是一样，名字字段与地址通常分在一组，因为它们联系紧密。在许多情况下，可以使用框架控件来帮助加强控件之间的联系。
界面元素的一致性
在用户界面设计中，一致性是一种优点。一致的外观与感觉可以在应用程序中创造一种和谐，任何东西看上去都那么协调。如果界面缺乏一致性，则很可能引起混淆，并使应用程序看起来非常混乱、没有条理、价值降低，甚至可能引起对应用程序可靠性的怀疑。为了保持视觉上的一致性，在开始开发应用程序之前应先创建设计策略和类型约定。诸如控件的类型、控件的尺寸、分组的标准以及字体的选取等设计元素都应该在事先确定。可以创建设计样板来帮助进行设计。在Visual Basic中有大量的控件可供使用，这可能引起有人想使用所有的控件。为了避免这种引诱，选取能很好地适合特定应用程序的控件子集。虽然列表框、组合框、网格以及树等控件都可用来表示信息列表，最好还是尽可能使用一种类型。还有，尽量恰当地使用控件，虽然TextBox控件可以设置成只读并用来显示文本，但Label控件通常更适用于该目的。在为控件设置属性时请保持一致性，如果在一个地方为可编辑的文本使用白色背景，除非有很好的理由，否则不要在别的地方又使用灰色。在应用程序中不同的窗体之间保持一致性对其可用性有非常重要的作用。如果在一个窗体上使用了灰色背景以及三维效果，而在另一个窗体上使用白色背景，则这两个窗体就显得毫不相干。选定一种类型并在整个应用程序保持一致，即使这意味着要重新设计某些功能。
动感：窗体与其功能匹配
动感是对象功能的可见线索。虽然对这个术语也许还不熟悉，但动感的实例四处可见。
自行车上的把手，手放在它的上面，动感会将把手用手扣紧这件事显现出来。按下按钮、旋转旋钮和点亮电灯的开关等都能进行动感表示，一看到它们就可以看出其用处。
用户界面也使用动感。例如，用在命令按钮上的三维立体效果使得他们看上去像是被按下去的。如果设计平面边框的命令按钮的话，就会失去这种动感，因而不能清楚地告诉用户它是一个命令按钮。在有些情况下，平面的按钮也许是适合的，比如游戏或者多媒体应用程序；只要在整个应用程序中保持一致就很好。文本框也提供了一种动感，用户可以期望带有边框和白色背景的框，框中包含可编辑的文本。显示不带边框的文本框(BorderStyle = 0)也有可能，这使它看起来像一个标签，并且不能明显地提示用户它是可编辑的。
空白空间的使用
在用户界面中使用空白空间有助于突出元素和改善可用性。空白空间不必非得是白色的--它被认为是窗体控件之间以及控件四周的空白区域。一个窗体上有太多的控件会导致界面杂乱无章，使得寻找一个字段或者控件非常困难。在设计中需要插入空白空间来突出设计元素。各控件之间一致的间隔以及垂直与水平方向元素的对齐也可以使设计更可用。就像杂志中的文本那样，安排得行列整齐、行距一致，整齐的界面也会使其容易阅读。Visual Basic提供了几个工具，使得控件的间距、排列和尺寸的调整非常容易。"排列"、"按相同大小制作"、"水平间距"、"垂直间距"和"在窗体中央"等命令都可以在"格式"菜单中找到。
保持界面的简明
界面设计最重要的原则也许就是简单化。对于应用程序而言，如果界面看上去很难，则可能程序本身也很难。稍稍深入考虑一下便有助于创建看上去（实际上也是）用起来都很简单的界面。从美学的角度来讲，整洁、简单明了的设计常常更可龋在界面设计中，一个普遍易犯的错误就是力图用界面来模仿真实世界的对象。例如，想象一下要求创建完整的保险单的应用程序。很自然的反应就是在屏幕上设计完全仿照保险单的界面。这样做会出现几个问题：保险单的形状与尺寸和屏幕上的有很大不同，要非常完善地复制这样的表格会将其限制在文本框与复选框中，而对用户并没有真正的好处。最好是设计出自己的、也能提供原始保险单打印副本（带打印预览）的界面。通过从原始保险单中创建字段的逻辑组，并使用有标签的界面或几个链接的窗体，就可以不要求滚动屏幕而显示所有的信息。也可以使用附加的控件，比如带有选取预装入的列表框，这些控件可以减少打字工作量。也可以取出不常用的函数并把它们移到它们自己的窗体中去，来简化许多应用程序。提供缺省有时也可以简化应用程序；如果十个用户中有九个选取加粗的文本，就把文本粗体设为缺省值，而不要叫用户每次都选取一遍（不要忘记提供一个选项可以覆盖该缺省值）。向导也有助于简化复杂的或不常用的任务。简化与否最好的检验就是在应用中观察应用程序。如果有代表性的用户没有联机帮助就不能立即完成想要完成的任务，那么就需要重新考虑设计了。
使用颜色与图像
在界面上使用颜色可以增加视觉上的感染力，但是滥用的现象也时有发生。许多显示器能够显示几百万种颜色，这很容易使人要全部使用它们。如果在开始设计时没有仔细地考虑，颜色也会像其他基本设计原则一样，出现许多问题。每个人对颜色的喜爱有很大的不同，用户的品味也会各不相同。颜色能够引发强烈的情感，如果正在设计针对全球读者的程序，那么某些颜色可能有文化上的重大意义。一般说来，最好保守传统，采用一些柔和的、更中性化的颜色。当然，预期的读者以及试图传达的语气与情绪也会影响对颜色的选龋明亮的红色、绿色和黄色适用于小孩子使用的应用程序，但是在银行应用程序中它很难带来财务责任心。少量明亮色彩可以有效地突出或者吸引人们对重要区域的注意。作为经验之谈，应当尽量限制应用程序所用颜色的种类，而且色调也应该保持一致。如果可能的话，最好坚持标准的16色的调色板；在16色显示器上观看时，抖动会使得其他一些颜色显示不出来。使用颜色时另一个需要考虑的问题就是色盲。有一些人不能分辨不同的基色（如红色与绿色）组合之间的差别。对于有这种情况的人，绿色背景上的红色文本就会看不见。
图像和图标
图片与图标的使用也可以增加应用程序的视觉上的趣味，但是，细心的设计也是必不可少的。不用文本，图像就可以形象地传达信息，但常常不同的人对图像的理解也不一样。带有表示各种功能的图标的工具栏，它是一种很有用的界面设备，但如果不能很容易地识别图标所表示的功能，反而会事与愿违。在设计工具栏图标时，应查看一下其它的应用程序以了解已经创建了什么样的标准。例如，许多应用程序用一张角上有卷边的纸来表示"新建文件"图标。也许还有更好的比喻来表示这一功能，但改用其它的表示方法会引起用户的混淆。考虑图像文化上的意义也非常重要。许多程序使用田园风格的带一面旗的邮箱来代表邮件功能。这原本是美国的图标；其他国家/地区或文化的用户也许不把它看作邮箱。在设计自己的图标与图像时，应尽量使它们简单。具有多种颜色的复杂的图片，作为16×16像素的工具栏图标，或者在高分辨率的屏幕上显示时，都不能很好地适应。
选取字体
字体也是用户界面的重要部分，因为它们常常给用户传递重要的信息。需选取在不同的分辨率和不同类型的显示器上都能容易阅读的字体。最好尽量坚持使用简单的无衬线字体或者衬线字体。通常手写字体或者其他装饰性字体的打印效果比屏幕上的效果更好，而且字体越小读起来越难。除非计划按应用程序来配置字体，否则应当坚持使用标准Windows字体，如Arial、New Times Roman或者System。如果用户的系统没有包含指定的字体，系统会使用替代的字体，其结果可能与设想的完全不一样。如果正在为国际读者设计，需要调查在预想的语言里可用什么字体。还有，在为其他语言设计时，需要考虑文本的扩展--有些语言的文本串可以多占50％以上的空间。还有，在选取字体时，设计的一致性非常重要。大多数情况下，不应当在应用程序中使用两种以上字体。太多的字体会使得应用程序看上去像罚款通知单。
可用性设计
任何应用程序的可用性基本上由用户决定。界面设计是需多次反复的过程；在为应用程序设计界面时，第一步就设计出非常完美的界面的情况非常少见。用户参与设计过程越早，花的气力越少，创建的界面越好、越可用。
什么是好的界面
设计用户界面时，开始时最好是先看看Microsoft或其他公司的一些卖得很好的应用程序。毕竟，界面很差的应用程序不会卖得很好。将会发现许多通用的东西，比如：工具栏、状态条、工具提示、上下文菜单以及标记对话框。Visual Basic具有把所有这些东西添加到应用程序中的能力，这并不偶然。也可以凭借自己使用软件的经验。想一想曾经使用过的一些应用程序，哪些可以工作、哪些不可以以及如何修改它。但要记住个人的喜好不等于用户的喜好，必须把自己的意见与用户的意见一致起来。还要注意到大多数成功的应用程序都提供选择来适应不同的用户的偏爱。例如，MicrosoftWindows"资源管理器"允许用户通过菜单、键盘命令或者拖放来复制文件。提供选项会扩大应用程序的吸引力，至少应该使所有的功能都能被鼠标和键盘所访问。
Windows 界面准则
Windows操作系统的主要的优点就是为所有的应用程序提供了公用的界面。知道如何使用基于Windows的应用程序的用户，很容易学会使用其他应用程序。而与已创建的界面准则相差太远的应用程序不易让人明了。菜单就是这方面很好的例子--大多数基于Windows的应用程序都遵循这样的标准："文件"菜单在最左边，然后是"编辑"、"工具"等可选的菜单，最右边是"帮助"菜单。如果说Documents会比File更好，或者"帮助"菜单要放在最前，这就值得讨论一下了。没有任何事情阻止您这样做，但这样做会引起用户的混淆，降低应用程序的可用性。每当在应用程序与其他程序之间切换时，用户都不得不停下来想一想。子菜单的位置也很重要。用户本期望在"编辑"菜单下找到"复制"、"剪切"与"粘贴"等子菜单，若将它们移到"文件"菜单下会引起用户的混乱。不要偏离已经创建的准则太远，除非有很好的理由这样做。
可用性的检测
测试界面可用性的最好方法是在整个设计过程中请用户参与。不论是正在设计大型的压缩包应用程序，还是小型的有限使用的应用程序，设计的过程应当完全相同。使用已创建的设计准则，界面设计应从纸上开始。下一步是创建一个或者多个原型，在Visual Basic中设计窗体。还需要增加足够的代码来启动原型：显示窗体、用示例数据填充列表框等等。然后准备可用性测试。可用性测试可以是个不拘形式的过程：与用户一道审查设计；也可以是在已创建的可用性实验室中进行的正式的过程。这两种方法目的是一样的：从用户那儿了解哪儿设计得很好，哪儿还需要改进的第一手材料。放开，让用户与应用程序在一起，然后观察它们；这种方式比询问用户更为有效。当用户试图完成一系列任务时让他们表达其思考过程："要想打开新文档，所以要在'文件'菜单中找一找。"记下哪些地方的界面设计没有反应他们的思考过程。与不同类型的用户一起测试，如果发现用户完成某个特定的任务有困难，该任务可能需要多加关照。下一步，复查一下记录，考虑如何修改该界面使它更加可用。修改界面并再测试。一旦对应用程序可用性满意，就准备开始编码。在开发的过程中也需要不时地测试来确保对原型的设想是正确的。
功能的可发现性
可用性测试的关键的概念是可发现性。如果用户不能发现如何使用某个功能（或者甚至不知道有此功能存在），则此功能很少有人去使用。例如，Windows 3.1的大多数用户都从来不知道ALT和TAB的组合键可以用于在打开的应用程序之间切换。界面中没有任何地方可提供线索来帮助用户发现这一功能。为了测试功能的可发现性，不解释如何做就要求用户完成一个任务（例如，使用"窗体模板"创建新文档）。如果他们不能完成这个任务，或者尝试了好多次，则此功能的可发现性还需要改进。
当用户或系统出错时与用户交互
在理想世界里，软件与硬件都会无故障地一直工作下去，用户也从不出错。而现实中错误总是难免的。决定当事情出毛病时应用程序如何响应，是用户界面设计的一部分。常用的响应是显示一个对话框，要求用户输入应用程序该如何处理这个问题。不太常用（但更好）的响应是简单地解决问题而不打扰用户。毕竟，用户主要关心的是完成任务，而不是技术细节。在设计用户界面时，考虑可能出现的错误，并判断哪一个需要用户交互作用，哪一个可以按事先安排的方案解决。
创建容易理解的对话框
偶尔应用程序中会出现错误，需要为解决这种情况做出判断。这通常作为代码的分支出现--If...Then语句或者Case语句。如果这个判断需要与用户交互，此问题通常用对话框来提交用户。对话框是用户界面的一部分，像界面的其他部分一样，它们的设计在应用程序可用性中发挥了作用。有时有这样的感觉，好像许多程序对话框的设计员，不会讲使人容易理解的话。比如这样的消息："硬盘C的扇区被损坏或不能访问。中止、重试、忽略？"这对一般的用户而言不大好理解。这等于有侍者问顾客："我们没有汤或者厨房正在生火，中止、重试、忽略?"您会如何回答呢？以用户能理解的方式或短语描述问题（和选择）是重要的。在前面的例子中，更好的消息可以是"在C盘上存文件有问题，请把文件存于A盘。存不存文件?"当为应用程序创建对话框时，心里想着用户。这个消息给用户传达了有用的信息吗？它容易理解吗？命令按钮表示的选择明确吗？这选择适合给定的条件吗？记住，仅仅一个讨厌的消息框就会使用户对应用程序产生坏印象。如果正在设计自定义对话框，尽量坚持用标准类型。如果与标准消息框布局相差太远，用户可能不会把它认作是对话框。
不用对话框的错误处理
当错误出现时不一定要打断用户。有时更可取的是不通知用户而用代码来处理错误，或者以不停止用户工作流程的方法来提醒用户。这个技术的很好的例子是Microsoft Word中的"自动更正"功能：如果普通单词拼错了，Word自动修改它；如果不常用单词拼错了，在其下划一条红线提醒用户以后改正。有大量的技术可以使用，哪些技术适用于应用程序应由自己决定。这里有几个建议：
在"编辑"菜单中添加"撤销"功能。对于删除等情况，与其用"确定"对话框来打断用户，还不如确保他们作出正确的决定并提供"撤销"功能以备他们以后改变主意。
在状态栏或图标上显示消息。如果错误不影响用户当前的任务，不要停止应用程序。使用状态栏或亮色警告图标来警告用户，当他们准备好后可以处理该问题。
改正问题。有时错误的解决办法很显然。例如，当用户试图存文件时磁盘已满，则在其他驱动器中检查系统寻找空间。如果空间可用，则保存该文件；在状态栏中显示一条消息告诉用户做了些什么。
保存消息等候处理。因为不是所有的错误都是紧要的，或要求马上注意的；考虑把这些记录到文件中，当用户退出应用程序时或其他方便的时候再把它们显示给用户。如果用户发生输入错误（如：把Main St.写成Mian St.），记录它。添加"Review Entries"按钮和显示差异的函数，以便用户可以改正它们。
不要做任何事。有时错误并不重要，不足以成为警告的原因。例如，LPT1上的打印机的纸张没准备好这一事实，在准备打印之前并没有多大关系。等待，直到消息合乎当前的任务。
