當我提到一個工具"對用戶不友好"(user-unfriendly)的時候，我總是被人"鄙視"。
難道這就叫"以其人之道還治其人之身"？想當年有人對我抱怨 Linux 或者 TeX 對
用戶不友好的時候，我貌似也差不多的態度吧。現在當我指出 TeX 的各種缺點，
提出新的解決方案的時候，往往會有美國同學眼角一抬，說：
"菜鳥們抱怨工具不好用，那是因為他們不會用。LaTeX 是‘所想即所得’，所以不像 Word 之類的上手。"
殊不知他面前這個"菜鳥"，其實早已把 TeX 的配置搞得滾瓜爛熟，
把 TeXbook 翻來覆去看了兩遍，"double bend" 的習題都全部完成，
可以用 TeX 的語言來寫巨集包。而他被叫做"菜鳥"，這是一個非常有趣的問題。
所以現在拋開個人感情不談，我們來探討一下這種"鄙視"現象產生的原因，
以及什麼叫做"對用戶友好"。
首先我們從心理的角度來分析一下為什麼有人對這種"對用戶不友好"的事實視而不見，
而稱抱怨的用戶為"菜鳥"。
這個似乎很明顯，答案是"優越感"。
如果每個人都會做一件事情，如何能體現出我的超群智力？
所以我就是要專門選擇那種最難用，最晦澀，最顯得高深的東西，把它折騰會。
這樣我就可以被稱為"高手"，就可以傲視群雄。
我不得不承認，我以前也有類似的思想。
從上本科以來我就一直在想，同樣都會寫程式，
是什麼讓電腦系的學生與非電腦系的學生有所不同？
經過多年之後的今天，我終於得到了答案（以後再告訴你）。
可是在多年以前，我犯了跟很多人一樣的錯誤：把"難度"與"智力"或者"專業程度"相等同。
但是其實，一個人會用難用的工具，並不等於他智力超群或者更加專業。
可惜的是，我發現世界上有非常少的人明白這個道理。
在大學裡，公司裡，彰顯自己對難用的工具的掌握程度的人比比皆是。
這不只是對於電腦系統，這也針對數學以及邏輯等抽象的學科。
經常聽人很自豪的說："我準備用XX邏輯設計一個公理化的系統……"
可是這些人其實只知道這個邏輯的皮毛，他們會用這個邏輯，
卻不知道它裡面所有含混晦澀的規則都可以用更簡單更直觀的方法推導出來。
愛因斯坦說：
"Any intelligent fool can make things bigger and more complex...
It takes a touch of genius - and a lot of courage to move in the opposite direction."
我現在深深的體會到這句話的道理。
想要簡化一個東西，讓它更"好用"，你確實需要很大的勇氣。
而且你必須故意的忽略這個東西的一些細節。
但是由於你的身邊都是不理解這個道理的人，他們會把你當成菜鳥或者白癡。
即使你成功了，可能也很難說服他們去嘗試這個簡化後的東西。
那麼現在我們來談一下什麼是"對用戶友好"。
如何定義"對用戶友好"？
如何精確的判斷一個東西是否對用戶友好？
我覺得這是一個現在仍然非常模糊的概念，
但是程式語言的設計思想，特別是其中的類型理論(type theory)可以比較好的解釋它。
我們可以把機器和人看作同一個系統：
1) 這個系統有多個模組，包括機器模組和人類別模組。
2) 機器模組之間的介面使用通用的程式介面。
3) 人機交互的介面就是機器模組和人類別模組之間的介面。
4) 每個介面必須提供一定的抽象，用於防止使用者得到它不該知道的細節。
這個使用者可能是機器模組，也可能是人類別模組。
5) 抽象使得系統具有可擴展性。因為只要介面不變，模組改動之後，它的使用者完全不用修改。
在機器的各個模組間，抽象表現為函數(function)或者方法(method)的類型，
程式的模組(module)定義，作業系統的系統呼叫(system call)，等等。
但是它們的本質都是一樣的：他們告訴使用者"你能用我來幹什麼"。
很多程式設計師都會注意到這些機器介面的抽象，
讓使用者儘量少的接觸到實現細節。
"可是他們卻往往忽視了人和機器之間的介面"
也許他們沒有忽視它，但是他們卻用非常不一樣的設計思想來考慮這個問題。
他們沒有真正把人當成這個系統的一部分，沒有像對待機器模組一樣，提供具有良好抽象的介面給人。
他們貌似覺得人應該可以多做一些事情，所以把紛繁複雜的程式內部結構暴露給人（包括他們自己）。
所以人對"我能用這個程式幹什麼"這個問題總是很糊塗。
當程式被修改之後，還經常需要讓人的操作發生改變，
所以這個系統對於人的可擴展性就差。
通常程式師都考慮到機器各介面之間的擴展性，卻沒有考慮到機器與人之間介面的可擴展性。
舉個例子。很多 Unix 程式都有設定檔，它們也設置環境變數，它們還有命令列參數。
這樣每個用戶都得知道設定檔的名字，位置和格式，環境變數的名字以及意義，命令列參數的意義。
一個程式還好，如果有很多程式，每個程式都在不同的位置放置不同名字的設定檔，
每個設定檔的格式都不一樣，這些配置會把人給搞糊塗。經常出現程式說找不到設定檔，
看手冊吧，手冊說設定檔的位置是某某環境變數 FOO 決定的。改了環境變數卻發現沒有解決問題。
沒辦法，只好上論壇問，終於發現設定檔起作用當且僅當在同一個目錄裡沒有一個叫 ".bar" 的文件。
好不容易記住了這條規則，這個程式升級之後，又把規則給改了，所以這個用戶又繼續琢磨，
繼續上論壇，如此反復。也許這就叫做"折騰"？他何時才能幹自己的事情？
TeX 系統的配置就更為麻煩。
成千上萬個小檔，很少有人理解 kpathsea 的結構和用法，折騰好久才會明白。
但是其實它只是解決一個非常微不足道的問題。TeX 的語言也有很大問題，
使得擴展起來非常困難。這個以後再講。
一個良好的介面不應該是這樣的。
它給予使用者的介面，應該只有一些簡單的設定。
使用者應該用同樣的方法來設置所有程式的所有參數，因為它們只不過是一個從變數到值的映射（map）。
至於系統要在什麼地方存儲這些設定，如何找到它們，具體的格式，用戶根本不應該知道。
這跟高階語言的運行期系統(runtime system)的記憶體管理是一個道理。
程式請求建立一個物件，系統收到指令後分配一塊記憶體，
進行初始化，然後把物件的引用(reference)返回給程式。
程式並不知道物件存在於記憶體的哪個位置，而且不應該知道。
程式不應該使用物件的位址來進行運算。
"對用戶不友好"的背後，其實是程式設計的不合理使得它們缺少抽象化，而不是用戶的問題。
這種對用戶不友好的現象在 Windows，Mac，iPhone, Android 裡也普遍存在。
比如幾乎所有 iPhone 用戶都被洗腦的一個錯誤是"iPhone 只需要一個按鈕"。一個按鈕其實是不夠的。
還有就是像Photoshop, Illustrator, Flash 之類的軟體的功能表介面，
其實把使用者需要的功能和設置給掩藏了起來，分類也經常出現不合理現象，讓他們很難找到這些功能。
如何對用戶更加友好，是一兩句話說不清楚的事情。
所以這裡只粗略說一下我想到過的要點：
1) 統一：隨時注意，人是一個統一的系統的一部分，而不是什麼古怪的神物。
基本上可以把人想像成一個程式模組。
2) 抽象：最大限度的掩蓋程式內部的實現，儘量不讓人知道他不必要知道的東西。
不願意暴露給其它程式模組的細節，也不要暴露給人。"己所不欲，勿施於人"。
3) 充要：提供給人充分而必要（不多於）的機制來完成人想完成的任務。
4) 正交：機制之間應該儘量減少冗餘和重疊，保持正交(orthogonal)。
5) 組合：機制之間應該可以組合(compose)，儘量使得幹同一件事情只有一種組合。
6) 理性：並不是所有人想要的功能都是應該有的，他們經常欺騙自己，
要搞清楚那些是他們真正需要的功能。
7) I/O：人的輸入輸出包括5種感官，雖然通常電腦只與人通過視覺和聽覺交互。
8) 直覺：人是靠直覺和模型(model)思考的，給人的資訊不管是符號還是圖形，
應該容易在人腦中建立起直觀的模型，這樣人才能高效的操作它們。
9) 上下文：人腦的"快取記憶體"的容量是很小的。試試你能同時想起7個人的名字嗎？
所以在任一特定時刻，應該只提供與當前被關注物件相關的操作，
而不是提供所有情況下的所有操作供人選擇。
上下文功能表和依據上下文的鍵盤操作提示，貌似不錯的主意。
文章標籤
全站熱搜
留言列表
