出色圖形用戶界面（GUI）設(shè)計規(guī)范

作者：James Hobart

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

日期：2001-3-23

來源：http://nku.nankai.edu.cn/cim/students/doctor/spark/articles/PrinciplesOfGUIDesign.htm

譯序：我在網(wǎng)上查找中文的GUI設(shè)計規(guī)范，居然沒有詳細(xì)一點的，一篇泛泛而談的文章卻被轉(zhuǎn)載了幾十次。只好退而求其次，找來這篇英文的，順帶翻譯成中文，以方便國內(nèi)編程人員。

+++++++++++++++++++++++++++++++++++++++++++++++++

圖形用戶界面（GUI）已經(jīng)成為用戶界面的首選，但不論GUI如何流行，令人詫異的是沒幾個程序有好的界面設(shè)計。另外，想找一些介紹如何編制出色用戶界面的材料也相當(dāng)困難。本文給出了出色界面應(yīng)該如何和不該如何的一些最重要的基本規(guī)則。

無論如何，開始談?wù)撌裁词呛玫慕缑嬖O(shè)計之前，我需要解釋一下導(dǎo)致差的界面設(shè)計的因素。這樣，如果你試圖偏離那些已經(jīng)被證明是好的界面設(shè)計的原則時，你就會知道是什么導(dǎo)致你如此，我希望，你能回到好的界面設(shè)計上來。

忽略了用戶

開發(fā)者常常只設(shè)計他們自己知道的，而非用戶知道的東西。這個古老的問題在軟件開發(fā)的多個領(lǐng)域發(fā)生，例如測試、文檔編寫等等。設(shè)計界面時這樣會更有害，因為用戶在使用產(chǎn)品的時候會立刻感到一點不熟、無所適從。這個錯誤是最應(yīng)努力避免的。

由用戶控制

GUI設(shè)計者傾向于控制程序是顯而易見的，在程序中通過使菜單項和控件變灰或變黑，不斷的試圖控制用戶的走向?？刂朴脩敉录?qū)動的程序設(shè)計風(fēng)格是極端矛盾的，事件驅(qū)動要求是用戶而非軟件來決定什么事件應(yīng)該發(fā)生。作為開發(fā)者，如果你花費(fèi)了大量的時間在動態(tài)的控制控件的變灰和變黑中，就需要反省一下自己的設(shè)計方法和實現(xiàn)?？赡苣阏谠噲D控制用戶，而他不希望被控制。在業(yè)務(wù)變化越來越快的今天，用戶界面的彈性將成為適應(yīng)改變的關(guān)鍵方法。允許用戶用各種方式甚至是你自己都想不到的方式使用程序，有點令人心里不安，但這會讓你作為開發(fā)者很有成就感，同時賦予用戶更大的權(quán)利。

頂層有太多的功能特性

看一下1985年產(chǎn)的錄像機(jī)，然后再看一下1995年產(chǎn)的。你一定會為這兩款錄像機(jī)界面上的差異感到震驚。1985年的那款在前面板上會有各種各樣易用的按鈕，很多按鈕會因為你幾年前丟了說明書而永遠(yuǎn)不知道它們是干什么用的。1995年的那款可能只有大家常用的幾個按鈕：播放、快進(jìn)、倒帶、停止和彈出。這款可能比十年前那款有更多的功能，但這些功能將被隱藏在彈出式面板或滑門之后，你需要的時候才去用它們，而不是放在表面上。

同樣，你應(yīng)該只選擇常用和易用的功能，避免把所有的東西都放到第一屏或者在工具條上放不常用的按鈕。多做一點分析，看看那些功能可以放到隱藏的面板而非前面板。

成功的用戶界面（GUI）

現(xiàn)在，讓我們談?wù)勔恍┏晒Φ?/span>GUI設(shè)計。成功的GUI設(shè)計具有很多共同的特征。最重要的，出色的圖形用戶界面（GUI）應(yīng)該是非常帶有直覺特征的。實現(xiàn)這些的一個方式是盡可能的采用現(xiàn)實世界中的抽象（暗示、隱喻）。例如，我最近看到一個用Visa卡和Master（萬事達(dá)）卡圖標(biāo)做為按鈕圖標(biāo)的程序，這個按鈕用來指示用戶如何付款，這個圖形立刻使用戶產(chǎn)生一種直覺并幫助他們更快的學(xué)會使用程序。

