Joel on Software 周思博趣談軟體

程式師的使用介面設計手冊
第1章
第2章
第3章
第4章
第5章
第6章
第7章
第8章
第9章

其他Joel on Software文章( 繁體中文)

其他Joel on Software文章(英文)

與作者聯繫 (英文)

當你進餐廳時看到一個告示寫著"不得帶狗進入", 你可能會認為這個告示就只是單純的禁止: 餐廳老闆不喜歡有狗跑來跑去, 所以開餐廳時就加上那個告示.

如果事情只是這樣, 應該也會有"不得帶蛇進入"的告示; 畢竟沒什麼人是喜歡蛇的. 另外也要有"禁止大象進入"告示, 因為大象一坐下來就會壓壞子.

出現這個告示真正的原因其實是歷史性的: 這是個歷史性的標記, 表示以前人們試圖把狗帶進這個餐廳.

大多數禁止告示的出現, 都是因為建物所有人受不了有人一直做某件事, 所以就做了一個標示要求大家別那樣做. 如果你到一家50年以上的老餐廳, 會看到牆上掛滿各種"請不要把背包放在櫃台上"之類的告示, 從人類學來看, 這表示大家曾經很習慣把背包放在櫃台上. 你還可以由告示的年代知道當地的學生是在什麼年代流行使用背包. 

有時候要找出原因會比較困難. "請不要把玻璃瓶帶進公園"一定是表示有人曾經赤腳走在草地上, 結果踩到碎玻璃割傷了, 而且很有可能這些人因此控告政府.

軟體也有類似的人類學記錄: 一般稱之為"選項"對話框. 叫出"工具"下的"選項"對話框, 你就會看到軟體設計者對該產品設計的爭議歷史. 我們是不是應該自動開啟使用者最後所用的檔案呢? 要! 不要! 這件事吵了兩個星期, 大家都不想傷到別人的感覺. 當設計者在爭執時, 程式員為了自保就先用#ifdef把這段程式框起來. 最後大家只好把這變成一個選項.

這甚至不必是兩個人間的爭議: 有可能只是在心中盤算的兩難狀況. 我就是無法決定 要針對大小還是速度來最佳化資料庫. 不管是哪一種型式, 最後都會以"精靈"對話框收場. 而"精靈"對話框無疑是Windows作業系統史上最低能的發明. 這個對話框愚蠢到應該獲頒某個獎, 一個全新種類的獎. 當你試圖從輔助說明中找資料時會出現下面的對話框:

這個對話框的第一個問題是會讓人分心. 你木來是想從說明檔裡找救兵. 根本沒空去管資料庫是大是小還是要微調,或是要塗上一層巧克力. 可是這時候卻跑出這個爛對話框在那裡跩文說它得建立一個清單(或資料庫). 裡面有大約三段文字, 其中大部份都會讓人愈看愈糊塗. 裡面有段很糟糕的字眼"your help file(s)". 你看看, 這表示你可能有一個或多個檔案. 意思好像這個時候你會在意可能有一個以上的檔. 儼然一個或多個檔間是有著極微細的差異. 其實顯然是寫這個對話框的程式員相信說明檔可能不只一個, 並且煩惱怕寫成單數是不對的. 我說的對不對?

我實在懶得再說了, 別說大部份要查說明檔的人不懂這種深奧文字, 連進階使用者也不會懂的. 就是有電腦科學博士學位精通全文檢索的程式人員也搞不清楚這裡究竟要選些什麼.  

更低級的是這還不只是個對話框...這是個精靈(下一頁只會說些廢話, 大意是 "感謝你在這裡殺時間"). 很顯然設計者已經心裡有底知道哪個選擇最好; 畢竟他們還花工夫推薦了其中一個選項.

這讓我們得出使用介面設計的第二項準則:

要求使用者下決定本身並不是件壞事. 能自由選擇是非常美妙的. 人們喜愛到星巴克點咖啡類飲料, 因為得做很多很多的選擇. 來一杯大杯低咖啡因脫脂摩卡,要加瓦倫西亞糖漿和加奶泡. 還有要特別熱的!

問題在於要他們做一個他們根本不在乎的決定. 以上面的說明檔為例, 人們是因為遭遇困難, 無法完成真的要完成的事(如製作生日邀請卡), 才會去看說明檔. 他們沒辦法把汽球圖案倒過來印或是有別的狀況, 只好暫停製作生日邀請卡改去查說明. 結果Microsoft裡某個負責說明檔索引引擎的工程師卻過度膨脹他自己的煩惱, 無禮又厚臉皮 地再度中斷使用者, 而且開始教使用者要製作列表(或資料庫). 這種二次中斷與生日邀請卡完全無關, 保證只會打擾使用者甚至讓使用者掉頭離去.

相信我, 其實使用者所在意的事並沒有你所設想的那麼多. 他們是利用你的軟體去完成某件工作. 他們比較在意工作本身. 如果這是個繪圖程式, 他們可能希望能以最細微的程度控制每一個畫質. 如果這是個建立網站的工具, 可以肯定他們一定會很堅持要做出的網站和他們的設計一模一樣.

