WEB交互界面設(shè)計和驗收的指導(dǎo)性原則

1、WEB交互界面設(shè)計和驗收的指導(dǎo)性原則隨著企業(yè)intranet和國際internet的迅速發(fā)展，越來越多的工作流程，商務(wù)交易，教育、 培訓(xùn)、會議和講座，以及個人消費娛樂都被轉(zhuǎn)移到所謂的萬維網(wǎng)World Wide Web以下簡 稱WEB)上來了。與此相對應(yīng)的是交互操作的復(fù)雜性越來越高。隨著Browser/Server模式的日漸流行，很多操作都是在瀏覽器環(huán)境下的網(wǎng)頁上完成的， 并不是只有失效的鏈接和意外的出錯才會使操作者感到煩惱，即便是一次完整的成功操作過 程，也可能因為操作的繁復(fù)性過高或者使用上的不方便而給操作者帶來不愉快的體驗。本文試圖闡述WEB交互頁面設(shè)計的一些指導(dǎo)性原則，這些原則有利于避免發(fā)

2、生不愉快 的操作體驗。這些原則是用戶友好性的，是在完成同一種操作要求下，使用戶最感到輕松、 簡單、舒適的WEB交互界面設(shè)計原則。我們假定我們討論的WEB頁面都是功能正常的， 符合美學(xué)觀點的。需要說明我們討論的原則可能會和設(shè)計上的美學(xué)觀點以及既有的功能設(shè)計 有所沖突。如果發(fā)生這種情況，基于“實用的就是美的”觀點，我們會建議您酌情放棄原先 的美學(xué)觀點與功能設(shè)計。輸入控件的自動聚焦和可用鍵盤切換輸入焦點使用JavaScript實現(xiàn)頁面加載完成后立即自動聚焦(focus)到第一個輸入控件。可用TAB 鍵(IE缺省實現(xiàn))或方向鍵切換聚焦到下一個輸入控件。輸入控件指WEB頁面表單()中顯式的，需要用戶進行

3、修改、編輯操作的表單元 素。對于這些控件，如果沒有自動聚焦操作，不可避免的出現(xiàn)一次用戶鼠標定位操作(如果 用戶此前處于鍵盤輸入操作狀態(tài)或鼠標定位后需要進行鍵盤輸入操作，實際上是鍵盤鼠標切 換操作)。如果鼠標定位后需要進行鍵盤輸入操作，如果不能鍵盤切換輸入焦點，那么不可 避免的在切換輸入焦點時需要反復(fù)的鍵盤鼠標切換操作，這是很繁瑣的。如果實現(xiàn)了頁面加載完成即自動聚焦到第一個輸入控件，并且可以鍵盤切換輸入焦點標 定位操作，那么對于用戶來說整個頁面的輸入操作可能都不需要鼠標操作，或次數(shù)較少，這 是一種便利。畢竟頻繁的鍵盤鼠標切換操作是比較累人的。對于有輸入欄的對話框或網(wǎng)頁，在不干預(yù)的情況下就應(yīng)將當前

4、控制焦點定位在待輸入的 輸入欄上；如果輸入欄在一般情況下不需要更改其中的內(nèi)容，則應(yīng)直接將焦點定在“確定” 按鈕上；在幾個輸入欄之間應(yīng)支持tab，shift+tab切換操作，“確定”和“取消”應(yīng)該是切換 操作的終點，與具體所在位置無關(guān)?？捎肊nter (或Ctrl+Enter)鍵提交，確保和點擊提交按鈕的效果是相同的不要在提交按鈕上加入onClick=”.”這樣的JavaScript代碼。用Enter鍵提交頁面是原則1的自然延伸，而且這也是瀏覽器所缺省支持的。只所以單 獨列出來是因為實際上有些設(shè)計者設(shè)計的頁面不能達到這種效果，結(jié)果導(dǎo)致使用Enter鍵提 交和點擊“確定”按鈕提交帶來的效果不一樣。

5、大部分情況下是設(shè)計者在“確定”按鈕上加 入了 onClik=”.”這樣的代碼，通過點擊“確定”按鈕后，會執(zhí)行一段JavaScript代碼，比 如對某些hidden類型的input元素設(shè)值。而使用Enter鍵提交時就不會執(zhí)行這段代碼。正確的做法是把這段代碼移到表單標中，以onSubmit=”.”屬性引入。對于表單元素，它會消耗Enter鍵，因此會使得Enter鍵提交失效?？梢砸?JavaScript代碼捕捉Ctrl+Enter復(fù)合鍵，一旦捕捉到即執(zhí)行表單的submit()方法。對于需要頻 繁提交的場合，比如BBS上，這種代碼是很有必要的。鼠標動作提示和回應(yīng)對用戶的鼠標定位操作，當移動到可響應(yīng)的

