出色图形用户界面（GUI）设计规范（转，中英对比）

 

作者：James Hobart

翻译：spark.bbs@bbs.nankai.edu.cn

日期：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 Figure 1
Picture	Meaning and Behaviour	Use to Identify an Application	Used to Identify a Function	Reserved Word Text Label
	Information Message	No	Yes (identifies Information message box)	None
	Warning Message	No	Yes (identifies Warning message box)	None
	Question Message	No	Yes (identifies question message box)	None
	Error Message	No	Yes (identifies error message box)	None

清楚一致的设计

很多GUI程序对最终用户常常不够清楚。一个增强程序清楚表述能力的有效方法是使用列表中的保留字进行开发。用户中最常见的抱怨是某个术语表述的不清楚或不一致。我常常看见开发者们激烈的争论按钮或菜单项上用那个术语更合适，而同时就在一墙之隔的另一群开发者也在争论同样的问题，在程序发布之后，一个屏幕上可能写着“项目”，而下一屏却写着“产品”，而第三屏又变成了“货物”，可是其实这三个术语是指的同一个东西。这种一致性的缺乏导致用户非常迷惑并产生操作失误。

图二给出了保留字列表的一个例子。一个开发小组应该用更多的保留字来完善和扩充这个表。

 

保留字列表 图二
文本	含义和行为	是否出现在按钮上	是否出现在菜单上	Mnemonic Keystrokes 热键？	Shortcut Keystrokes 快捷键？
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设计学习。

记住，如果你应用了规范并设计出来出色的用户界面，你的用户利用你为他们设计的界面将更容易和熟练的完成他们的工作。

---

James Hobart是CCI（Corporate Computing International）的高级顾问，提供关于客户－服务器和GUI的服务，咨询和产品。他擅长大型、大规模的客户－服务器应用程序的开发设计。他对把基于字符的系统移植到图形用户界面的规划和事务处理系统的GUI设计有丰富的经验。可通过70334.3064@compuserve.com同他联系。

 

 

Principles of good GUI Design

Graphical user interfaces (GUIs) have become the user interface of choice. Yet despite the GUI's popularity, surprisingly few programs exhibit good interface design. Moreover, finding information explaining what constitutes a good and intuitive interface is exceedingly difficult. In this article, I describe the basic rules for all good interfaces -the cardinal dos and don'ts.

However, before starting in on what constitutes good design, I need to explain the causes of bad design. This way, if you are tempted to deviate from the tried and true, you'll know where the wrong path leads -and, I hope, get back to good design.

Forgetting the User

Developers often design for what they know, not what the users know. This age-old problem occurs in many other areas of software development, such as testing, documentation, and the like. It is even more pernicious in the interface because it immediately makes the user feel incapable of using the product. Avoid this error diligently.

Give Users Control

GUI designers' predilection for control is evident in applications that continually attempt to control user navigation by graying and blackening menu items or controls within an application. Controlling the user is completely contradictory to event-driven design in which the user rather than the software dictates what events will occur. As a developer, if you are spending a lot of time dynamically graying and blackening controls, you need to re-examine your design approach and realize that you may be controlling the user, who may not want to be controlled. As business changes at a faster pace, flexibility in user interfaces will become a key enabler for change. Allowing the user to access the application in ways you never dreamed can be scary, but satisfying for you as a developer and empowering for the user.

Too Many Features at the Top Level

Examine a VCR built in 1985 and then examine one built in 1995. You will see a startling difference in the interface of the two models. The model built in 1985 will have an abundance of buttons readily available on the faceplate of the unit, many of which will remain a mystery since the manual was lost years ago. The 1995 model will have only a few buttons for the key features people use: play, fast-forward, reverse, stop, and eject. This model will probably have even more features than the model built a decade before, yet the features will be cleverly tucked away behind a drop-down panel or sliding door, accessible when needed but not staring you in the face.

Likewise, you should ensure that features used frequently are readily available. Avoid the temptation to put everything on the first screen or load the toolbar with rarely used buttons. Do the extra analysis to find out which features can go behind the panel instead of on the faceplate.

GUI Successes

Now, let's discuss some GUI successes. Successful GUIs share many common characteristics. Most importantly, good GUIs are more intuitive than their character-based counterparts. One way to achieve this is to use real-world metaphors whenever possible. For example, an application I recently examined used bitmaps of Visa and MasterCard logos on buttons that identified how a customer was going to pay. This graphical representation was immediately intuitive to users and helped them learn the application faster.

Another important characteristic of good GUIs is speed, or more specifically, responsiveness. Many speed issues are handled via the design of the GUI, not the hardware. Depending on the type of application, speed can be the make-or-break factor in determining an application's acceptability in the user community. For example, if your application is oriented toward online transaction processing (OLTP), slow performance will quickly result in users wanting to abandon the system.

