網頁應用程式 Usability 筆記
原則一：思考服務的對象
首先要先了解你的用戶是哪一種類型：若按用戶功力可分為 end user 和 power user。若按網頁使用頻率來分，可分為例行性作業和一次性作業。用例子說明好了，比方說大家熟悉的購物網站，包含產品瀏覽、購物車、下單等等功能。首先，這類網站的使用者功力大多屬於 end user，因此介面上越簡單越好 (即使你有很好的創意，也要小心發揮，因為 end user 可能會看不懂你新穎的介面)。若從使用頻率來看，產品瀏覽屬於例行性作業，下單則屬於一次性作業 (因為久久才下單一次)。因此產品瀏覽的網頁不能拖泥帶水，步驟要越少越好，不然用戶逛了老半天找不到想買的東西就跑掉了。另一方面，下單的網頁到是不怕步驟多，就怕使用者不會用，或是抗拒使用 (要付錢的地方總是會小心翼翼的)。所以一般下單都會設計成 wizard 的方式，一步一步導引使用者完成下單。
那如果是購物網站的後台呢？後台的使用者屬於 power user (可能一開始就是，或是之後會被訓練)。他每天的工作就是產品上架，處理訂單...等等例行性的作業。這樣的網頁以快速為最優先考量：可以運用 減少 popup、不用 wizard、多功能客製化元件、一頁內放多一點資訊、增設 hotkey... 等等技巧。總之讓用戶可以在最少的點擊、最少的思考完成他的工作就是了。
購物網站是大家熟悉的例子，大家都見多了。但是如果換個 domain 就要多花心思去了解了。比方說我的工作是服務醫院醫學相關的研究，涉及到的人員有護士、醫生、研究員、實驗室、計畫負責人...等等。服務內容則有病人收樣管理、實驗管理、秏材進銷存、問卷調查...等等。遇到這類不熟悉的 domain 時，記得談需求時要多尋問：分辨他在這個功能上屬於 end user 還是 power user？他多久用一次這個功能？每天用還是一個月用一次？先替這些用戶簡單歸個類，大方向捉對了，未來做出的網站用戶用的就順手。
原則二：第一頁要放用戶最想做，最常做的事
這個原則乍聽之下很自然、也很直覺... 但我們 team 的大多數成員 (包含我自己) 就是沒有辦法做到這一點。我們的專案多屬內部使用，而開發部門並沒有設立專人設計網頁，所以從網頁設計到後端資料全都工程師自己來。工程師拿到案子，頭腦就開始直覺思考後端流程怎麼設計，然後由後端往前端推，網頁的流程就會和後端呈現一比一的關係。比方說要做一個管理稽核案的功能，有新增修改查詢等等功能。依典型的工程師思維，第一頁就做了個查詢案子的表單和新增案子的連結，下了查詢條件後再列出相關案子的網頁。這種 "第一頁" 也不能說工程師沒按需求來做... 只是剛進去時除了表單，就是一片空白，什麼都沒有。使用者一進來就得去想、得去回憶要下什麼查詢條件，才能找到他要的東西。這樣還真有點難用...
要提升 usability，就是去思考用戶最想做或是最常做的事，比方說，第一頁除了查詢表單之外，還列出他最近處理過的10個案子；或者，用戶比較關心那些稽核不過的案子，那一開始就先列出這些有問題的案子；或者，可以提供查詢條件 history 的功能，讓用戶可以調出最近下的查詢條件... 等等。決定要做那方面的事，要透過談需求時了解。而且，要注意很少有使用者會自覺得想到這一塊，必需由開發者主動尋問和了解使用者的作業才行。
原則三：重要的內容放在 1024x768 內
這個原則很基本，許多人都了解 (還不知道的人要打屁屁！)。問題是出在難遵守.... 開發人員通常都用很大的營幕、開高解析度、然後字型用的小小的，希望一次看多點資訊，方便開發。這樣的習慣長期下來，一不小心就會發生設計的網頁常常需要 scroll (甚至是左右 scroll)。除非你的網頁是設計給 power user，而且是配備比較好的營幕。不然開發時建議固定開個 1024x748 的 browser 來檢視網頁的呈現，比較符合一般使用者的畫面大小。(安裝 firefox 的 web developer plugin，然後大小設 1024x748 (不是 768，因為要扣掉 toobar和 menu 的高度)) 瀏覽器的大小有了，接下來就是將重要的內容、用戶最關心的事情，盡量放在網頁上半段，一般來說，左上角是人瀏覽的起點，從那裡開始最好。目的就是讓用戶最少的力氣找到他要的東西，而不是 scroll 老半天才看的到。
原則四：改變資料狀態用按鈕，瀏覽資料用連結
當你做的功能是 改變資料狀態時，網頁上要用按鈕來呈現。如果是資料間瀏覽，則用連結來呈現。什麼是改變資料狀態？比方說刪除資料、送出表單、移動位置、切換...等等功能。這些功能用按鈕比較洽當，因為按鈕有 "動作" 的感覺 (按下後再彈上)、有視覺上的 feedback。當然在 ajax 的風潮之下，按鈕漸漸越用越少了，不少地方開始用連結來替代。不過重點還是一樣，要有視覺上的 feedback，例如加些 animation, yellow fade out之類的都可以。
另一方面，瀏覽資料則一定是用連結，千萬不要用按鈕替代。這聽起來很白吃吧？但就是有新手會犯這種錯 (三年前我自個兒也常犯...)
原則五：慎防預覽頁面
當設計多步驟網頁時，例如結帳的功能，中間多半會夾一個預覽的頁面。預覽的網頁原本是好意，讓使用者可以再完成前，再確認、考慮一番。但偏偏很多用戶會把他當做 "已完成" 的網頁，造成常會有客戶來電，抱怨明明已經完成了，卻沒成交。為避免這類常犯的錯誤，建議預覽的畫面正上方要加上大剌剌的 "完成按鈕" (可用顏色/大小/字型來醒目) 提醒使用者，要按了才會生效。如果版面許可，可以再加上 process train (另一說法是 process funnel) 就是常見的按順序導引：(1) -> (2) -> (3) -> done，這樣就更穩了。現在 Ajax 技術發達，也可以考慮用 "即時預覽" 取代掉舊的換頁預覽，這樣既方便又不會出錯。
最後，我們來看一個客製元件提升 usability 的實際例子
需求：用戶需替病人的樣本做稽核 (有無漏收或誤收)，一個稽核案約含 100 個病人。每個病人的稽核狀態分別為 未稽核、已稽核、稽核不過。
用戶 profile：用戶為稽核員，是內部的使用者，可以被訓練。因此屬 power user
使用頻率：約每週使用，一次約稽核數十人，屬例行性作業。
按上面的需求，如果用傳統的 html 元件設計，我們會得到：
上圖用表格的方式呈現 100 個病人資料。而最右邊稽核的狀態則採下拉式選單表示 (當然這裡也能用 Radio Button，但是三個選項會太寬，版面擠不下)。在下拉式選單中挑選欲變更的狀態時，背後會用 ajax 的方式直接更新後端的資料。一般來說寫到這樣已經算很方便了，最少用戶不用為了切換狀態而 submit 一個個的 html form。
雖然不錯，但是還有兩個缺點：第一，每次切換下拉式選單都需要兩次的 click。第二，當 100 個 病人直直排下來，狀態用文字表示時，要分辨出 未稽核、已稽核 等狀態其實還蠻花的。
由於稽核員屬 power user，因此我們不一定要使用簡單的 html 基本元件，我們可以客製元件：
上圖稽核的狀態改用兩個圖示表示，兩個都是灰的表示尚未稽核，綠色表示已稽核，紅色則表示稽核不過。這樣一來，即使 table 上排滿滿了 100 個病人，也可以很快看出哪些病人還沒稽核，哪些是稽核有問題的。要切換狀態，只要在欲切換的圖示上點擊一次就行了 (有點類似常見的評比星星)，而背後也是直接用 ajax 更新後端的資料。
當然，這樣的元件用戶第一次看到會傻眼... 無從下手，不過只要稍微 demo 一下，之後作業就很順暢囉。
至於要製作這樣的客製元件... 呃... 要看各位用什麼技術寫了... 用 Wicket 的話，一個幾十行的 .java 就搞定了，也不用寫什麼 javascript 或是 xml。其他的技術就得慢慢磨了吧... 採用容易寫客製元件的 framework 真的好處很多，寫元件不僅快又簡單，也讓你有更多的時間和精力花在構思更好的 usability 上。
來源
http://www.javaworld.com.tw/roller/ingramchen/entry/2007_11_18_WebAppUsabilityNotes