6、位置上時，應(yīng)給予視覺或聽覺的提示。動作回應(yīng)的最簡單形式就是鼠標ICON變成手狀。瀏覽器只對具有href屬性的HTML 標簽會自動進行這種變換ICON的行為。對于沒有href屬性(或沒有設(shè)置href屬性)的標 簽，可以通過JavaScript設(shè)置style屬性的cursor為hand。目標區(qū)域發(fā)生變化是更為主動的響應(yīng)形式。當鼠標指針移到目標區(qū)域，此時指針圖形改 變或文字顏色發(fā)生改變均能較大的減輕用戶搜索定位目標區(qū)域的注意力負擔。在按鈕上增添 直觀的圖形，盡可能的增大按鈕面積；按鈕間保持適當?shù)木嚯x，太近增加了用戶區(qū)別它們之 間界限以防誤操作的負擔，太遠增加了用戶搜索定位按鈕的負擔。盡可能早的在客戶

7、端完成輸入數(shù)據(jù)合法性驗證輸入數(shù)據(jù)的合法性檢驗應(yīng)該在客戶端使用JavaScript進行驗證。除非驗證只能在服務(wù)器 端完成，否則驗證工作應(yīng)在最早能完成的情況下進行。在客戶端完成數(shù)據(jù)合法性驗證，可以避免一次服務(wù)器請求和回復(fù)通訊，這種通訊是需要 用戶等待的，如果用戶等待很長時間后從服務(wù)器返回的結(jié)果提示出現(xiàn)的錯誤是在輸入時即可 發(fā)現(xiàn)的，那么這種設(shè)計就是不友好的。諸如密碼長度限制，用戶名允許字符限制等等，顯然 應(yīng)該在客戶端提交前就應(yīng)該進行驗證。根據(jù)應(yīng)用場景決定在表單頁面和提交后返回頁面間是否使用中間過渡頁面根據(jù)應(yīng)用場景，決定是否顯示接收表單頁面(表單頁面和提交后返回頁面間的中間過渡 頁面)，以及使用何種方

8、式顯示接收表單頁面。表單頁面和接收表單頁面是大部分WEB交互操作賴以實現(xiàn)的配合模式。關(guān)于表單頁面 和接收表單頁面的相互關(guān)系的設(shè)計，要做如下幾個方面的考慮。一，對于需要頻繁操作的場合，從操作便利和快捷性出發(fā)，盡可能的減少服務(wù)器和客戶 端交互次數(shù)，應(yīng)該避免使用中間過渡頁面。提交完畢直接返回原來的表單頁面或默認頁面。 在這種情況下要考慮到數(shù)據(jù)安全和可恢復(fù)性。如果因為用戶輸入的數(shù)據(jù)不合格，需要重新輸入，那么，去除中間頁面，把錯誤信息直 接顯示在原表單頁面上的設(shè)計方式，將是最簡潔的處理方式。用戶只需要根據(jù)錯誤提示進行 更正即可。當然這樣做稍微增加了編程負擔。在表單接收頁面上需要包含原表單頁面的內(nèi)容， 而

9、且輸入數(shù)據(jù)項都必須用服務(wù)器端代碼或客戶端JavaScript設(shè)置成用戶輸入的值。為了開發(fā) 快捷，可以這樣做：表單頁面和接收表單頁面用同一個服務(wù)器端腳本頁面實現(xiàn)。這個頁面按 如下流程完成原來兩個頁面的工作：頁面腳本初始化I檢查“提交”變量是否設(shè)置卜已設(shè)置，做數(shù)據(jù)驗證I卜驗證通過一 業(yè)務(wù)邏輯處理一 使用包含頁面方式或重定向方式返回到特定頁面I驗證不通過一 保存用戶輸入的數(shù)據(jù)一退出表單提交處理到表單頁面流程中未設(shè)置，做表單頁面流程，如有來自提交流程中產(chǎn)生的用戶輸入數(shù)據(jù)，則顯示出來其中，使用包含頁面方式返回到特定頁面可以避免一次客戶端重定向過程，比客戶端重 定向過程還要快捷和穩(wěn)定一些。但是有些情況下因