You can give a GUI the appearance of speed in several ways. Avoid repainting the screen unless it is absolutely necessary. Another method is to have all field validations occur on a whole-screen basis instead of on a field-by-field basis. Also, depending upon the skills of the user, it may be possible to design features into a GUI that give the power user the capability to enter each field of each data record rapidly. Such features include mnemonics, accelerator keys, and toolbar buttons with meaningful icons, all of which would allow the speed user to control the GUI and rate of data entry.

Dos And Don'ts

Every good developer should have the goal of designing the best GUIs possible. But how does a developer make this goal a reality? By following sound, proven GUI design principles such as those listed in the following sections.

Like any good professional, YOU need some rules for repeatable successful designs. We have used the principles offered here for work with our own customers and have taught more than 20,000 GUI-design students nationally and internationally. These principles should help you as well.

Understand People

Applications must reflect the perspectives and behaviors of their users. To understand users fully, developers must first understand people because we all share common characteristics. People learn more easily by recognition than by recall. Always attempt to provide a list of data values to select from rather than have the users key in values from memory. The average person can recall about 2,000 to 3,000 words, yet can recognize more than 50,000 words.

Be Careful Of Different Perspectives

Many designers unwittingly fall into the perspective trap when it comes to icon design or the overall behavior of the application. I recently saw an icon designed to signify "Rolled Up" totals for an accounting system. To signify this function, the designer put much artistic effort into creating an icon resembling a cinnamon roll. Unfortunately, the users of the system had no idea what metaphor the icon was supposed to represent even though it was perfectly intuitive from the designer's perspective. A reserved-icons table containing standard approved icons, such as the one shown in Figure 1, will help eliminate these problems.

Reserved Icons Figure 1
Picture	Meaning and Behaviour	Use to Identify an Application	Used to Identify a Function	Reserved Word Text Label
	Information Message	No	Yes (identifies Information message box)	None
	Warning Message	No	Yes (identifies Warning message box)	None
	Question Message	No	Yes (identifies question message box)	None
	Error Message	No	Yes (identifies error message box)	None

Design for Clarity

GUI applications often are not clear to end users. One effective way to increase the clarity of applications is to develop and use a list of reserved words. A common complaint among users is that certain terms are not clear or consistent. I often see developers engaging in spirited debates over the appropriate term for a button or menu item, only to see this same debate occurring in an adjacent building with a different set of developers. When the application is released, one screen may say "Item," while the next screen says "Product," and a third says "Merchandise" when all three terms denote the same thing. This lack of consistency ultimately leads to confusion and frustration for users.

Figure 2 gives an example of a list of reserved words. An application-development group might complete and expand the table with additional reserved words.

List of Reserved Words Figure 2
Text	Meaning And Behavior	Appears On Button	Appears On Menu	Mnemonic Keystrokes	Shortcut Keystrokes
OK	Accept data entered or acknowledge information presented and remove the window	Yes	No	None	<Return> or <Enter>
Cancel	Do not accept data entered and remove the window	Yes	No	None	Esc
Close	Close the current task and continue working with the application; close view of data	Yes	Yes	Alt+C	None
Exit	Quit the application	No	Yes	Alt+X	Alt+F4
Help	Invoke the application's Help facility	Yes	Yes	Alt+H	Fl
Save	Save data entered and stay in current window	Yes	Yes	Alt+S	Shift+Fl2
Save As	Save the data with a new name	No	Yes	Alt+A	F12
Undo	Undo the latest action	No	Yes	Alt+U	Ctrl+Z
Cut	Cut the highlighted characters	No	Yes	Alt+T	Ctrl+X
Copy	Copy highlighted text	No	Yes	Alt+C	Ctrl+C
Paste	Paste the copied or cut text at the insertion point	No	Yes	Alt+P	Ctrl+V

Design for Consistency

Good GUIs apply consistent behavior throughout the application and build upon a user's prior knowledge of other successful applications. When writing software for business applications, provide the user with as many consistent behaviors as possible. For example, both the Embassy Suites and Courtyard Marriot hotel chains are growing rapidly due to their popularity among business travelers who know they will be provided with a familiar room and a consistent set of amenities. The bottom line is that business travelers are not looking for a new and exciting experience at each new city. Business users of your software have similar needs. Each new and exciting experience you provide in the software can become an anxiety-inducing experience or an expensive call to your help desk.

Provide Visual Feedback

If you've ever found yourself mindlessly staring at the hourglass on your terminal while waiting for an operation to finish, you know the frustration of poor visual feedback. Your users will greatly appreciate knowing how much longer a given operation will take before they can enjoy the fruits of their patience. As a general rule, most users like to have a message dialog box with a progress indicator displayed when operations are going to take longer than seven to ten seconds. This number is highly variable based on the type of user and overall characteristics of the application.

Provide Audible Feedback

