圖形使用者介面(轉)

圖形使用者介面(轉)[@more@]

　　簡介

　　幾年前，使用者必須使用DOS提示符來檢視資料夾的內容，他必須記住並輸入象“dir”或“dir/p”之類的命令。為了這個，使用者必須忍受記住並且在沒有輸入錯誤的情況下在正確的提示符後輸入正確命令的麻煩。由於沒有太多的新方法，這種情況延續了相當一段時間。

　　在那個時候，沒有技術背景的使用者可能會想透過一種更簡單的方法來訪問他系統的內容。。。但如果只是想想，生活將會變得多麼的暇逸，使用者有機會僅僅用少數的按鍵或手指移動來訪問同樣的東西。。。！

　　在早期的計算機裡，在操作員控制檯有除了一些按鈕之外的少量使用者介面或UI。使用者介面很大程度上是穿孔卡片輸入和報表輸出的形式。後來，使用者被提供有和計算機線上互動的能力，並且UI變成了一個帶有一個命令列，鍵盤和一組命令的差不多全黑的螢幕，然後交換計算機響應。這個命令列介面引導為以後的選單控制。

　　現在是圖形使用者介面或GUI發揮貢獻的時候，它為使用者提供了最簡單的方式去真實地形象化的看每一件東西。GUI到來了，主要是由Xerox’s Palo Alto研究中心發起的，Apple電腦吸納並增強，最後再由Microsoft有效的在它的Windows作業系統中標準化。曾一度想象的資料夾樹現在真的被使用者看到了！！UI被設計為一個使用者可以透過螢幕，鍵盤和桌面顯示，明亮的字元，幫助資訊與之互動，以及應用程式或網站如何引發互動並響應它的資訊裝置。

　　這篇文章主要為了讀者從根本上（簡單扼要的）集中瞭解圖形使用者介面，可用性問題，在組織中吸納GUI標準以及執行GUI確認測試的一些簡單步驟。

　　圖形使用者介面GUI

　　GUI讓使用者可以透過圖示和滑鼠與他們的電腦進行互動，而不是在命令列中輸入文字。流行的GUI有Sun Microsystem的OpenWindows，Microsoft的Windows和Apple的Mac OS。一些命令列介面有MS-DOS和Unix。

　　GUI的元素包括窗體，下拉選單，按鈕，捲軸，圖示，嚮導，滑鼠和其他很多東西。隨著多媒體被越來越多做為GUI的一部分使用，聲音，嗓音，動作影片和虛擬真實的介面對於許多應用程式來說似乎很可能成為其GUI的一部分。有時一個系統的GUI連同它的輸入裝置一起被稱為“視覺效果（look-and-feel）”。

　　人機介面HCI

　　人機介面HCI (human-computer interaction)是研究人們如何和電腦互動以及開發計算機和人類可以成功互動的程度。現在很多大公司和學術機構在研究HCI。歷史上和有一些例外，計算機系統開發人員沒有特別重視計算機的易用性（ease-of-use）。今天許多計算機使用者都可以證明計算機制造商仍然沒有花足夠的精力來使他們的產品“使用者介面友好（user-friendly）”。然而，計算機系統開發人員可能會以計算機是一種非常複雜的產品來設計和製造的，並且同樣計算機能夠提供的服務的需求總是要超出易用性的需求作為爭辯。

　　一個重要的HCI因素是不同的使用者形成了不同的觀念或關於他們互動的心理模式，並且有不同的學習及保持知識和技能的方法。另外，文化和地區差異也扮演了部分角色。研究和設計HCI另一個需要考慮的事項是使用者介面技術迅速地變化，為以前可能不適用地研究發現提供了新的互動可能性。最後，當使用者逐漸掌握新的介面時使用者的興趣也隨著變化。

　　為什麼GUI？

　　·　　　　 GUI，眾所周之，是使用影像，輸入的文字，帶圖示的螢幕的計算機介面，取而代之許多鍵盤的功能。

