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