Last week, I had the opportunity to ride in elevators in which a pleasant voice informed riders which floor they were on. The building was fairly new, and at first, employees thought the voice was cute. After six months of traveling floor to floor, employees ignore the voice and see it as more of an annoyance than a help. The same thing can happen with your GUls, except the annoying sounds are not contained within the walls of an elevator, but instead are available to everyone within earshot of the worker's cubicle. Put sound on a few hundred workstations, and a real cacophony emerges in the open-air cubicle environment. However, audible feedback can be useful in cases where you need to warn the user of an impending serious problem, such as one in which proceeding further could cause loss of data or software. Allow users to disable audio feedback, except in cases when an error must be addressed.

Keep Text Clear

Developers often try to make textual feedback clear by adding a lot of words. However, they ultimately make the message less clear. Concise wording of text labels, user error messages, and one-line help messages is challenging. Textual feedback can be handled most effectively by assigning these tasks to experienced technical writers.

Provide Traceable Paths

If your users ever say something akin to, "I don't know how I got to this window, and now that I'm here, I don't know how to get out," then you have not provided a traceable (or, in this case, retraceable) path. Providing a traceable path is harder than it sounds. It starts with an intuitive menu structure from which to launch your specific features.

You must also identify areas where you can flatten the menu structure and avoid more than two levels of cascading menus. Providing a descriptive title bar within each dialog box will help greatly to remind the user what menu items or buttons were pressed to bring them to the window now in focus.

Provide Keyboard Support

Keyboards are a common fixture on users' desktops and provide an efficient means to enter text and data. With the introduction of GUI applications, we often assume users will embrace a mouse as the primary interactive device. This can become time-consuming and inefficient for the touch typist or frequent users of your application.

Keyboard accelerators can provide an efficient way for users to access specific menu items or controls within a window. The accelerators used should be easy to access and limited to one or two keys (such as F3 or Ctrl-P). Keyboards have limitations in the GUI world, such as when trying to implement direct-manipulation tasks like drag and drop, pointing, and resizing.

In contrast, you will always find a smaller set of users who are not touch typists and hence embrace the mouse as a point-and-click nirvana. The result is that you need to provide complete and equal keyboard and mouse support for all menu and window operations.

Watch the Presentation Model

A critical aspect that ties all these facets of the interface together is the interface's look and feel. The look and feel must be consistent. On the basis of users' experiences with one screen or one dialog box, they should have some sense of how to interact with the next screen or control.

Searching the interface model for good design and continuity is most important. The model should involve careful decisions, such as whether the application will have a single or multiple document interface. The model also will validate how users perform their main tasks within the application.

Identifying the appropriate presentation for the application will greatly facilitate the subsequent windows being developed since they will have a common framework to reside in. On the other hand, if you do not define the presentation model early in the design of your GUI, late changes to the look and feel of the application will be much more costly and time-consuming because nearly every window may be affected.

Modal vs. Modeless Dialogs

When we need input from the user, we often use a modal dialog box. Using modal dialogs has long been shunned by many developers as too constraining on the user. However, modal dialogs do have many uses in complex applications since most people only work on one window at a time. Try to use modal dialogs when a finite task exists. For tasks with no fixed duration, modeless dialogs will normally be the preferable choice with a major caveat: Try to keep the user working in no more than three modeless windows at any one time. Go beyond this magical number and the support-desk phones will start ringing as users spend their time managing the various open windows rather than concentrating on their tasks. Use the table in Figure 3 to determine the appropriate use of dialog boxes and windows.

When to Use Dialog Boxes Or Windows Figure 3
Type	Description	Use	Example
Modal	Dialog box	Presentation of a finite task	File Open dialog box Save As dialog box
Modeless	Dialog box	Presentation of an ongoing task	Search dialog box History List dialog box Task List dialog box
Applicaton Window	Window frame with document (child) windows contained within	Presentation of multiple instances of an object Comparison of data within two or more windows	Word Processor Spreadsheet
Document Window	Modeless dialog box or document window contained within and managed by Application window	Presentation of multiple parts of an application	Multiple views of data (sheets)
Secondary Window	Primary window of a secondary application	Presentation of another application called from parent	Invoke Help within an application

Control Design

Controls are the visual elements that let the user interact with the application. GUI designers are faced with an unending array of controls to choose from. Each new control brings with it expected behaviors and characteristics. Choosing the appropriate control for each user task will result in higher prodtictivity, lower error rates, and higher overall user satisfaction. Use the table in Figure 4 as a guideline for control usage in your screens.