10、為代碼變量沖突或其他原因，使用包含頁 面方式可能并不方便，這時候可以使用服務(wù)器端重定向技術(shù)，在ASP里是Server.Transfer 方法，在 Java Servlet 里是 RequestDispatcher.forward()方法。不要使用 Response.Redirect 或者 HttpServletResponse.sendRedirect()這種客戶端 HTTP 重定向方 法。不使用中間過渡頁面也就意味著用戶不能后退瀏覽原先已經(jīng)填好的表單頁面，因為使用 的是同一個URL。所以在驗證不通過情況下保存用戶輸入的數(shù)據(jù)就是必不可少的。不使用中間過渡頁面帶來的另一個問題就是使用包含頁面方式

11、或服務(wù)器端重定向方式 返回會使得URL和頁面內(nèi)容不能一一對應(yīng)。對于用戶可能會直接用這個URL（會收藏這個URL） 訪問返回頁面的情況，他會發(fā)現(xiàn)實際上到達的是表單頁面，不是他想要的那個返回結(jié)果頁面。 所以，去除中間過渡頁面，確實會帶來URL和內(nèi)容含混不清的情況，因而不適合需要URL 和頁面內(nèi)容一一對應(yīng)的場合。二，從技術(shù)角度考慮，使用中間過渡頁面能保證URL和頁面內(nèi)容一一對應(yīng)，簡化頁面開 發(fā)工作。為了保證頁面內(nèi)容總是和固定的URL聯(lián)系起來，必須使用客戶端重定向： 提交業(yè)務(wù)邏輯處理（中間過渡頁面）表單頁面 接收表單頁面 顯示處理結(jié)果 客戶端重定向到特定頁面客戶端重定向分幾種情況：1，使用 HTTP

12、Header重定向， Location:,這種定向是最快的，在窗口一片空白的情況下就迅速訪問 （GET）另一個頁面。這種方式實際上不能顯示處理結(jié)果，只能說是向第一種快速重定向方 式的一種折衷處理；2,HTML 標簽刷新，META HTTP-EQUIV=Refresh CONTENT=5;URL=，這種定向比較友好，在這個頁面加載完畢 后訪問另一個頁面。很多設(shè)計者把這個作為一個技巧使用，在載入一個大頁面前放置一個緩 沖頁面以避免用戶乏味的等待；3, JavaScript重定向。由于是用代碼控制重定向，可以做的 更靈活。比如根據(jù)用戶習(xí)慣，控制操作完畢后的轉(zhuǎn)向流程。4,被動式的重定向。在頁面上 放置

13、按鈕或鏈接，由用戶手動決定返回到特定頁面。這種情況適合于處理結(jié)果的顯示頁面包 含相當多的信息，需要用戶仔細瀏覽，而決定下一步的操作。在使用中間過渡頁面的情況下，不能再使用頁面過期失效了。否則一旦出現(xiàn)錯誤，需要 用戶重新輸入表單數(shù)據(jù)，用戶就不能用后退按鈕恢復(fù)此前填寫的表單數(shù)據(jù)了。除非設(shè)計者有 意禁止這種恢復(fù)。防止表單重復(fù)提交處理對提交按鈕點擊后做變灰處理避免在網(wǎng)絡(luò)響應(yīng)較慢情況下用戶重復(fù)提交同一個表單。使 用頁面過期失效避免用戶后退瀏覽重復(fù)提交表單。有些復(fù)雜的應(yīng)用會導(dǎo)致需要較長時間的等待才會返回處理結(jié)果。而在較慢的網(wǎng)絡(luò)環(huán)境 中，這種情況更是頻繁發(fā)生。焦急等待的用戶往往會重復(fù)點擊提交按鈕。這種情況是

14、設(shè)計者 所不希望看到的。使用JavaScript在點擊提交按鈕后使按鈕失效變灰是一個最直接的辦法（根據(jù)原則2這 段代碼應(yīng)該放在form標簽里onSubmit=” 做）。此外，在表單頁面上，用服務(wù)器端腳本 設(shè)置HTTP Header的Expires為立即過期可以保證用戶沒辦法使用后退瀏覽恢復(fù)表單頁面。 注意這樣做的代價可能是用戶辛辛苦苦填寫很長的內(nèi)容，結(jié)果一旦操作失誤就沒法恢復(fù)。所 以應(yīng)該避免在包含textarea表單元素的頁面上使用頁面過期失效。應(yīng)該說，更嚴格的方法是，服務(wù)器端腳本就應(yīng)該具備抵抗重復(fù)提交的能力。例如，為這 個表單分配一個唯一 ID或一個使用一次即失效的驗證碼。此外，這個表單處理

