什么是“對用戶友好”

　　當我提到一個工具“對用戶不友好”(user-unfriendly)的時候，我總是被人“鄙視”。難道這就叫“以其人之道還治其人之身”?想當年有人對我抱怨 Linux 或者 TeX 對用戶不友好的時候，我貌似也差不多的態度吧?，F在當我指出 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 ofcourageto move in the opposite direction.”我現在深深的體會到這句話的道理。想要簡化一個東西，讓它更“好用”，你確實需要很大的勇氣。而且你必須故意的忽略這個東西的一些細節。但是由于你的身邊都是不理解這個道理的人，他們會把你當成菜鳥或者白癡。即使你成功了，可能也很難說服他們去嘗試這個簡化后的東西。

　　那么現在我們來談一下什么是“對用戶友好”。如何定義“對用戶友好”?如何精確的判斷一個東西是否對用戶友好?我覺得這是一個現在仍然非常模糊的概念，但是程序語言的設計思想，特別是其中的類型理論(type theory)可以比較好的解釋它。我們可以把機器和人看作同一個系統：

　　這個系統有多個模塊，包括機器模塊和人類模塊。

　　機器模塊之間的界面使用通常的程序接口。

　　人機交互的界面就是機器模塊和人類模塊之間的接口。

　　每個界面必須提供一定的抽象，用于防止使用者得到它不該知道的細節。這個使用者可能是機器模塊，也可能是人類模塊。

　　抽象使得系統具有可擴展性。因為只要界面不變，模塊改動之后，它的使用者完全不用修改。

　　在機器的各個模塊間，抽象表現為函數或者方法的類型(type)，程序的模塊(module)定義，操作系統的系統調用(system call)，等等。但是它們的本質都是一樣的：他們告訴使用者“你能用我來干什么”。很多程序員都會注意到這些機器界面的抽象，讓使用者盡量少的接觸到實現細節?？墒撬麄儏s往往忽視了人和機器之間的界面。也許他們沒有忽視它，但是他們卻用非常不一樣的設計思想來考慮這個問題。他們沒有真正把人當成這個系統的一部分，沒有像對待其它機器模塊一樣，提供具有良好抽象的界面給人。他們貌似覺得人應該可以多做一些事情，所以把紛繁復雜的程序內部結構暴露給人(包括他們自己)。所以人對“我能用這個程序干什么”這個問題總是很糊涂。當程序被修改之后，還經常需要讓人的操作發生改變，所以這個系統對于人的可擴展性就差。通常程序員都考慮到機器各界面之間的擴展性，卻沒有考慮到機器與人之間界面的可擴展性。

　　舉個例子。很多 Unix 程序都有配置文件，它們也設置環境變量，它們還有命令行參數。這樣每個用戶都得知道配置文件的名字，位置和格式，環境變量的名字以及意義，命令行參數的意義。一個程序還好，如果有很多程序，每個程序都在不同的位置放置不同名字的配置文件，每個配置文件的格式都不一樣，這些配置會把人給搞糊涂。經常出現程序說找不到配置文件，看手冊吧，手冊說配置文件的位置是某某環境變量 FOO 決定的。改了環境變量卻發現沒有解決問題。沒辦法，只好上論壇問，終于發現配置文件起作用當且僅當在同一個目錄里沒有一個叫 ".bar" 的文件。好不容易記住了這條規則，這個程序升級之后，又把規則給改了，所以這個用戶又繼續琢磨，繼續上論壇，如此反復。也許這就叫做“折騰”?他何時才能干自己的事情?

　　TeX 系統的配置就更為麻煩。成千上萬個小文件，很少有人理解 kpathsea 的結構和用法，折騰好久才會明白。但是其實它只是解決一個非常微不足道的問題。TeX 的語言也有很大問題，使得擴展起來非常困難。這個以后再講。

　　一個良好的界面不應該是這樣的。它給予用戶的界面，應該只有一些簡單的設定。用戶應該用同樣的方法來設置所有程序的所有參數，因為它們只不過是一個從變量到值的映射(map)。至于系統要在什么地方存儲這些設定，如何找到它們，具體的格式，用戶根本不應該知道。這跟高級語言的運行時系統(runtime system)的內存管理是一個道理。程序請求建立一個對象，系統收到指令后分配一塊內存，進行初始化，然后把對象的引用(reference)返回給程序。程序并不知道對象存在于內存的哪個位置，而且不應該知道。程序不應該使用對象的地址來進行運算。

原文轉自：http://www.kuqin.com/shuoit/20131106/336092.html