Guidelines For Using Controls Figure 4
Control	Number Of Choices In Domain Shown	Type Of Controls
Menu Bar	Maximum 10 items	Static action
Pull-Down Menu	Maximum 12 items	Static action
Cascading Menu	Maximum 5 items, 1 cascade deep	Static action
Pop-up Menu	Maximum 10 items	Static action
Push-button	1 for each button, maximum of 6 per dialog box	Static action
Check Box	1 for each box, maximum of 10 to 12 per group	Static set/select value
Radio Button	1 for each button, maximum of 6 per group box	Static set/select value
List Box	50 in list, display 8 to 10 rows	Dynamic set/select value
Drop-down List Box	Display 1 selection in control at a time, up to 20 in a drop-down box	Dynamic set/select single value
Combination List Box	Display 1 selection in control at a time in standard format up to 20 in a drop-down box	Dynamic set/select single value; add value to list
Spin Button	Maximum 10 values	Static set/select value
Slider	Dependent on data displayed	Static set/select value in range

Finally, try to keep the basic behavior and placement of these controls consistent throughout your application. As soon as you change the behavior of these basic controls, your user will feel lost. Make changes thoughtfully and apply the changes consistently.

Applying Design Principles

Understanding the principles behind good GUI design and applying them to your applications can be a challenge. Let's examine an application to see how these principles can result in an improved interface.

Exploring a GUI Design in Need of Redesign

The interface in Figure 5 is used by an ambulance-dispatching company to maintain customer data, provide billing information, and dispatch ambulances. The application was a port from a character-based system and contains several design errors that affect the user's performance with this mission-critical application. Keep in mind that GUI ease of use and clarity is especially important in a critical application such as this where rapid handling of a request can make the difference between life and death. Here is what is wrong with this screen:

Figure 5

• Too many functions at the top level. The users requested that the new application provide all information at their fingertips. This results in the screen being used for both customer maintenance and ambulance dispatching. If you enter extensive customer information and then press the Update button, the record is updated. However, if you enter minimal customer information, such as Social-security number, diagnosis, from-location, and to-location, then press the Trans button, an ambulance will be dispatched. Updating and dispatching functions need to be on separate dialog boxes.
• Too many buttons. The buttons along the right should be on the application's parent window, possibly in a toolbar, but not on this child window.
• Poor navigational assistance. GUI controls should be positioned according to frequency of use. The most important field should be in the upper left; the least important field should be in the lower right. It's hard to imagine how the company and invoice number could be the most important fields when dispatching an ambulance.
• Inappropriate use of controls. The designer chose to use text labels rather than group boxes to identify which groups of data would be placed in the boxes. This many group boxes with text labels in these positions makes the screen appear convoluted and makes it difficult to distinguish the data from the labels. Also, the editable fields should be identified with a box around them so that it is intuitively obvious which fields can be changed.
• Lack of symmetry. Just lining up fields, group boxes, and buttons will make this GUI much easier to use. Our brains like order, not chaos.

An Improved Interface

Figures 6 and 7 show a much improved interface for this same application:

Figure 6

Figure 7

• Order out of chaos. This application should contain several child windows for the different tasks a user might perform. These tasks can be accessed easily through the Tasks menu or by pushing one button on the vertical toolbar. The Dispatch button invokes a modal dialog box instead of a modeless child window. That way, you can require the user to acknowledge completion of the dispatching task. If it were a modeless window, the user might overlay it without ever dispatching the ambulance.
• Reordering input fields. The confusing order of fields has been more logically structured based on importance and frequency of use.
• Improved controls. The revised interface features consistent use of data-entry fields. Any field in which a user can enter data is surrounded by a border. Group boxes are used to group related fields together or to illustrate a domain.

These changes, suggested by the principles we have previously discussed, make for a clean and more intuitive interface.

Implementing Effective Standards

Once you implement some good design practices into your GUI applications, how do you ensure others in your organization will do the same? The most cost-effective way to ensure consistency among your GUI applications is to implement GUI standards that are easy to use, clear, and concise. We've all experienced the "standards" manual that is energetically distributed to coworkers only to be placed immediately on the developer's shelf next to other unread manuals. To ensure your standards do not meet this same fate, provide them in an online hypertext format. Divide your standards into rules -which must be followed or the developer will have some explaining to do- and recommendations. Developers like to know what is mandatory and where they have discretion.

Conclusion

Designing good GUis is a critical skill for application developers in the 1990s, regardless of the GUI platform for which they are designing. Good GUI designs don't happen naturally. They require that the developer learn and apply some basic principles, including making the design something the user will enjoy working with every day. They also require that the developer get as much experience as possible in working on and being exposed to good GUl designs.

Remember, if you apply the principles and get some experience in good GUI design, your users will have an easier time getting their jobs accomplished using the GUIs you produce for them.

---

James Hobart is a senior consultant with Corporate Computing International (CCI), a provider of client-server and GUI services, consulting, and products. He specializes in the design and development of large-scale, high-volume client-server applications. He has extensive experience in GUI design for transaction-processing systems and strategies for migration from character-based systems. He can be reached at 70334.3064@compuserve.com.