Designing for Error (5)：execution and evaluation

March 03 21:39~10:52

終於到了 Designing for Error 這個系列最後一篇（希望是），不知道有沒有鄉民已經等在 電視機 電腦前面等著收看這一集的實況轉播，每天寫也是會累滴。

Teddy 記得在『美味關係』這部電影裡面，女主角之一的『茱莉鮑爾』立志用一年的時間，每天都要按照『掌握法國烹飪藝術』這本食譜上的菜單親自做菜，並把做菜的心得發表在自己的部落格上。等 Teddy 自己開始認真寫『搞笑談軟工』之後才發現，這怎麼可能，每天要『擠料』出來可是很傷腦細胞的一件事。就算是腦細胞撐的下去，每天打那麼多字，手腕，手肘和肩膀也會受不了（路人甲：Teddy 你好弱喔...）。

言歸正傳，今天要談的是 The Psychology of Everyday Things （p. 140）對於 Designing for Error 的總結，一共有三個重點，今天談第三個重點： 

Narrow the gulfs of execution and evaluation. Make things visible, both for execution and evaluation. On the execution side, make the options readily available. On the evaluation side, make the results of each action apparent. Make it possible to determine the system state readily, easily, and accurately, and in a form consistent with the person's goals, intentions, and expectations.

這一點應該是很容易理解的（雖然並不見得容易做到），舉的例子先。假設你想要趕流行學人家『霸凌同 學 事』（PS：叔叔有練過，小朋友不可以學喔），於是有一天上班你帶了一根棍子到公司，遠遠看到被霸凌對象迎面而來，此時你高高舉起手上的棍子往對方頭上猛 K 下去。以上動作叫做 execution，你事先擬定了一個霸凌同事的『目標 （goal）』，為了達到此目標，你選擇了用『棍子猛 K 對方』的個作法（method），當看到對方之後，你採行一連串的行動（operators）以便達到此目標。啊，一不小心又 GOMS 上身了...

K 完一棒之後就沒事了嗎？當然不是，因為在採取行動（execution）之後你還必須要評估一下行動是否成功（evaluation）。按照常理推斷，對方被你 K 了一棒之後，應該要一邊用手摸著被 K 的地方，同時發出一聲慘叫外加大聲重複背誦三字經。如果這些事件都發生了，你就可以確定此次的霸凌成功，否則就是失敗。

***

On the execution side, make the options readily available. On the evaluation side, make the results of each action apparent 是避免使用者操作錯誤相當有用的方法。翻成白話文就是，在設計介面時，對於使用者可以操作的功能有哪些選項要清楚的表達出來。例如，如果一個檯燈用的是『省電燈泡』，只有『開』和『關』的功能（不能調亮度），那麼這個檯燈的開關就應該設計成只能『開』和『關』。


採用 on/off 開關

execution side（開關） ：           evaluation side（電燈）:
on                                                            亮
off                                                            暗
 
如果開關設計成可以調整亮度（鎢絲燈泡）的那種旋鈕開關，那麼就會很奇怪了。為什麼奇怪？因為：

採用旋鈕開關開關


execution side（開關） ：           evaluation side（電燈）:
往右轉到最底                                            亮
往左轉到最底                                            暗
非上述兩個狀態                                         沒反應

就沒有達到 make the results of each action apparent 這一點要求，也就是說使用者明啊明就有做了某些動作，但是卻沒有觀察到任何反應。以剛剛霸凌的例子來講，原本 K 了一棒就要快閃，受害者痛一下也就沒事了，但是萬一好死不死這個受害者硬撐不喊出聲音來，你可能以為沒 K 到或是 K 的太輕，於是卯起來連續 K 了 100 下，一直到受害者真的不可能再有任何反應為止....這是很恐怖滴...所以....伊...想哭不要硬撐。

 

***

Execution and evaluation 的例子很多，平常經常看到的 progress bar 就是讓使用者知道他剛剛執行的動作（execution）的狀態（evaluation）。或是當使用者按下『確定交易』的按鈕之後，系統回覆『交易成功』也算。想一想，如果一個系統只有 execution（提供使用者操作否個功能的介面）而沒有 evaluation，這樣的系統是很難被正確使用的。

Teddy 最近就遇到一個慘痛的經驗，Teddy 公司和家裡的電腦都安裝 Ubuntu 作業系統，因為工作的需要經常會用到 Skype 來 聊天 談公事和傳輸檔案。還好 Skype 有提供 Ubuntu 版本，雖然有一些小問題，不過大致還堪用。

有用過 Skepe 的人都知道當你傳輸檔案給對方的時候，Skype 會跳出一個『檔案傳輸對話盒』（如下圖所示），讓你知道目前傳輸檔案的進度。不知道為什麼，在 Teddy 的電腦上有時候這個『檔案傳輸對話盒』就是不會出現。明明對方都已經接收到檔案了，Teddy 還以為檔案沒有傳出去（因為沒有得到任何 feedback 所以無法 evaluate 剛剛的檔案傳輸動作是否有正確執行）。有一次同事就問 Teddy，同一的檔案幹麼連續傳 10 幾次給他，此時 Teddy 才發現這個問題。

***

節目到這邊已經接近尾聲，鄉民們應該會發現其實這些 Designing for Error 的方法都很簡單，看起來也沒什麼學問。沒錯，這本書好就好在這裡...因為大部分都看的懂，所以看完之後有『自我感覺非常良好』。但是別忘了『知易行難』的道理，意思懂了不代表應用到實際設計上的時候都還記得這些道理。好里加在好心的 Teddy 把這些重點幫鄉民們記錄下來（鄉民甲：有重點嗎？！），上班上到腦袋空空的時候來逛一下，久而久之就不會忘記了。

***

友藏內心獨白：K 人的例子會不會太暴力一點...