　　·　　　　 許多視力正常的人會發現GUI更容易使用，因為它不需要記住或為每個程式功能查詢特別的命令。

　　·　　　　 只需花很少的時間指出如何讓計算機做你想它做的事

　　·　　　　 盲人和視弱的人可以使用GUI，提供他們一個可信賴的螢幕閱讀器來將螢幕上的東西翻譯成盲字印或合成的語音

　　GUI的歷史簡介

　　GUI的歷史要回溯到1970年代，當時Xerox Palo Alto 研究中心(Parc)建立Smalltalk專案以試圖窺視未來。這個點子是假設在未來計算機的能力會很強大並低廉時，也將產生對這種可利用的力量的最佳使用。產生了兩個有影響的新生事物：名為物件導向程式設計&圖形使用者介面。很快Apple追隨Xerox的足跡。Apple推出了Lisa，一個有著GUI的強大微型計算機。Macintosh在1984年釋出了，由附在9英寸的單色螢幕的盒子的鍵盤和滑鼠和一個單獨的軟盤驅動器的組成。然後推出了帶有512kb的“大”Mac。在那時，介面的風格通常被稱做“Wimp”，來源於“窗體，圖示，選單和指標”元件。GUI－或者甚至很快“gooie”，取代這個名字。

　　可用性為什麼重要？

　　可用性的定義是這樣的：使用者能夠學習操作，準備輸入並且翻譯系統或元件輸出的容易程度[IEEE 90]。

　　採用在今天醫療保健資訊學部門的一些藥房軟體來說明使用有效的介面的重要性。製藥管理是一個重要的任務，包括大量的資料輸入，資料追蹤，問題解決，實際上許多使用者對於程式是非常陌生的，並且他們中的大多數人不想或沒有時間閱讀大量的使用者手冊或支援文件。除了這些，使用者，包括很多計算機學者，試圖有效地利用並使用那些包。背景是很簡單地！程式執行就是它的功能，然後介面是使用者和軟體互動執行多樣任務的方法。對於軟體建立者來說，它是設計，程式碼，功能和組成一個產品的整體程式，然而對於終端使用者而言，它只是構成產品的介面或可用性。

　　日益增加的可用性減少了使用者用於掌握你產品的時間及減少了你技術支援和培訓的費用。確認可用性使你發現並糾正新產品中的問題，並且集中開發資源以準備現有產品的新版本。

　　需要考慮哪些細節呢

　　GUI設計者和/或實現者和/或其他和被開發的GUI產品相關的代表應該：

　　·　　　　 瞭解決定應用程式的可用性和有效性的基本因素

　　·　　　　 能夠將以使用者為中心的設計技術應用到應用程式的設計，實現和評估上

　　·　　　　 知道用於使用者介面設計的最新的趨勢和技術

　　·　　　　 瞭解在Web設計和GUI設計之間的差異

　　·　　　　 感受到UI對於使用者來說就是產品

　　·　　　　 理解UI需要支援使用者的任務

　　·　　　　 意識到增強的可用性增加了使用者的效率，並且減少了維護和支援的工作量

　　除了這些，為了提供好的使用者介面，我們也需要熟悉下面的這些方面。

　　I.　　　　　　理解可用性：使用如排版設計和文字藝術的清晰，一致，混淆的術語（不使用OK，Cancel，Save和其他的按鈕），拙劣的組織(例如：工具欄，選單欄的佈局等)，複雜的選單結構（在一個單獨的選單中有超過2或2層的子選單項），資訊不足的反饋（例如：一個警告訊息呈現一個錯誤！），濫用顏色等，來確定好和壞的可用性之間的差異。

　　II.　　　　　　GUI設計概念：

　　·　　　　 以使用者為中心的設計User-centered Design

　　·　　　　 以系統為中心的設計System-centered Design

　　·　　　　 事件驅動程式設計Event-driven Programming

　　·　　　　 功能可見性，隱喻和操作Affordances, Metaphors & Manipulations

　　III.　　　　　　可用性設計：考慮－以使用者為中心的設計，使用者檔案，使用場景和任務檔案，原型，評估