出色的用戶圖形界面的另一個重要特征是速度，更專業(yè)一點說，是響應(yīng)速度。很多速度問題的處理是通過GUI而非硬件。根據(jù)應(yīng)用程序的類型，速度可能是決定程序是否被用戶群接受的成敗關(guān)鍵。例如，如果你的程序是面向在線事務(wù)處理（OLTP）的，操作太慢很快就會導(dǎo)致用戶產(chǎn)生放棄系統(tǒng)的念頭。

你可以用幾種方法使用戶界面上顯得很快的樣子。除非絕對必要，不要重繪屏幕。另一個方法是使這個屏幕的所有區(qū)域同時可用，而非一個區(qū)域一個區(qū)域的來。另外，根據(jù)用戶的熟練程度，應(yīng)該在用戶界面中加入一些功能，這些功能可以讓熟練用戶在不同的區(qū)域快速的輸入數(shù)據(jù)。這些功能包括重復(fù)功能、快捷鍵、帶有有意義的圖標(biāo)的按鈕等等，所有這些可以使速度快的用戶可以控制界面并加快數(shù)據(jù)的輸入。

應(yīng)該怎樣和不該怎樣

每個好的開發(fā)者都應(yīng)該把目標(biāo)定在盡可能的設(shè)計最好的圖形用戶界面。 但如何把這個目標(biāo)變成現(xiàn)實呢？下文中，在各個章節(jié)給出了圖形用戶界面設(shè)計的規(guī)范（標(biāo)準(zhǔn)）。

同任何出色的專業(yè)人士一樣，你需要一些可重復(fù)的成功設(shè)計法則。我們就是用這里提供的法則為我們的客戶服務(wù)并教授了超過20000名的國內(nèi)國際GUI設(shè)計專業(yè)的學(xué)生。這些規(guī)范也會對你有幫助的。

對人的理解

程序必須反映用戶的視角和行為。要充分理解用戶開發(fā)者首先要理解人，因為我們都具有共同的特征。人類通過辨別比通過記憶學(xué)習(xí)起來更容易。要經(jīng)常試著提供一個數(shù)據(jù)列表給用戶，而非讓用戶憑記憶自己輸入數(shù)據(jù)。普通人能記住2000到3000單詞，但卻可以認(rèn)出50000單詞。

留意不同的視角

很多設(shè)計者在設(shè)計圖標(biāo)或程序整個行為的時候會不自覺的陷入視角陷阱。最近我看到一個圖標(biāo)，它用于在一個會計系統(tǒng)中指明匯總。為了標(biāo)示這個功能，設(shè)計者花了很多心思在畫一個把桂圓組合到一起的圖標(biāo)。不幸的是，這個系統(tǒng)的用戶對這個圖標(biāo)的喻意更本就沒有一點概念，雖然它從設(shè)計者的視角來看是非常直觀的。保留圖標(biāo)列表中給出了標(biāo)準(zhǔn)圖標(biāo)，如圖一所示，可以幫助你消除這些問題。（原Html文件中就沒圖，估計老外也時興轉(zhuǎn)載）

清楚一致的設(shè)計

很多GUI程序?qū)ψ罱K用戶常常不夠清楚。一個增強(qiáng)程序清楚表述能力的有效方法是使用列表中的保留字進(jìn)行開發(fā)。用戶中最常見的抱怨是某個術(shù)語表述的不清楚或不一致。我常?？匆婇_發(fā)者們激烈的爭論按鈕或菜單項上用那個術(shù)語更合適，而同時就在一墻之隔的另一群開發(fā)者也在爭論同樣的問題，在程序發(fā)布之后，一個屏幕上可能寫著“項目”，而下一屏卻寫著“產(chǎn)品”，而第三屏又變成了“貨物”，可是其實這三個術(shù)語是指的同一個東西。這種一致性的缺乏導(dǎo)致用戶非常迷惑并產(chǎn)生操作失誤。

圖二給出了保留字列表的一個例子。一個開發(fā)小組應(yīng)該用更多的保留字來完善和擴(kuò)充這個表。

同常見軟件保持一致性的設(shè)計