15、還應(yīng)具有事 務(wù)性質(zhì)，如果表單不被接受，所做的改變還是能恢復(fù)的。在金融應(yīng)用場合，重復(fù)提交同一筆 交易是肯定不被允許的。能在重復(fù)提交中獲利的一方總是會想辦法繞過瀏覽器的限制，所以 不能依賴于客戶端的技術(shù)。頁面鏈接是打開新窗口、使用原窗口還是彈出窗口的原則一般而言，首頁上鏈接可以使用target=”_blank”屬性打開新窗口，而其他頁面上的鏈接 都應(yīng)使用原窗口或彈出窗口。如果鏈接頁面內(nèi)容相對原頁面來說不重要，是附屬性質(zhì)的，可 以使用彈出窗口方式。一般情況下應(yīng)該使用原窗口，把是否保留原窗口內(nèi)容的權(quán)利留給用戶。除非設(shè)計者相信 原頁面是如此重要，在用戶發(fā)出點擊指令后還有使用上的價值，以至于不能被隨便更新

16、或覆 蓋。一般來說，只有首頁才會處于這樣一個地位，用戶在首頁上打開一個鏈接后，一般還會 在這個首頁上去打開另一個鏈接。比如首頁包含極多鏈接的門戶網(wǎng)站，或者搜索引擎的搜索 結(jié)果頁面。G以前的搜索結(jié)果頁面上的鏈接是使用原窗口的，后來他們意識到用 戶會反復(fù)使用這個頁面，而改成打開新窗口了。一般的網(wǎng)站如果首頁鏈接不多，就不必使用 新窗口，這是用戶友好的設(shè)計原則。上述情形的一個極端情況就是新頁面內(nèi)容比起原頁面內(nèi)容的重要性差很多，以至于都未 必需要打開一個新頁面。這時候使用彈出窗口比較合適。用JavaScript彈出窗口有好幾種： 一個是window.open()函數(shù)。這里有個技巧。應(yīng)該使用window.

17、open()先打開一個空白窗口， 再使用location.replace()用目標頁面替換。這樣做可以避免在打開新頁面的過程中導(dǎo)致原頁 面失去響應(yīng)。Window.open()將打開一個新的瀏覽器窗口進程，因此資源消耗比較大。另一 個是由微軟DynamicHTML規(guī)范中擴充的方法createPopup()。createPopup()可以創(chuàng)建無邊框 的彈出窗口，消耗系統(tǒng)資源較小。還有一個就是用頁面中隱藏的層div來模擬一個彈出頁 面。后兩種可以使用JavaScript代碼填充彈出窗口內(nèi)容。如果需要下載網(wǎng)頁作為其內(nèi)容的話， 需要微軟DynamicHTML規(guī)范中的download標簽。盡可能少的排列可

18、選項，盡可能少的安排操作步驟根據(jù)用戶操作習(xí)慣安排盡可能少的操作菜單選項，同時要保證盡可能少的操作步驟。在不降低功能多樣性的前提下減少菜單項和操作步驟是用戶友好的設(shè)計。要做到這一點 很不容易。要從用戶出發(fā)考慮他們最頻繁的操作是什么。正常情況下一個用戶需要的操作總 可以歸類為5個以下的種類，如果出現(xiàn)更多的種類，那一定是沒有針對用戶興趣去區(qū)分主次。 一個用戶同時有5個以上的強烈興趣中心是難以想像的，走馬觀花似的隨意點擊瀏覽的用 戶，是不大可能在某個種類上進行深入的交互操作的。在這5個種類中，每個種類都可能有 若干個可操作的二級種類。如果這些二級操作項是不可見的，那么意味著要做兩次選擇才能 進入可操作頁面。這就違背了 “盡可能少的安排操作步驟”這一原則。如果使用JavaScript 制作二級菜單，避免請求服務(wù)器，會好一些。如果二級菜單項總共不超過20個左右，不妨 將二級菜單直接顯示出來，比如放在左列一字向下排開，這樣只需要一次選擇到可