　　IV.　　　　　　概要設計：包括概念設計，概念設計，隱喻，結構和導航

　　V.　　　　　　詳細設計：包括可用性原則，互動設計，窗體結構，選單&互動，表單，對話方塊，嚮導和反饋技術。

　　VI.　　　　　　視覺設計：包括顏色，字型，圖示和佈局

　　VII.　　　　　　新鮮事物：包括活動桌面，風格指南.

　　VIII.　　　　　　可用性評估技術：使用如下策略：

　　·　　　　 非正式測試

　　Ø　　　 走查

　　Ø　　　 同行評審

　　·　　　　 正式測試

　　Ø　　　 中心小組

　　Ø　　　 問卷

　　Ø　　　 試驗室測試

　　IX.　　　　　　如何提高軟體產品整體的可用性？

　　吸納和實施過程象那些在這裡提及的一樣可以增強可用性。他們是：

　　·　　　　 建立可用性小組&引導可用性研究（和使用者的市場研究）

　　·　　　　 管理專家可用性評審你的產品

　　·　　　　 透過問卷評估產品－內部和外部

　　·　　　　 評審設計備選方案的優點時把中心小組包括進來

　　·　　　　 和使用者一起在他們的地方或是可用性實驗室裡執行基於任務的測試

　　吸納GUI標準的必要性

　　在完成以上所有事項之後，現在，我們該如何有效的將我們想要的結合到我們的程式碼裡呢？提供給使用者一個或兩個實現一些GUI需求的產品是不足夠的。長遠來說，為了達到最大的客戶滿意度及增強業務及時性，任何組織應該力求提供一致的GUI軟體。由開發組織提供的所有產品必須貫穿一致【注意，GUI特徵的更改是從屬於使用者需求的變更】。這就要求GUI標準的文件化，並且需要被嚴格的遵守和實施。在發貨給使用者之前產品必須根據這些標準進行驗證。

　　這也要求在所有的直接和產品開發相關的技術人員之間共享GUI標準工作進展。這可以透過執行組織範圍的培訓達成。讓每個人知道不僅要嚴格實施標準，而且要理解遵循這些標準的需要，這是是很重要的。

　　以下是一些為了標準化，可能需要關注的GUI元素（在一個客戶端/伺服器產品）：

　　（p.s.一下為一些常見的UI名詞，不作翻譯。）

　　Ø　　　 Dialog Boxes – Property, Function, Process and Message Types

　　·　　　　 Modal Dialog

　　·　　　　 Modeless Dialog

　　·　　　　 Search Dialog Boxes

　　·　　　　 Other types of Dialog Boxes

　　Ø　　　 Message Boxes

　　·　　　　 Information

　　·　　　　 Warning

　　·　　　　 Critical

　　Ø　　　 Menus

　　·　　　　 Shortcut Menus

　　·　　　　 Menu Items

　　Ø　　　 Controls

　　·　　　　 Command Buttons

　　·　　　　 Button Action

　　·　　　　 Ellipsis Buttons

　　·　　　　 Option Buttons

　　·　　　　 Check Boxes

　　Ø　　　 Keyboard Support

　　·　　　　 Access Key for OK / Cancel

　　·　　　　 Function Keys as Access Keys

　　Ø　　　 Text / Numeric / Alphanumeric fields

　　·　　　　 Text Boxes

　　·　　　　 List Boxes

　　·　　　　 Check List Boxes

　　·　　　　 List views

　　·　　　　 Combo Box

　　·　　　　 Multi-Line Edit fields

　　Ø　　　 Visual Entities

　　·　　　　 Cursor Movements

　　·　　　　 Tab [Forward Tab]

　　·　　　　 Shift + Tab [Backward Tab]

　　·　　　　 Cursor Movement Keys

　　·　　　　 Default Commands

　　·　　　　 Fonts

　　·　　　　 Capitalization

　　·　　　　 Color

　　Ø　　　 Organization Specific Screens

　　·　　　　 Logon Screen