出色的用戶界面在程序中將實現(xiàn)同用戶以前用過的其它成功軟件一致的動作。寫商用程序軟件的時候應(yīng)該盡可能的給用戶提供這種一致性。例如，EmbassySuit和CourtyardMarriot連鎖旅店增長的非?？欤驗樯虅?wù)旅行者知道這些連鎖的旅店能為他們提供相似的客房和其它大體差不多的服務(wù)。最次也使得商務(wù)旅行者不必每到一個新的城市都為找新旅店發(fā)愁。你的軟件的商務(wù)用戶有同樣的需求。你程序中提供的每個新的特色都可能讓用戶感到焦躁，迫使他們反復(fù)試驗或著給你的維護(hù)小組打昂貴的長途電話。

提供可視反饋

如果你曾有過傻傻的瞪著自己電腦上顯示的沙漏等著一個操作結(jié)束的時候，就會明白沒有可視化的反饋信息有多糟糕。你的用戶非常希望知道一個操作會花費(fèi)多長的時間以便準(zhǔn)備好足夠的耐心。作為最一般的規(guī)則，當(dāng)一個操作超過7～10秒的時候，大多數(shù)用戶希望看到一個帶有進(jìn)度條的消息對話框。時間的長短要根據(jù)用戶類型和應(yīng)用程序的特點來調(diào)整。

提供聲音反饋

上周，我有幸乘坐了一次電梯，這部電梯用悅耳的聲音通知乘客他們到那一層了。大樓非常新，而首先，雇員們認(rèn)為聲音非常可愛。一層層的走來走去的六個月后，雇員忽略了聲音，開始覺得它厭煩而不認(rèn)為是一個幫助。同樣的事情在你的用戶界面上也會發(fā)生，除了一個是厭煩的聲音限制在電梯之內(nèi)，一個是到了工作間的每個人的耳朵里。把音效放到幾百臺電腦上，在開放式的工作間中就會產(chǎn)生刺耳的雜音。但無論如何，聲音反饋是有用的，尤其是在你需要警告用戶一個嚴(yán)重問題產(chǎn)生的地方，例如進(jìn)一步的操作將導(dǎo)致數(shù)據(jù)的丟失或程序出錯。允許用戶取消聲音反饋，除非錯誤不得不通知。

保持文字內(nèi)容清楚

開發(fā)者常常通過增加大量詞匯來盡力使文字反饋內(nèi)容清楚。但事與愿違，他們最后使消息更不清楚了。簡化文本標(biāo)簽、用戶錯誤信息和一行的幫助信息上的詞匯是一項挑戰(zhàn)。文字反饋的任務(wù)可以交給科普作家，通常他們可以高效的處理。

提供操作路徑跟蹤

如果你的用戶曾經(jīng)說過象這樣的話：“我也不知道怎么就到這個窗口了，可是我在這里了，我也不知道怎么才能退回去。”那么就是你沒有提供一個可跟蹤的路徑，或者說，在這種情況下，是一個可重復(fù)的操作路徑。提供一個可重復(fù)的操作路徑說著容易做來難。應(yīng)該從設(shè)計簡潔的啟動你指定的功能的菜單結(jié)構(gòu)開始著手。

你也要指明你菜單結(jié)構(gòu)的展開位置，避免超過兩級的級聯(lián)菜單。為每個對話框提供描述性的標(biāo)題可以非常有用的提醒用戶是哪個菜單項或按鈕被按下后把他們帶到當(dāng)前窗口的。

提供鍵盤支持

鍵盤是用戶桌面上常見的固定設(shè)備，為用戶輸入文本和數(shù)據(jù)提供了一個有效手段。在介紹圖形用戶界面程序時，我們常常假定用戶把鼠標(biāo)作為主要的交互設(shè)備。而用鼠標(biāo)操作程序?qū)τ阡浫雴T或常用用戶來講是非常費(fèi)時和低效的。

加速建可以給用戶提供一種非常有效的操作方式來訪問窗口中的指定菜單項和控件。加速建應(yīng)該易于使用并限制在一到兩個鍵（如F3或者Ctrl-P）。鍵盤在GUI的世界中有一定的限制，例如在實現(xiàn)象拖拽、點擊、變大變小窗口等直接操作任務(wù)的時候。相對來說，你總會發(fā)現(xiàn)有一小批人堅持用鼠標(biāo)從不碰鍵盤。這導(dǎo)致你需要對所有菜單和窗口操作提供完整等價的鍵盤和鼠標(biāo)支持。