不過他們才不會在乎程式的工具列放在視窗上面還是下面. 他們不在意說明檔是否有用索引. 很多東西他們都不在意, 而設計者有責任做這些選擇好讓使用者不必多費心. 替使用者添這種麻煩選項是軟體設計者的傲慢自大, 因為設計者不夠努力思考決定哪個選項比較好. (還有更糟的情況, 就是像WinHelp成員那樣, 明明把難題丟給使用者選擇, 卻把選項轉成精靈型式企圖隱瞞過去. 儼然把使用者當作低能兒, 必須針對這個爛選項上小小兩堂課(兩頁的精靈)才能做出被教出來的決定.)

有人曾說設計是個做選擇的藝術. 當你設計一個放在街角的垃圾桶時, 必須在多個互相衝突的需求間做決擇. 垃圾桶必須重才不會被吹走. 可是要輕才能讓垃圾工方便清理. 要大才能裝很多垃圾. 可是要小才不會佔住人行道. 如果你在設計時想逃避責任而強迫使用者決定某些事情, 十之八九你並沒有盡到本份. 其他人會寫出一個更簡單的程式, 不必那麼煩人就能完成相同的工作, 結果大部份的使用者都會喜歡用這個程式.

當1990年Microsoft Excel 3.0出現時, 它是第一個具備工具列這個新功能的應用程式. 這是個很聰明的功能, 大家都很喜歡, 而且所有人都在抄這個功能 --- 抄到最後幾乎看不到沒有工具列的程式.

工具列非常的成功, 所以Excel團體還對少數人發行特別版本的Excel, 以進行用戶端使用的研究; 這個版本會統計最常用的命令並把結果傳回Microsoft. 然後他們在下一個版本再加了另一列的工具列按鈕, 裡面包括最常用到的命令. 真是棒啊.

問題是他們一直沒有解散工具列小組, 而這個小組似乎也不知道見好就收. 他們要讓你能訂製你自己的工作列. 他們要讓你能把工具列拖到畫面上任何位置. 接下來他們又開始想到, 功能表列其實只是個用文字代替圖示的工具列, 所以也讓你能把功能表列拖放到畫面上任何一個位置. 這種訂製化的能力已經離譜了. 它的問題是沒有人會在意! 我從沒看過有人會把功能表列放在視窗頂端以外的位置. 這裡要講個(爛)笑話: 如果你想拉出檔案功能表, 可是不小心拉到功能表左邊, 結果就把整個功能表列拖到你不要的地方, 然後擋到正在用的文件.

這種事你遇過多少次? 另外一旦不小心弄錯, 實在不清楚自己做錯什麼或要怎麼修復. 所以這裡又會多出現一個選項(是否能移動功能表列), 沒人要(或許會有0.1%的人會要吧)卻又干擾到所有人.

有一天有個朋友打電話給我. 她遇到問題沒法子送出電子郵件. 她說半個畫面都是灰的. 

半個畫面都是灰的?

我在電話上花了五分鐘才弄清楚怎麼回事. 她不小心把Windows工具列拖到畫面右邊, 然後又不小心把工具列拉寬:

這就是那種沒人會故意做的事. 而外頭有很多電腦使用者不知道怎麼解決這種鳥事. 當你不小心改變了程式的選項, 你並不知道如何重新設定. 有件事令人非常驚訝, 很多人會在程式出問題時移除或重裝軟體, 因為這是他們唯一會做的事. (他們得先學會移除軟體, 否則所有錯誤的設定重裝完後依舊存在).

"可是先等一下!" 你會說 "對想要調整環境的進階使用者來說選項非常重要!" 事實上這並沒有你想得那麼重要. 這讓我想起我曾經想改用Dvorak鍵盤. 結果發現我不只用一台電腦. 我用的電腦五花八門什麼都有. 我也會用其他人的電腦. 通常我在家裡會用三台電腦, 在工作時也會用到三台. 我還會用到實驗室裡的電腦. 訂製環境的問題是無法轉移, 所以乾脆不要改變省掉這個麻煩.

大多數進階的使用者通常都會用好幾台電腦; 他們每隔幾年就會把電腦升級, 每三個星期就會重裝作業系統. 他們第一次知道Word的按鍵可以完全重訂時, 的確把所有東西依照自己喜好重新設過. 不過當他們升級到Windows 95並發現以前的設定都不見了, 工作環境也不一樣了, 最後就會放棄,不再重新設定環境. 這件事我問過很多算是"高階使用者"的朋友; 除了要讓系統正常運作的必要修改外, 幾乎沒有人會進行額外的調整.

每當你提供一個選項, 就等於要使用者下一個決定. 這表示他們得考慮某些事並作決策. 這並不一定是壞事, 不過一般而言, 應該要持續努力把使用者必須做的決策數目降到最少.

這並不是要你消除所有的選擇. 無論如何使用者都得做很多的選擇: 文件的外觀如何, 網站要如何運作, 還有其他和使用者工作內容密不可分的項目. 在這些部份就可以儘量發揮:  這時候有選擇是很好的, 而且當然是愈多愈好. 另外還有一類選擇很受歡迎: 就是不影響行為只更改事物外觀的功能. 大家都喜歡WinAmp的換殼功能; 大家都會把桌布設成圖片. 因為這些選擇改變了視覺外觀, 可是完全不會影響任何功能, 另外也因為使用者能完全自由地忽略選擇直接完成工作, 這就是選項的良好應用.