WEB交互界面易用性設計和驗收的指導性原則
2011-08-26 文章來源: 深達設計
Tags:
WEB,交互,界面,易用性,設計,指導性,原則
隨著企業intranet和國際internet的迅速發展，越來越多的工作流程，商務交易，教育、培訓、會議和講座，以及個人消費娛樂都被轉移到所謂的萬維網（World Wide Web，以下簡稱WEB）上來了。與此相對應的是交互操作的復雜性越來越高。
隨著Browser/Server模式的日漸流行，很多操作都是在瀏覽器環境下的網頁上完成的，并不是只有失效的鏈接和意外的出錯才會使操作者感到煩惱，即便是一次完整的成功操作過程，也可能因為操作的繁復性過高或者使用上的不方便而給操作者帶來不愉快的體驗。
本文試圖闡述WEB交互頁面設計的一些指導性原則，這些原則有利于避免發生不愉快的操作體驗。這些原則是用戶友好性的，是在完成同一種操作要求下，使用戶最感到輕松、簡單、舒適的WEB交互界面設計原則。我們假定我們討論的WEB頁面都是功能正常的，符合美學觀點的。需要說明我們討論的原則可能會和設計上的美學觀點以及既有的功能設計有所沖突。如果發生這種情況，基于“實用的就是美的”觀點，我們會建議您酌情放棄原先的美學觀點與功能設計。
1．輸入控件的自動聚焦和可用鍵盤切換輸入焦點
使用JavaScript實現頁面加載完成后立即自動聚焦(focus)到第一個輸入控件。可用TAB鍵（IE缺省實現）或方向鍵切換聚焦到下一個輸入控件。
輸入控件指WEB頁面表單(<form>)中顯式的，需要用戶進行修改、編輯操作的表單元素。對于這些控件，如果沒有自動聚焦操作，不可避免的出現一次用戶鼠標定位操作（如果用戶此前處于鍵盤輸入操作狀態或鼠標定位后需要進行鍵盤輸入操作，實際上是鍵盤鼠標切換操作）。如果鼠標定位后需要進行鍵盤輸入操作，如果不能鍵盤切換輸入焦點，那么不可避免的在切換輸入焦點時需要反復的鍵盤鼠標切換操作，這是很繁瑣的。
如果實現了頁面加載完成即自動聚焦到第一個輸入控件，并且可以鍵盤切換輸入焦點標定位操作，那么對于用戶來說整個頁面的輸入操作可能都不需要鼠標操作，或次數較少，這是一種便利。畢竟頻繁的鍵盤鼠標切換操作是比較累人的。
對于有輸入欄的對話框或網頁，在不干預的情況下就應將當前控制焦點定位在待輸入的輸入欄上；如果輸入欄在一般情況下不需要更改其中的內容，則應直接將焦點定在“確定”按鈕上；在幾個輸入欄之間應支持tab，shift+tab切換操作，“確定”和“取消”應該是切換操作的終點，與具體所在位置無關。
2．可用Enter（或Ctrl＋Enter）鍵提交，確保和點擊提交按鈕的效果是相同的
不要在提交按鈕上加入onClick=”…”這樣的JavaScript代碼。
用Enter鍵提交頁面是原則1的自然延伸，而且這也是瀏覽器所缺省支持的。只所以單獨列出來是因為實際上有些設計者設計的頁面不能達到這種效果，結果導致使用Enter鍵提交和點擊“確定”按鈕提交帶來的效果不一樣。大部分情況下是設計者在“確定”按鈕上加入了onClik=”…”這樣的代碼，通過點擊“確定”按鈕后，會執行一段JavaScript代碼，比如對某些hidden類型的input元素設值。而使用Enter鍵提交時就不會執行這段代碼。
正確的做法是把這段代碼移到表單標簽<form>中，以onSubmit=”…”屬性引入。
對于<textarea>表單元素，它會消耗Enter鍵，因此會使得Enter鍵提交失效。可以引入JavaScript代碼捕捉Ctrl+Enter復合鍵，一旦捕捉到即執行表單的submit()方法。對于需要頻繁提交的場合，比如BBS上，這種代碼是很有必要的。
3．鼠標動作提示和回應
對用戶的鼠標定位操作，當移動到可響應的位置上時，應給予視覺或聽覺的提示。
動作回應的最簡單形式就是鼠標ICON變成手狀。瀏覽器只對具有href屬性的HTML標簽會自動進行這種變換ICON的行為。對于沒有href屬性（或沒有設置href屬性）的標簽，可以通過JavaScript設置style屬性的cursor為hand。
目標區域發生變化是更為主動的響應形式。當鼠標指針移到目標區域，此時指針圖形改變或文字顏色發生改變均能較大的減輕用戶搜索定位目標區域的注意力負擔。在按鈕上增添直觀的圖形，盡可能的增大按鈕面積；按鈕間保持適當的距離，太近增加了用戶區別它們之間界限以防誤操作的負擔，太遠增加了用戶搜索定位按鈕的負擔。
4．盡可能早的在客戶端完成輸入數據合法性驗證
輸入數據的合法性檢驗應該在客戶端使用JavaScript進行驗證。除非驗證只能在服務器端完成，否則驗證工作應在最早能完成的情況下進行。
在客戶端完成數據合法性驗證，可以避免一次服務器請求和回復通訊，這種通訊是需要用戶等待的，如果用戶等待很長時間后從服務器返回的結果提示出現的錯誤是在輸入時即可發現的，那么這種設計就是不友好的。諸如密碼長度限制，用戶名允許字符限制等等，顯然應該在客戶端提交前就應該進行驗證。
5．根據應用場景決定在表單頁面和提交后返回頁面間是否使用中間過渡頁面
根據應用場景，決定是否顯示接收表單頁面（表單頁面和提交后返回頁面間的中間過渡頁面），以及使用何種方式顯示接收表單頁面。
表單頁面和接收表單頁面是大部分WEB交互操作賴以實現的配合模式。關于表單頁面和接收表單頁面的相互關系的設計，要做如下幾個方面的考慮。
一，對于需要頻繁操作的場合，從操作便利和快捷性出發，盡可能的減少服務器和客戶端交互次數，應該避免使用中間過渡頁面。提交完畢直接返回原來的表單頁面或默認頁面。在這種情況下要考慮到數據安全和可恢復性。
如果因為用戶輸入的數據不合格，需要重新輸入，那么，去除中間頁面，把錯誤信息直接顯示在原表單頁面上的設計方式，將是最簡潔的處理方式。用戶只需要根據錯誤提示進行更正即可。當然這樣做稍微增加了編程負擔。在表單接收頁面上需要包含原表單頁面的內容，而且輸入數據項都必須用服務器端代碼或客戶端JavaScript設置成用戶輸入的值。為了開發快捷，可以這樣做：表單頁面和接收表單頁面用同一個服務器端腳本頁面實現。這個頁面按如下流程完成原來兩個頁面的工作：
頁面腳本初始化
┃檢查“提交”變量是否設置┠已設置，做數據驗證┃驗證通過－>業務邏輯處理－>使用包含頁面方式或重定向方式返回到特定頁面┃驗證不通過－>保存用戶輸入的數據－>退出表單提交處理到表單頁面流程中┗未設置，做表單頁面流程，如有來自提交流程中產生的用戶輸入數據，則顯示出來
其中，使用包含頁面方式返回到特定頁面可以避免一次客戶端重定向過程，比客戶端重定向過程還要快捷和穩定一些。但是有些情況下因為代碼變量沖突或其他原因，使用包含頁面方式可能并不方便，這時候可以使用服務器端重定向技術，在ASP里是Server.Transfer方法，在Java Servlet里是RequestDispatcher.forward()方法。不要使用Response.Redirect或者HttpServletResponse.sendRedirect()這種客戶端HTTP重定向方法。不使用中間過渡頁面也就意味著用戶不能后退瀏覽原先已經填好的表單頁面，因為使用的是同一個URL。所以在驗證不通過情況下保存用戶輸入的數據就是必不可少的。
不使用中間過渡頁面帶來的另一個問題就是使用包含頁面方式或服務器端重定向方式返回會使得URL和頁面內容不能一一對應。對于用戶可能會直接用這個URL（會收藏這個URL）訪問返回頁面的情況，他會發現實際上到達的是表單頁面，不是他想要的那個返回結果頁面。所以，去除中間過渡頁面，確實會帶來URL和內容含混不清的情況，因而不適合需要URL和頁面內容一一對應的場合。
二，從技術角度考慮，使用中間過渡頁面能保證URL和頁面內容一一對應，簡化頁面開發工作。
為了保證頁面內容總是和固定的URL聯系起來，必須使用客戶端重定向：
提交 業務邏輯處理 （中間過渡頁面）
表單頁面―>接收表單頁面―>顯示處理結果―>客戶端重定向到特定頁面
客戶端重定向分幾種情況：1，使用HTTP Header重定向，Location:http://www.netall.com.cn，這種定向是最快的，在窗口一片空白的情況下就迅速訪問（GET）另一個頁面。這種方式實際上不能顯示處理結果，只能說是向第一種快速重定向方式的一種折衷處理；2,HTML標簽刷新，<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://www.netall.com.cn">，這種定向比較友好，在這個頁面加載完畢后訪問另一個頁面。很多設計者把這個作為一個技巧使用，在載入一個大頁面前放置一個緩沖頁面以避免用戶乏味的等待；3，JavaScript重定向。由于是用代碼控制重定向，可以做的更靈活。比如根據用戶習慣，控制操作完畢后的轉向流程。4，被動式的重定向。在頁面上放置按鈕或鏈接，由用戶手動決定返回到特定頁面。這種情況適合于處理結果的顯示頁面包含相當多的信息，需要用戶仔細瀏覽，而決定下一步的操作。
在使用中間過渡頁面的情況下，不能再使用頁面過期失效了。否則一旦出現錯誤，需要用戶重新輸入表單數據，用戶就不能用后退按鈕恢復此前填寫的表單數據了。除非設計者有意禁止這種恢復。
6．防止表單重復提交處理
對提交按鈕點擊后做變灰處理避免在網絡響應較慢情況下用戶重復提交同一個表單。使用頁面過期失效避免用戶后退瀏覽重復提交表單。
有些復雜的應用會導致需要較長時間的等待才會返回處理結果。而在較慢的網絡環境中，這種情況更是頻繁發生。焦急等待的用戶往往會重復點擊提交按鈕。這種情況是設計者所不希望看到的。
使用JavaScript在點擊提交按鈕后使按鈕失效變灰是一個最直接的辦法（根據原則2這段代碼應該放在<form>標簽里onSubmit=”…”做）。此外，在表單頁面上，用服務器端腳本設置HTTP Header的Expires為立即過期可以保證用戶沒辦法使用后退瀏覽恢復表單頁面。注意這樣做的代價可能是用戶辛辛苦苦填寫很長的內容，結果一旦操作失誤就沒法恢復。所以應該避免在包含<textarea>表單元素的頁面上使用頁面過期失效。
應該說，更嚴格的方法是，服務器端腳本就應該具備抵抗重復提交的能力。例如，為這個表單分配一個唯一ID或一個使用一次即失效的驗證碼。此外，這個表單處理還應具有事務性質，如果表單不被接受，所做的改變還是能恢復的。在金融應用場合，重復提交同一筆交易是肯定不被允許的。能在重復提交中獲利的一方總是會想辦法繞過瀏覽器的限制，所以不能依賴于客戶端的技術。
7．頁面鏈接是打開新窗口、使用原窗口還是彈出窗口的原則
一般而言，首頁上鏈接可以使用target=”_blank”屬性打開新窗口，而其他頁面上的鏈接都應使用原窗口或彈出窗口。如果鏈接頁面內容相對原頁面來說不重要，是附屬性質的，可以使用彈出窗口方式。
一般情況下應該使用原窗口，把是否保留原窗口內容的權利留給用戶。除非設計者相信原頁面是如此重要，在用戶發出點擊指令后還有使用上的價值，以至于不能被隨便更新或覆蓋。一般來說，只有首頁才會處于這樣一個地位，用戶在首頁上打開一個鏈接后，一般還會在這個首頁上去打開另一個鏈接。比如首頁包含極多鏈接的門戶網站，或者搜索引擎的搜索結果頁面。Google.com以前的搜索結果頁面上的鏈接是使用原窗口的，后來他們意識到用戶會反復使用這個頁面，而改成打開新窗口了。一般的網站如果首頁鏈接不多，就不必使用新窗口，這是用戶友好的設計原則。
上述情形的一個極端情況就是新頁面內容比起原頁面內容的重要性差很多，以至于都未必需要打開一個新頁面。這時候使用彈出窗口比較合適。用JavaScript彈出窗口有好幾種：一個是window.open()函數。這里有個技巧。應該使用window.open()先打開一個空白窗口，再使用location.replace()用目標頁面替換。這樣做可以避免在打開新頁面的過程中導致原頁面失去響應。Window.open()將打開一個新的瀏覽器窗口進程，因此資源消耗比較大。另一個是由微軟DynamicHTML規范中擴充的方法createPopup()。createPopup()可以創建無邊框的彈出窗口，消耗系統資源較小。還有一個就是用頁面中隱藏的層<div>來模擬一個彈出頁面。后兩種可以使用JavaScript代碼填充彈出窗口內容。如果需要下載網頁作為其內容的話，需要微軟DynamicHTML規范中的<download>標簽。
8．盡可能少的排列可選項，盡可能少的安排操作步驟
根據用戶操作習慣安排盡可能少的操作菜單選項，同時要保證盡可能少的操作步驟。
在不降低功能多樣性的前提下減少菜單項和操作步驟是用戶友好的設計。要做到這一點很不容易。要從用戶出發考慮他們最頻繁的操作是什么。正常情況下一個用戶需要的操作總可以歸類為5個以下的種類，如果出現更多的種類，那一定是沒有針對用戶興趣去區分主次。一個用戶同時有5個以上的強烈興趣中心是難以想像的，走馬觀花似的隨意點擊瀏覽的用戶，是不大可能在某個種類上進行深入的交互操作的。在這5個種類中，每個種類都可能有若干個可操作的二級種類。如果這些二級操作項是不可見的，那么意味著要做兩次選擇才能進入可操作頁面。這就違背了“盡可能少的安排操作步驟”這一原則。如果使用JavaScript制作二級菜單，避免請求服務器，會好一些。如果二級菜單項總共不超過20個左右，不妨將二級菜單直接顯示出來，比如放在左列一字向下排開，這樣只需要一次選擇到可操作項，更加明了方便。
9．操作邏輯無漏洞，保證數據是操作安全的
多個頁面間的操作和同個頁面上的多個操作間的邏輯關系在設計上是安全和嚴謹的。保證不會出現不被允許的用戶操作組合，至少不會因為用戶的不適當的操作導致出錯。
這最典型的表現則是在頁面上廣泛采用的所謂聯動下拉框設計。一個下拉框中允許的選項受另一個下拉框中的選擇而變。另外一個例子是根據選擇使表單元素有效或者失效。如果在多個頁面間也要維持某種合法性邏輯，那么就需要服務器端腳本的參與。這樣會使表單設計跟操作有關，應該說這不是一個好的設計。可以通過變更操作步驟順序、組合方式來盡可能避免這種情況出現。
操作邏輯的設計既要保證用戶任意的輸入不會導致錯誤，也要保證是用戶輸入的數據能購被安全處理。在Session控制下的表單中輸入大幅文字可能會導致超時出錯，這時候往往還伴隨重定向過程，導致用戶的長篇輸入蕩然無存。用JavaScript提醒用戶已超時，請保存輸入后重新提交，是一個好辦法。某些表單元素如<input type=”text”>接受ESC鍵清除數據，并且無法撤銷，這也是很危險的。在中文輸入法中常常使用ESC鍵清楚輸入的碼位，一旦不小心多按一下ESC就會使得輸入數據消失。因此有必要用JavaScript禁用<input>和<textarea>的ESC鍵處理過程。
