Designing for Error (2)

Feb. 27 21:32~22:58

昨天談到 The Psychology of Everyday Things （p. 131）提到的四點 Designing for Error 作法：

• Understand the causes of error and design to minimize those causes.

了解錯誤發生的根本原因，在設計時盡可能避免這些錯誤發生。換句話說，這是 error prevention。一個最簡單的例子，如下圖所示，用行事曆的 UI 讓使用者選擇一個日期，這樣可以避免使用者打出 2011/02/29 這種不存在的日期。這個方法方法聽起來好像很簡單，如果有點年紀的鄉民們回想一下，在 Web 才剛剛流行的那個年代，透過網頁輸入『日期』的資料，大多還是只提供一個 text box 讓使用者自行輸入類似『2011/02/29』的期，或是三 text box 讓使用者自行輸入年，月，日。這種作法持續了一段時間，後來才有用 javascript 做的行事曆元件可用。所以，雖然『Understand the causes of error and design to minimize those causes』可以算是常識，但是在設計使用者介面時常常因為種種原因很容易被忽略。

• Make it possible to reverse actions- to "undo" then - or make it harder to do what cannot be reversed. 

既然犯錯是難免的，如果有『月光寶盒』或是『時光機』可以回到過去『修正』自己所犯的錯誤，修正之後錯誤就不存在啦。換句話說，這是 error recovery。最常見的例子就是文書編輯軟體都有提供的無限次數 undo 功能，因為有了這個功能，使用者可以『無罣礙的（放心的）』編輯文件，反正萬一改錯了，只要 undo 就可以回到上一個狀態了。如果人生也能有 control+z 該多好。

如果有些操作和人生一樣是無法 undo 那該怎麼辦？例如，鄉民們使用網路 ATM『轉帳』，網路 ATM 軟體人總不可能提供 undo 功能，讓鄉民們們在『不小時把錢轉給詐騙集團時』可按下 undo 按鈕吧。雖然這個功能聽起來很不錯，不過『轉帳』是不可逆也不可以 undo 的，而且不小心轉錯會『很傷』，因此，當使用者執行這類的功能時，軟體都會『再三提醒』，這也是這個作法第二部份所說的 make it harder to do what cannot be reversed。

• Make it easier to discover the errors that do occur, and make them easier to correct.

如果錯誤無法從根本上（在設計的時候）避免，那麼至少要能夠想方法讓『偵測錯誤』與『修復錯誤』變的簡單一點。舉個車子的例子，車子製造商無法用設計的方法『避免』使用者『忘記加油 （對車子而言這沒油了是一種錯誤）』，所以，他們設計了『油量指示表』，而且主動在『油量只剩下 10% 的時候亮紅燈或是發出 BBB 警告聲』（ discover the errors），如果車子有 GPS 此時能夠自動結合 GPS 告訴車主最近的加油站在哪裡那就更棒了（make them easier to correct）。

再舉個軟體的例子，假設鄉民們正使用 Eclipse 用 Java 在寫程式。大家都知道，『寫程式是一件超級容易犯錯的工作』，Eclipse 的設計者如何幫助使用者（就是你）來 discover the errors 而且 make them easier to correct？人家想出了 quick fix 這個超讚的功能。以下圖的程式範例為例，Eclipse 偵測到一個語法錯誤（main method 遇到一個 checked exception 但是沒有 catch 或是 declare 這個 checked exception），在錯誤發生的那一行的左邊顯示了一個小X icon 稱之為 marker（以上是 easier to discover）。接下來是 easier to correct 的作法，當使用者按下這個小X icon 之後，Eclipse 顯示建議修改方案（resolution），使用者點選合適的修改方案 Eclipse 便自動幫忙修復這個錯誤。

當年 Teddy 曾經研究過 Eclipse 的 quick fix 機制，大體上就是：

• 利用 visitor 去拜訪 Eclipse JDT （Java Development Tools）所建立的 AST (Abstract Syntax Tree)。Error detection 的邏輯就是寫在 visitor 裡面，plug-in 的開發者可以自行擴充新的 visitor 以便加入自己的錯誤檢查邏輯。
• 當發現錯誤時，產生一個 麵包屑 marker 用以標示錯誤發生的『位置』（程式行號）。
• 針對不同種類的 marker，plug-in 開發者提供自定的 resolution（解決方案）以協助使用者排除錯誤。由於 marker 是 plug-in 開發者依據『自訂檢查錯誤邏輯』所產生的一個『錯誤標記』，因此如果此錯誤『存在可能的解決方案』的話，plug-in 開發者自然可以事先提供 resolution 來協助使用者排除問題。當然，有時後這些 resolution 並不一定合用，需要使用者自己動手修改。

說真的，對於使用者而言，如果一個軟體系統有提供這種 quick fix 的貼心功能，真的是很方便。不過，要設計出這樣的功能是需要多耗費一點精神滴，對於各位加班加到暴肝的鄉民們而言，沒事應該不太想嘗試吧（Teddy 內心獨白：要向上提昇啊...）。

 

• Change the attitude toward errors. Think of an object's user as attempting to do a task, getting there by imperfect approximations. Don't think of the users as making errors; think of the actions as approximations of what is desired.

最後這一點用書上的一段話來解釋並做本篇結尾 (p. 131)：

When someone makes an error, there usually is good reason for it. If it was a mistake, the information available was probably incomplete or misleading. The decision was probably sensible at the time. If it was a slip, it was probably due to poor design or distraction. Errors are usually understandable and logical, once you think through their causes. Don't punish the person for making errors. Don't take offense. But most of all, don't ignore it. Try to design the system to allow for errors. Realize that normal behavior isn't always accurate. Design so that errors are easy to discover and corrections are possible.


以上四點以及上面這一段文字念個幾十次對於 designing for error 就會慢慢有 fu 了...

***

友藏內心獨白：好久沒翻這本書了，都快忘了這本書寫得有多好。