出色图形用户界面（GUI）设计规范
作者： James Hobart
日期： 2001-3-23
转自：http://nku.nankai.edu.cn/cim/students/doctor/spark/articles/PrinciplesOfGUIDesign.htm
译序：我在网上查找中文的 GUI 设计规范，居然没有详细一点的，一篇泛泛而谈的文章却被转载了几十次。只好退而求其次，找来这篇英文的，顺带翻译成中文，以方便国内编程人员。
+++++++++++++++++++++++++++++++++++++++++++++++++
图形用户界面（ GUI ）已经成为用户界面的首选，但不论 GUI 如何流行，令人诧异的是没几个程序有好的界面设计。另外，想找一些介绍如何编制出色用户界面的材料也相当困难。本文给出了出色界面应该如何和不该如何的一些最重要的基本规则。
无论如何，开始谈论什么是好的界面设计之前，我需要解释一下导致差的界面设计的因素。这样，如果你试图偏离那些已经被证明是好的界面设计的原则时，你就会知道是什么导致你如此，我希望，你能回到好的界面设计上来。
忽略了用户
开发者常常只设计他们自己知道的，而非用户知道的东西。这个古老的问题在软件开发的多个领域发生，例如测试、文档编写等等。设计界面时这样会更有害，因为用户在使用产品的时候会立刻感到一点不熟、无所适从。这个错误是最应努力避免的。
由用户控制
GUI 设计者倾向于控制程序是显而易见的，在程序中通过使菜单项和控件变灰或变黑，不断的试图控制用户的走向。控制用户同事件驱动的程序设计风格是极端矛盾的，事件驱动要求是用户而非软件来决定什么事件应该发生。作为开发者，如果你花费了大量的时间在动态的控制控件的变灰和变黑中，就需要反省一下自己的设计方法和实现。可能你正在试图控制用户，而他不希望被控制。在业务变化越来越快的今天，用户界面的弹性将成为适应改变的关键方法。允许用户用各种方式甚至是你自己都想不到的方式使用程序，有点令人心里不安，但这会让你作为开发者很有成就感，同时赋予用户更大的权利。
顶层有太多的功能特性
看一下 1985 年产的录像机，然后再看一下 1995 年产的。你一定会为这两款录像机界面上的差异感到震惊。 1985 年的那款在前面板上会有各种各样易用的按钮，很多按钮会因为你几年前丢了说明书而永远不知道它们是干什么用的。 1995 年的那款可能只有大家常用的几个按钮：播放、快进、倒带、停止和弹出。这款可能比十年前那款有更多的功能，但这些功能将被隐藏在弹出式面板或滑门之后，你需要的时候才去用它们，而不是放在表面上。
同样，你应该只选择常用和易用的功能，避免把所有的东西都放到第一屏或者在工具条上放不常用的按钮。多做一点分析，看看那些功能可以放到隐藏的面板而非前面板。
成功的用户界面（GUI）
现在，让我们谈谈一些成功的 GUI 设计。成功的 GUI 设计具有很多共同的特征。最重要的，出色的图形用户界面（ GUI ）应该是非常带有直觉特征的。实现这些的一个方式是尽可能的采用现实世界中的抽象（暗示、隐喻）。例如，我最近看到一个用 Visa 卡和 Master （万事达）卡图标做为按钮图标的程序，这个按钮用来指示用户如何付款，这个图形立刻使用户产生一种直觉并帮助他们更快的学会使用程序。
出色的用户图形界面的另一个重要特征是速度，更专业一点说，是响应速度。很多速度问题的处理是通过 GUI 而非硬件。根据应用程序的类型，速度可能是决定程序是否被用户群接受的成败关键。例如，如果你的程序是面向在线事务处理（ OLTP ）的，操作太慢很快就会导致用户产生放弃系统的念头。
你可以用几种方法使用户界面上显得很快的样子。除非绝对必要，不要重绘屏幕。另一个方法是使这个屏幕的所有区域同时可用，而非一个区域一个区域的来。另外，根据用户的熟练程度，应该在用户界面中加入一些功能，这些功能可以让熟练用户在不同的区域快速的输入数据。这些功能包括重复功能、快捷键、带有有意义的图标的按钮等等，所有这些可以使速度快的用户可以控制界面并加快数据的输入。
应该怎样和不该怎样
每个好的开发者都应该把目标定在尽可能的设计最好的图形用户界面。 但如何把这个目标变成现实呢？下文中，在各个章节给出了图形用户界面设计的规范（标准）。
同任何出色的专业人士一样，你需要一些可重复的成功设计法则。我们就是用这里提供的法则为我们的客户服务并教授了超过 20000 名的国内国际 GUI 设计专业的学生。这些规范也会对你有帮助的。
对人的理解
程序必须反映用户的视角和行为。要充分理解用户开发者首先要理解人，因为我们都具有共同的特征。人类通过辨别比通过记忆学习起来更容易。要经常试着提供一个数据列表给用户，而非让用户凭记忆自己输入数据。普通人能记住 2000 到 3000 单词，但却可以认出 50000 单词。
留意不同的视角
很多设计者在设计图标或程序整个行为的时候会不自觉的陷入视角陷阱。最近我看到一个图标，它用于在一个会计系统中指明汇总。为了标示这个功能，设计者花了很多心思在画一个把桂圆组合到一起的图标。不幸的是，这个系统的用户对这个图标的喻意更本就没有一点概念，虽然它从设计者的视角来看是非常直观的。保留图标列表中给出了标准图标，如图一所示，可以帮助你消除这些问题。（原 Html 文件中就没图，估计老外也时兴转载）
| Reserved Icons |
||||
| Picture |
Meaning and Behaviour |
Use to Identify an Application |
Used to Identify a Function |
Reserved Word Text Label |
|
|
Information Message |
No |
Yes |
None |
|
|
Warning Message |
No |
Yes |
None |
|
|
Question Message |
No |
Yes |
None |
|
|
Error Message |
No |
Yes |
None |
清楚一致的设计
很多 GUI 程序对最终用户常常不够清楚。一个增强程序清楚表述能力的有效方法是使用列表中的保留字进行开发。用户中最常见的抱怨是某个术语表述的不清楚或不一致。我常常看见开发者们激烈的争论按钮或菜单项上用那个术语更合适，而同时就在一墙之隔的另一群开发者也在争论同样的问题，在程序发布之后，一个屏幕上可能写着“项目”，而下一屏却写着“产品”，而第三屏又变成了“货物”，可是其实这三个术语是指的同一个东西。这种一致性的缺乏导致用户非常迷惑并产生操作失误。
图二给出了保留字列表的一个例子。一个开发小组应该用更多的保留字来完善和扩充这个表。
| 保留字列表 |
|||||
| 文本 |
含义和行为 |
是否出现在按钮上 |
是否出现在菜单上 |
Mnemonic 热键？ |
Shortcut 快捷键？ |
| OK |
接受输入的数据或显示的响应信息，关掉窗口 |
Yes |
No |
None |
<Return> or <Enter> |
| Cancel |
不接受输入的信息，关掉窗口 |
Yes |
No |
None |
Esc |
| Close |
结束当前的任务，让程序继续进行；关掉数据窗口 |
Yes |
Yes |
Alt+C |
None |
| Exit |
推出程序 |
No |
Yes |
Alt+X |
Alt+F4 |
| Help |
调出程序的帮助信息 |
Yes |
Yes |
Alt+H |
Fl |
| Save |
保存数据，停留在当前窗口 |
Yes |
Yes |
Alt+S |
Shift+Fl2 |
| Save As |
用新名字保存数据 |
No |
Yes |
Alt+A |
F12 |
| Undo |
撤销前一个动作 |
No |
Yes |
Alt+U |
Ctrl+Z |
| Cut |
剪切高亮字符 |
No |
Yes |
Alt+T |
Ctrl+X |
| Copy |
拷贝高亮的文本 |
No |
Yes |
Alt+C |
Ctrl+C |
| Paste |
在插入点粘贴被拷贝或剪切的文本 |
No |
Yes |
Alt+P |
Ctrl+V |
同常见软件保持一致性的设计
出色的用户界面在程序中将实现同用户以前用过的其它成功软件一致的动作。写商用程序软件的时候应该尽可能的给用户提供这种一致性。例如， EmbassySuit 和 CourtyardMarriot 连锁旅店增长的非常快，因为商务旅行者知道这些连锁的旅店能为他们提供相似的客房和其它大体差不多的服务。最次也使得商务旅行者不必每到一个新的城市都为找新旅店发愁。你的软件的商务用户有同样的需求。你程序中提供的每个新的特色都可能让用户感到焦躁，迫使他们反复试验或着给你的维护小组打昂贵的长途电话。
提供可视反馈
如果你曾有过傻傻的瞪着自己电脑上显示的沙漏等着一个操作结束的时候，就会明白没有可视化的反馈信息有多糟糕。你的用户非常希望知道一个操作会花费多长的时间以便准备好足够的耐心。作为最一般的规则，当一个操作超过 7 ～ 10 秒的时候，大多数用户希望看到一个带有进度条的消息对话框。时间的长短要根据用户类型和应用程序的特点来调整。
提供声音反馈
上周，我有幸乘坐了一次电梯，这部电梯用悦耳的声音通知乘客他们到那一层了。大楼非常新，而首先，雇员们认为声音非常可爱。一层层的走来走去的六个月后，雇员忽略了声音，开始觉得它厌烦而不认为是一个帮助。同样的事情在你的用户界面上也会发生，除了一个是厌烦的声音限制在电梯之内，一个是到了工作间的每个人的耳朵里。把音效放到几百台电脑上，在开放式的工作间中就会产生刺耳的杂音。但无论如何，声音反馈是有用的，尤其是在你需要警告用户一个严重问题产生的地方，例如进一步的操作将导致数据的丢失或程序出错。允许用户取消声音反馈，除非错误不得不通知。
保持文字内容清楚
开发者常常通过增加大量词汇来尽力使文字反馈内容清楚。但事与愿违，他们最后使消息更不清楚了。简化文本标签、用户错误信息和一行的帮助信息上的词汇是一项挑战。文字反馈的任务可以交给科普作家，通常他们可以高效的处理。
提供操作路径跟踪
如果你的用户曾经说过象这样的话：“我也不知道怎么就到这个窗口了，可是我在这里了，我也不知道怎么才能退回去。”那么就是你没有提供一个可跟踪的路径，或者说，在这种情况下，是一个可重复的操作路径。提供一个可重复的操作路径说着容易做来难。应该从设计简洁的启动你指定的功能的菜单结构开始着手。
你也要指明你菜单结构的展开位置，避免超过两级的级联菜单。为每个对话框提供描述性的标题可以非常有用的提醒用户是哪个菜单项或按钮被按下后把他们带到当前窗口的。
提供键盘支持
键盘是用户桌面上常见的固定设备，为用户输入文本和数据提供了一个有效手段。在介绍图形用户界面程序时，我们常常假定用户把鼠标作为主要的交互设备。而用鼠标操作程序对于录入员或常用用户来讲是非常费时和低效的。
加速建可以给用户提供一种非常有效的操作方式来访问窗口中的指定菜单项和控件。加速建应该易于使用并限制在一到两个键（如 F3 或者 Ctrl-P ）。键盘在 GUI 的世界中有一定的限制，例如在实现象拖拽、点击、变大变小窗口等直接操作任务的时候。相对来说，你总会发现有一小批人坚持用鼠标从不碰键盘。这导致你需要对所有菜单和窗口操作提供完整等价的键盘和鼠标支持。
注意表达模式
把所有界面的各个方面连起来的一个重点是界面的外观和风格。外观和风格必须一致。用户使用一个窗体或对话框过后，在此基础上，他们希望在使用下一个窗体或控件时有同样的感受。
研究好的界面设计模式和连续性是最重要的。决定模式一定要用心，例如程序是有单文档界面还是多文档界面。模式也包括用户如何在程序中完成他们的任务。
指定合适的程序表达方式对开发后续窗口提供了很大的便利，因为它们有很多通用的内在框架。另一方面，如果你不尽早在你的界面设计中定义好表达方式，拖后对程序外观和风格的修改将浪费大量的时间和金钱，因为改动几乎会影响到所有的窗口。
有模式和无模式对话框
当我们需要用户的输入时，我们常常就需要用有模式对话框。使用有模式对话框一直被很多开发者尽量避免，因为它对用户限制太多。但不管怎样，有模式对话框在复杂程序中还是很有用的，因为很多人同一时间只在一个窗口内工作。当有特定任务时可以试着用有模式对话框。对不确定完成时限的任务无模式对话框是一种更好的选择，但有个提示：在同一时刻，要使用户的无模式对话框保持在 3 个以内。如果超过这个数的话，你维护部门的电话就会响个不停了，这时用户就很难把注意力集中到他们的任务上，却要花费很多的时间管理各种各样打开的窗口。利用图三中的表来决定合理的使用对话框和窗口。
| 何时使用对话框、窗口 |
|||
| 类型 |
描述 |
使用 |
例子 |
| 有模式 |
对话框 |
给出一个确定的任务 |
打开文件对话框 |
| 无模式 |
对话框 |
给出一个持久的任务 |
查找框 |
| 应用程序窗口 |
含有子文档窗口的窗口框架 |
给出一个对象的多个实例 |
文字处理 |
| 文档窗口 |
无模式对话框或者被应用程序窗口管理和包含的文档窗口 |
给出一个程序的多个部分 |
数据的多个视图 ( 表单 ) |
| 从属窗口 |
附属应用程序的主窗口 |
给出被父程序调用的另一个程序 |
调出一个程序的帮助 |
控件约定
控件是用户同程序交互的可见单元。用户界面设计人员面对着的控件集合取之不尽。每个新的控件带有自己特定的行为和特征。为每个用户选择合适的控件会产生更高的产出、更低的错误率和更高的用户满意度。可以在你的屏幕上按图四的表中列出的控件用法使用控件。
| 控件使用说明 |
||
| 控件 |
范围内应用的数量 |
控件类型 |
| Menu Bar |
最多十个子项 |
Static action |
| Pull-Down Menu |
最多十二个子项 |
Static action |
| Cascading Menu |
最多五个子项 , 一层级联 |
Static action |
| Pop-up Menu |
最多十个子项 |
Static action |
| Push-button |
每个对话框中最多六个 |
Static action |
| Check Box |
每组最多 10 ～ 12 个 |
Static set/select value |
| Radio Button |
每组最多六个 |
Static set/select value |
| List Box |
表中最多 50 行 , 显示 8 ～ 10 行 |
Dynamic set/select value |
| Drop-down List Box |
控件中一次显示一个选项，下拉框中不超过 20 项 |
Dynamic set/select single value |
| Combination List Box |
控件中按标准格式一次显示一个选项，下拉框中不超过 20 项 |
Dynamic set/select single value; add value to list |
| Spin Button |
最多十个子项 |
Static set/select value |
| Slider |
依赖于显示的数据 |
Static set/select value in range |
最后，尽量在整个应用程序中保持这些控件基本行为和摆放的一致性。一旦你改变这些基本控件的行为，用户就会迷糊。要仔细想过才改，并且这些改变用的时候要一致。
使用设计规范
要理解出色的用户界面设计（ GUI ）背后的规范并把它们应用到自己的程序中是一个挑战。让我们检查一个程序，看看如何应用这些规范来改善界面。
看一看要重新设计的用户界面设计
图五中的界面被一家救护车分派公司用来维护客户数据，提供财务信息和分派救护车。应用程序是从字符系统移植过来的，包含很多设计错误，这些错误将影响到重要任务应用系统程序的用户使用。要记住，在重要应用系统中，界面的清晰简单尤其重要。例如这里，对请求的快速处理攸关生死。这个窗体中有如下错误：
图五
- 顶层有太多的功能。 用户要求新系统方便的提供所有信息，这使得窗体同时用于客户管理和救护车派送。如果你输入完整的客户资料并按更新按钮，记录就更新了。但是，如果你只输入最少量的客户信息，例如社会安全号，诊断，从哪里到哪里，然后按分派按钮，救护车就被派出。更新功能和派送功能需要在不同的对话框中处理。
- 太多按钮。 右侧的按钮应该在父窗口中，也许就在工具栏中，但不应该在子窗口中。
- 差的导向帮助。 GUI 控件应该按使用的频率摆放。最重要的字段应该放在左上；次要的字段应该放在右下。当分派救护车时很难想象公司名和发票号是最重要的字段。
- 控件的不合理使用。 设计者采用了文本标签而不是组别框来区分屏幕上的数据应该归哪一组。这许许多多的文本标签弄得屏幕非常乱同时使数据和标签很难区分。可编辑的字段应该用一个框子框起来，以便可以非常直观的看出那些字段可以更改。
- 缺乏对称性。 简单的调整一些字段、组框和按钮就可以使界面更容易使用。我们的大脑喜欢有序，而非无序。
改进的用户界面
图六和图七展示了同一应用程序大大改进后的界面。
图六
图七
- 不再乱七八糟。 这个应用程序应该有几个子窗口以便用户做不同的任务。这些任务可以简单的通过任务菜单或按竖着的工具条上的按钮来操作。派车按钮调出一个有模式的对话框而非无模式的子窗口。这样，你就可以要求用户确认完成了派车任务。如果用无模式的窗口的话，有可能被用户覆盖掉，甚至根本就没派车。
- 重排了输入字段。 混乱的字段顺序已经按重要性和使用频率更有逻辑性的调整了结构。
- 改进的控件。 修正后的界面显示了数据输入字段使用的一致性。所有用户可以输入数据的字段都被框了起来。组别框被用于分组相关字段或表明一个范围。
利用我们以前讨论过的规范，这些修正使我们得到一个清楚干净的并非常直观的一个界面。
实施有效的标准
当你把一些出色的设计经验应用到你的程序当中时，你怎么保证你的团队中其他人也这么做呢？最有价值效用的使得你的 GUI 程序保持一致性的方法是采用易用、清晰、简明的 GUI 标准。我们都有过这种经验，被积极发放给协作成员的标准手册，立刻就被放到了开发者的书架上，同其它从未读过的标准手册摆在一起。要使你的标准避免这种命运，可以给他们提供在线的超文本格式的标准手册。把你的标准分成一条一条规则和建议，要求开发人员必须遵守，如果违反，要求开发人员给出理由。开发人员希望知道那些是强制执行的那些他们可以由他们自己调整。
总结
无论 GUI 用于哪个平台，九十年代以来对程序开发人员来讲，设计出色的图形用户界面（ GUI ）是一项重要的技能。出色的 GUI 设计不是自发的。它需要开发者学习和应用一些基本的规则，包括设计用户每天都乐于使用的一些东西。它也需要开发人员坚持不懈用这些规则获得尽可能多的经验，以及向出色的 GUI 设计学习。
记住，如果你应用了规范并设计出来出色的用户界面，你的用户利用你为他们设计的界面将更容易和熟练的完成他们的工作。