2000年04月11日 使用介面設計手冊第二章 - User Interface Design for Programmers Chapter 2
The Joel on Software Translation Project:使用介面設計手冊第二章
From The Joel on Software Translation Project
Jump to: navigation, search
程式員的使用介面設計手冊 第二章：找出使用者的期望
作者：周思博 (Joel Spolsky)
譯：Paul May 梅普華
Tuesday, April 11, 2000 A part of Joel on Software, http://www.joelonsoftware.com
新使用者在操作一個程式時，心裡絕不會一片空白。他們會先預設程式會如何運作。如果他們以前曾用過類似的軟體，就會假設這個程式的動作應該與其他軟體一樣。如果他們以前沒有用過任何軟體，就會假設你的軟體會遵循某些正常。他們還可能很聰明，會猜測整個使用介面的運作模式。這被稱作使用者模型：也就是使用者心中對程式所做的事的認知。
程式本身也有一個「心智模型」，不過這個模型是用數位方式編碼，并且由CPU确實地執行。這被稱作程式模型，而且是固定不變的。我們在第一章說過，如果程式模型與使用者模型一緻，就能擁有成功的使用介面。
我們來看一個例子。在Microsoft Word(及大多數文書處理器)中，如果在檔案裡放一張圖檔，圖檔會被儲存在該檔案同一個檔案內。你可以建立圖檔并把圖檔拖入檔案內，然後刪除原圖檔檔，而檔案內的圖檔依舊存在。
不過HTML卻不能這樣做。HTML檔案一定得把圖檔放在分開的檔案裡。如果找個慣用文書處理器卻完全不懂HTML的使用者來，請他用FrontPage等還不錯的所見即所得HTML編輯器，他幾乎一定會認為圖檔将會存在同一個檔案裡。這就叫使用者模型慣性(如果你願意這樣叫的話)。
是以使用者模型(圖檔會嵌入在同一個檔案)與程式模型(圖檔必須分開存檔)間就有個讨厭的沖突，這樣使用介面一定會産生問題。
如果你正在設計一個類似FrontPage的程式，這就是你會發現的第一個使用介面問題。你不可能改變HTML。是以一定得做些事讓程式模型符合使用者模型。
你有兩個選擇。你可以嘗試改變使用者模型。不過這點将會非常困難。你可以在手冊裡面解釋清楚，不過大家都知道使用者根本不看手冊，而且他們可能也沒必要看。你也可以顯示一個小對話框說明圖檔檔不會被嵌入，不過這又有兩個問題：熟練的使用者會覺得很煩，另外使用者也可能根本不看對話框。(我們會在第六章深入讨論)。
是以呢，山不轉路轉...最好的選擇通常都是改變你的程式模型而不是使用者模型。或許你可以在插入圖檔時産生一個圖檔複本，存到檔案檔所在處的子目錄中，這樣至少能符合使用者認為圖檔已複制(可以安全地刪除原圖)的印象。
我要怎麼知道使用者模型呢？
這件事其實很容易。隻要問他們就好了！在你的辦公室裡随便抓五個人或是找朋友或家人，然後用普通的說法說明你的程式(這是個制作網頁的程式)。接下去描述狀況：「你正在編一個網頁，現在有張圖叫Picture.JPG。你要把圖插入到網頁內。」然後問幾個問題來猜測他們的使用者模型。比如「圖檔會放在哪裡？」，「如果你刪除Picture.JPG，這個網頁還能正常顯示該圖檔嗎？」
我有個朋友正在做一個相簿形式的應用程式。當你把照片加進去之後，程式會顯示一堆小圖：也就是每張圖的縮圖複本。由于産生小圖要花很長一段時間(如果照片很多時時間更長)，是以他想把小圖存在硬碟某處，這樣小圖隻要産生一次就好了。有很多方法可以達成這個目的。可以把所有小圖存在一個叫小圖的大檔案中。也可以把各個小圖分别存檔，不過放在同一個叫小圖的子目錄內。小圖也可以在作業系統內标示成隐藏檔不讓使用者發現。我的朋友選了一種自認最妥當的方法：把各張圖檔picture.JPG的小圖另存成名為picture_t.JPG的新檔，放在原圖的目錄中。如果你本的圖檔有30張，完成後該目錄含小圖就會有60個檔案。
讨論各種圖檔儲存機制的優缺點可以吵上幾個星期，不過還是有比較科學的作法可以用。隻要問問使用者對小圖存檔的想法就好了。當然會有很多使用者不清楚或不在意或是根本沒想過，不過如果你問過很多人，就會開始看到某些一緻的意見。常見的選擇就是最佳的使用者模型，至于程式模型是否要和使用者模型一緻就是你自己的事了。
接下來你得測試自己的理論。替你的使用介面建一個模型或原型，然後請大家用它完成某些工作。在他們完成的過程中問他們期望發生什麼事。你的目标是找出他們所期望的東西。如果工作內容是「插入一張圖檔」，而你看到他們嘗試把圖檔拖進你的程式裡，你就知道程式最好能支援拖放功能。如果他們去點「插入」功能表，你就知道「插入」功能表下最好能有一個「圖檔」選項。如果他們把「字型」工具列裡的「細明體」換成「插入圖檔」，你就知道這是個沒碰過圖形化使用介面，試圖使用指令列介面的老古董。
那麼要找多少人來測試你的介面呢？你的直覺可能會認為愈多愈好(對科學實驗來說完全正确)。不過你的直覺錯了。幾乎每個靠做可使用性測試為生的人似乎都認為五個或六個人就夠了。超過這個數字之後就會看到結果一直重複，是以繼續做其他使用者隻是浪費時間。
你并不需要一個正式的可使用性實驗室，也不必真的去街上随意挑使用者來做。你可以做個「5毛錢可用性測試」，也就是叫住下一個遇到的人，請他幫忙做個快速的可使用性測試就可以了。不過要注意别說溜嘴先告訴他要怎麼做。應該要他「好好想清楚」，然後再嘗試用開放性的問題找出他們的心智模型。
如果你的程式模型不單純，可能就不是使用者模型。
我6歲時爸爸買了一台世界上第一批的口袋型計算機(HP-35)回家，他努力告訴我那裡頭有一台電腦。我覺得不可能。星艦迷航記裡所有的電腦都是整個房間大小而且都有巨大的碟帶機。我認為隻不過是按鍵的鍵和LED顯示上各個段落有很巧妙的連接配接關系，才會産正正确的數學答案(嘿，我才6歲而已)。
有個很重要的經驗法則，就是使用者模型不會非常複雜。當人們必須猜測程式的運作方式時，答案通常是簡單的而非複雜的。
找台麥金塔坐下來用。打開兩個Excel試算表檔和一個Word檔案檔。幾乎所有生手都會猜測這些視窗間沒有關連。他們看起來就是沒有關系：
從使用者模型來看，點Spreadsheet 1應該會把該視窗叫到最前面。可是實際發生的卻是Spreadsheet 2跑到前面，幾乎對所有人來說這都是個讓人挫折的意外：
實際的情況如下。Microsoft Excel的程式的程式模型認為「你有一些隐藏的試算表，每個試算表都屬于某個應用程式，而視窗是連到這些隐藏的試算表的。當你把Excel叫到最前面時，所有Excel的視窗也會被移到前面。」
沒錯。隐藏的試算表。不過使用者模型裡具有隐藏試算表的機會有多少呢？大概可能是零吧。是以新的使用者總是會被這個行為吓到。
Microsoft Windows上有另一個例子，就是按Alt+Tab鍵可以切到「下一個」視窗。大部份的使用者可能都會假設這個鍵是在所有可用視窗間循環。如果你有A,B,C三個視窗，A視窗是在作用中。按Alt+Tab應該會切到B視窗。再按一次Alt+Tab會切到C視窗。實際上第二次的Alt+Tab會切回A視窗。要切到C視窗一定要按住Alt後再按兩次Tab鍵。這在切換兩個應用程式時還不錯，不過幾乎沒人了解這個方法，因為比起在多個可用視窗間循環的模型來說，這個模型稍嫌複雜。
要讓程式模型遵循簡單的使用者模型已經夠難了。當使用者模型更為複雜時簡直不可能做到。是以要盡可能挑選最簡單的模型。
下一章：選擇
這些網頁的內容為表達個人意見。
All contents Copyright 1999-2002 by Joel Spolsky。All Rights Reserved.