注意表達(dá)模式

把所有界面的各個方面連起來的一個重點是界面的外觀和風(fēng)格。外觀和風(fēng)格必須一致。用戶使用一個窗體或?qū)υ捒蜻^后，在此基礎(chǔ)上，他們希望在使用下一個窗體或控件時有同樣的感受。

研究好的界面設(shè)計模式和連續(xù)性是最重要的。決定模式一定要用心，例如程序是有單文檔界面還是多文檔界面。模式也包括用戶如何在程序中完成他們的任務(wù)。

指定合適的程序表達(dá)方式對開發(fā)后續(xù)窗口提供了很大的便利，因為它們有很多通用的內(nèi)在框架。另一方面，如果你不盡早在你的界面設(shè)計中定義好表達(dá)方式，拖后對程序外觀和風(fēng)格的修改將浪費(fèi)大量的時間和金錢，因為改動幾乎會影響到所有的窗口。

有模式和無模式對話框

當(dāng)我們需要用戶的輸入時，我們常常就需要用有模式對話框。使用有模式對話框一直被很多開發(fā)者盡量避免，因為它對用戶限制太多。但不管怎樣，有模式對話框在復(fù)雜程序中還是很有用的，因為很多人同一時間只在一個窗口內(nèi)工作。當(dāng)有特定任務(wù)時可以試著用有模式對話框。對不確定完成時限的任務(wù)無模式對話框是一種更好的選擇，但有個提示：在同一時刻，要使用戶的無模式對話框保持在3個以內(nèi)。如果超過這個數(shù)的話，你維護(hù)部門的電話就會響個不停了，這時用戶就很難把注意力集中到他們的任務(wù)上，卻要花費(fèi)很多的時間管理各種各樣打開的窗口。利用圖三中的表來決定合理的使用對話框和窗口。

控件約定

控件是用戶同程序交互的可見單元。用戶界面設(shè)計人員面對著的控件集合取之不盡。每個新的控件帶有自己特定的行為和特征。為每個用戶選擇合適的控件會產(chǎn)生更高的產(chǎn)出、更低的錯誤率和更高的用戶滿意度。可以在你的屏幕上按圖四的表中列出的控件用法使用控件。

最后，盡量在整個應(yīng)用程序中保持這些控件基本行為和擺放的一致性。一旦你改變這些基本控件的行為，用戶就會迷糊。要仔細(xì)想過才改，并且這些改變用的時候要一致。

使用設(shè)計規(guī)范

要理解出色的用戶界面設(shè)計（GUI）背后的規(guī)范并把它們應(yīng)用到自己的程序中是一個挑戰(zhàn)。讓我們檢查一個程序，看看如何應(yīng)用這些規(guī)范來改善界面。

看一看要重新設(shè)計的用戶界面設(shè)計

圖五中的界面被一家救護(hù)車分派公司用來維護(hù)客戶數(shù)據(jù)，提供財務(wù)信息和分派救護(hù)車。應(yīng)用程序是從字符系統(tǒng)移植過來的，包含很多設(shè)計錯誤，這些錯誤將影響到重要任務(wù)應(yīng)用系統(tǒng)程序的用戶使用。要記住，在重要應(yīng)用系統(tǒng)中，界面的清晰簡單尤其重要。例如這里，對請求的快速處理攸關(guān)生死。這個窗體中有如下錯誤：

圖五

• 頂層有太多的功能。用戶要求新系統(tǒng)方便的提供所有信息，這使得窗體同時用于客戶管理和救護(hù)車派送。如果你輸入完整的客戶資料并按更新按鈕，記錄就更新了。但是，如果你只輸入最少量的客戶信息，例如社會安全號，診斷，從哪里到哪里，然后按分派按鈕，救護(hù)車就被派出。更新功能和派送功能需要在不同的對話框中處理。
• 太多按鈕。右側(cè)的按鈕應(yīng)該在父窗口中，也許就在工具欄中，但不應(yīng)該在子窗口中。
• 差的導(dǎo)向幫助。GUI控件應(yīng)該按使用的頻率擺放。最重要的字段應(yīng)該放在左上；次要的字段應(yīng)該放在右下。當(dāng)分派救護(hù)車時很難想象公司名和發(fā)票號是最重要的字段。
• 控件的不合理使用。設(shè)計者采用了文本標(biāo)簽而不是組別框來區(qū)分屏幕上的數(shù)據(jù)應(yīng)該歸哪一組。這許許多多的文本標(biāo)簽弄得屏幕非常亂同時使數(shù)據(jù)和標(biāo)簽很難區(qū)分。可編輯的字段應(yīng)該用一個框子框起來，以便可以非常直觀的看出那些字段可以更改。
• 缺乏對稱性。簡單的調(diào)整一些字段、組框和按鈕就可以使界面更容易使用。我們的大腦喜歡有序，而非無序。