　　·　　　　 Splash Screen

　　·　　　　 About Screen

　　·　　　　 Screen Navigation

　　Ø　　　 Other GUI Elements

　　·　　　　 Classic Menu

　　·　　　　 Tab Form

　　·　　　　 Multi-page Form

　　·　　　　 Accumulator

　　·　　　　 Access and Exit of all windows

　　我們可能還會有更多的元素增加到這個列表中，象在醫療保健應用程式或每個視窗裡顯示的應用程式的名稱－“Patient Ribbon”。例如，如果我們稱一個應用程式的名稱為“Standard Salary Manager”，開發組織可能想在主應用程式框架的標題欄裡都顯示這個名字。如果在這個應用程式裡有一個功能叫“Employee Gross Salary”，那麼和這些螢幕相關的功能之後為子視窗命名。例如，“Employee Gross Salary – New (to add a new gross salary data for a new employee)”，“Employee Gross Salary – Edit” (to modify a gross salary data for an existing employee)”或“Employee Gross Salary –View” (to read-only the gross salary data for an existing employee)”。

　　GUI確認測試

　　GUI驗證測試主要就是要求確保在編碼過程中嚴格地遵守了每個產品的開發期間需要被實現的標準。主要就是驗證是否遵守植入產品裡的公司自己的GUI標準。

　　下圖（圖1）列舉了一個簡單，但是很有效的執行確認測試的方法。

　　圖1 GUI確認測試的模型

　　一些執行GUI確認測試的指南

　　·　　　　 為了手工測試和自動化（如果有的話）準備GUI測試策略，它可以適用於貫穿所有的專案

　　·　　　　 針對手工測試和自動化，為當前的活動設計GUI測試計劃

　　·　　　　 專門為此活動分配資源&全部時間用於驗證不同專案的GUI特性

　　·　　　　 可以為每個GUI元素準備通用的測試用例文件，它可以適用於被測試的所有應用程式的每個窗體。

　　例如，如果測試人員在某個窗體裡碰到一個單選按鈕，他必須參考單選按鈕測試的測試用例文件，然後驗證是否迎合單選按鈕的所有期望結果。

　　·　　　　 另外一個方法是，透過準備所有標準GUI元素的checklist，然後在測試執行時將結果填在表中，無論期望的行為是否實現。在這種情況下，每個窗體的確認都會有很多的checklist需要填寫。

　　·　　　　 按照設計好的計劃執行/執行測試

　　·　　　　 手工測試是最好的方法之一，因為它節約資源並且在軟體中不時發生變更時通常是最好的，

　　·　　　　 如果你有GUI測試的自動化測試工具，例如Mercury Interactive (WinRunner / Astra QuickTest for Web)或Segue (SilkTest)，它們都可以使用與測試GUI的特性（假設不會太頻繁地對需求做大量的變更）

　　·　　　　 即使採用了自動化測試，最好都要執行手工測試以確保GUI的所有方面，包括那些不可能被自動化的地方

　　·　　　　 自動化測試提供給測試人員速度，可重複性，覆蓋率，可靠性，可重用性&可程式設計性

　　·　　　　 當必須在每個build裡執行測試，針對資料驅動測試，迴歸測試或指令碼的遠端執行，使用不同瀏覽器做的同一測試，關鍵性任務頁面等，自動化測試可能是非常可行的，

　　·　　　　 自動化測試對於一次性測試，ad-hoc測試，沒有預期結果的測試等等，可能是不理想的

　　·　　　　 需要注意的非常重要的事情是，幾乎是很難去檢查指定的畫素是由某某顏色組成，某個物件是否是多少大小。並且在Web裡，如果希望指令碼執行在不同的瀏覽器裡，物件的大小可能不同。除非可用性對於任何一個應用程式都是非常重要的，否則自動化這樣的測試沒有任何希望。

　　·　　　　 一旦執行了測試，就要準備測試結果並且傳送給所有有關的人。測試結果文件可能包括所測試應用程式裡的每一個窗體裡已提交的bug。