改進(jìn)的用戶界面

圖六和圖七展示了同一應(yīng)用程序大大改進(jìn)后的界面。

圖六

圖七

• 不再亂七八糟。這個應(yīng)用程序應(yīng)該有幾個子窗口以便用戶做不同的任務(wù)。這些任務(wù)可以簡單的通過任務(wù)菜單或按豎著的工具條上的按鈕來操作。派車按鈕調(diào)出一個有模式的對話框而非無模式的子窗口。這樣，你就可以要求用戶確認(rèn)完成了派車任務(wù)。如果用無模式的窗口的話，有可能被用戶覆蓋掉，甚至根本就沒派車。
• 重排了輸入字段。混亂的字段順序已經(jīng)按重要性和使用頻率更有邏輯性的調(diào)整了結(jié)構(gòu)。
• 改進(jìn)的控件。修正后的界面顯示了數(shù)據(jù)輸入字段使用的一致性。所有用戶可以輸入數(shù)據(jù)的字段都被框了起來。組別框被用于分組相關(guān)字段或表明一個范圍。

利用我們以前討論過的規(guī)范，這些修正使我們得到一個清楚干凈的并非常直觀的一個界面。

實施有效的標(biāo)準(zhǔn)

當(dāng)你把一些出色的設(shè)計經(jīng)驗應(yīng)用到你的程序當(dāng)中時，你怎么保證你的團(tuán)隊中其他人也這么做呢？最有價值效用的使得你的GUI程序保持一致性的方法是采用易用、清晰、簡明的GUI標(biāo)準(zhǔn)。我們都有過這種經(jīng)驗，被積極發(fā)放給協(xié)作成員的標(biāo)準(zhǔn)手冊，立刻就被放到了開發(fā)者的書架上，同其它從未讀過的標(biāo)準(zhǔn)手冊擺在一起。要使你的標(biāo)準(zhǔn)避免這種命運(yùn)，可以給他們提供在線的超文本格式的標(biāo)準(zhǔn)手冊。把你的標(biāo)準(zhǔn)分成一條一條規(guī)則和建議，要求開發(fā)人員必須遵守，如果違反，要求開發(fā)人員給出理由。開發(fā)人員希望知道那些是強(qiáng)制執(zhí)行的那些他們可以由他們自己調(diào)整。

總結(jié)

無論GUI用于哪個平臺，九十年代以來對程序開發(fā)人員來講，設(shè)計出色的圖形用戶界面（GUI）是一項重要的技能。出色的GUI設(shè)計不是自發(fā)的。它需要開發(fā)者學(xué)習(xí)和應(yīng)用一些基本的規(guī)則，包括設(shè)計用戶每天都樂于使用的一些東西。它也需要開發(fā)人員堅持不懈用這些規(guī)則獲得盡可能多的經(jīng)驗，以及向出色的GUI設(shè)計學(xué)習(xí)。

記住，如果你應(yīng)用了規(guī)范并設(shè)計出來出色的用戶界面，你的用戶利用你為他們設(shè)計的界面將更容易和熟練的完成他們的工作。

James Hobart是CCI（Corporate Computing International）的高級顧問，提供關(guān)于客戶－服務(wù)器和GUI的服務(wù)，咨詢和產(chǎn)品。他擅長大型、大規(guī)模的客戶－服務(wù)器應(yīng)用程序的開發(fā)設(shè)計。他對把基于字符的系統(tǒng)移植到圖形用戶界面的規(guī)劃和事務(wù)處理系統(tǒng)的GUI設(shè)計有豐富的經(jīng)驗?？赏ㄟ^70334.3064@compuserve.com同他聯(lián)系。

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.

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.

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.

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.

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:

• 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:

• 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.