移動 Web 的用戶界面設計

http://www.ibm.com/developerworks/cn/mobile/wa-interface/index.html

 

簡介

 

在創新者試圖探索新的可能性的同時，新興技術也在經歷快速變化的時期。各個替代解決方案開始爭奪注意力和市場佔有率。移動用戶界面（UI）技術目前處於這一革命性階段的中期。手機和平板電腦無論是使用 Apple 的 iOS （iPhone、iPod Touch 和 iPad）、Google 的 Android 架構、Blackberry 的操做系統、HP 的 webOS 仍是 Windows® Phone 7 移動操做系統，都提供各類不一樣的 UI 設計方法。

UI 多樣化是有意設計的。平臺必須有本身的獨到之處才能佔領市場。在 android 平臺上，運營商和設備供應商必須創造更多的多樣性使其產品區別與競爭對手。 雖然產品多樣性對競爭力的提升是頗有必要的，但這也給爲這些設備建立應用程序和網站的開發人員和設計人員帶來了挑戰。爲了建立能在多種設備類型上良好運行的應用程序，開發團隊須要：

• 精通各類開發技術
• 熟悉大量且頻繁變化的設備的功能
• 瞭解不一樣 UI 風格慣例和標準
• 擁有多種編程以及跨平臺移植經驗
• 豐富的多設備和多平臺測試經驗

移動 Web 技術提供一種更具成本效益的方法來開發用於各類設備平臺的應用程序。移動 UI 開發人員可以使用最新開發的 JavaScript 庫，例如 Dojo Mobile、jQuery Mobile 和 Sencha Touch，實現 「一次編寫，隨處運行」。開發人員無需學習各個平臺的不一樣框架，或者從新開發應用程序，或者將應用程序移植到各個支持平臺。用戶也會受益於 Web 應用程序的零安裝性質，他們能夠一直使用最新的應用程序版本，無需在線應用程序商店安裝升級。應用程序部署人員也會從中獲益，再也不擔憂須要爲在同一應用程序不一樣版本上運行的用戶提供支持。

然而，設計高質量的移動 Web 應用程序自己有一系列困難。首先從本質上來講，移動用戶界面是一個全新的用戶交互模型，擁有：

• 更小形狀
• 觸摸界面
• 加速傳感器
• 導向意識
• 無處不在的動畫
• 物理行爲模擬

其次，因爲 Web UI 要在全部設備上運行，不考慮其大小、規格以及功能，與設計傳統桌面 Web 應用程序相比，設計人員必須考慮更多的變數。

本文將會探討設計 移動 Web UI 的考慮因素和最佳實踐。雖然較少涉及實現細節，但本文偶爾會說起 HTML5 和 Dojo Toolkit 移動 UI 組件。出於必要性，這裏將對本機移動應用程序設計進行一些討論，可是重點仍是跨平臺設計。根據相對市場佔有率，本文重點放在 ios、Android 和 Blackberry 用戶指望上。

 

回頁首

顯示尺寸

小巧使得設備可在任意地方使用，可是也與不少可用性 方面背道而馳。小型的屏幕限制了那些以易於閱讀方式顯示的信息。在設計時，文本和圖像能夠快速消耗掉有限的屏幕空間，致使內容和用戶交互之間的失衡。

智能手機比較小，平板電腦屬於上網本到筆記本的範疇。許多供應商都同時提供這兩種類型的設備，各類顯示尺寸都有，如圖 1 所示。移動 Web 應用程序設計必須可以處理各類屏幕大小的顯示，在低端設備上不會出現擠壓，在高端設備不會出現拉伸。

圖 1. 移動設備顯示屏相對尺寸

 

回頁首

輸入

許多流行的移動設備使用觸摸和手勢輸入。雖然觸摸輸入更爲直觀，可是相對準確性較差。與傳統安裝應用程序或者 Web 應用程序的鼠標、指針輸入相比，觸摸的目標（如按鈕）必須比較大，且間隔比較寬。

在手機上，因爲受到屏幕尺寸的限制，加上交互目標較大，致使在各個面板上只有較少的控制。相對於鼠標指針圖標，手指和手可能會掩蓋一大半 UI 屏幕。

由於 Web 應用程序與生俱來就有跨平臺功能，因此必須考慮到不一樣設備的輸入特性。某些移動設備有物理鍵盤，而某些只有虛擬鍵盤，有的二者兼有。一些 Blackberry 設備使用觸摸板來完成指向、選擇和拖拽。Blackberry 和 Android 設備都有一些用於執行各類導航活動的專用物理按鈕，只是排列順序不一樣。

 

回頁首

操做系統的多樣性

因操做系統不一樣而致使的最重要的三個 UI 設計區別是：導航設計、控制實現和視覺風格。

導航

iOS 使用手勢和小部件，使用戶在各視圖之間移動。邊框的主屏幕按鈕也用於關閉應用程序和退出文件夾。Android 使用手勢、小部件和硬件按鈕（主屏鍵、返回鍵、菜單鍵和搜索鍵），而 Blackberry 使用手勢、小部件和硬件按鈕（菜單鍵和退出鍵）。輸入方法因設備型號和服務供應商的不一樣而不一樣，這就使狀況變得更加複雜。這一問題在 Android 設備上更爲嚴重，由於對於各個服務供應商和設備製造商，虛擬鍵盤的佈局和邊框按鈕從左到右的順序都各不相同。

控制實現

iOS 嚴重依賴軟件的 UI 控制功能，例如，虛擬按鈕。用戶經過觸摸與小部件交互，只有一個例外是退出應用程序或者文件夾。相較之下，Android 和 Blackberry 設備均提供物理按鈕，用於導航回前一視圖以及打開選項菜單。在 iOS 設備上，這些活動由按鈕執行。

一般，iOS 應用程序將返回和上下文菜單活動分配給選項卡行按鈕。按照慣例，在 iPhone 和 iPod Touch 上，選項卡按鈕被置於視圖的底部，這樣用戶就能夠輕鬆地用拇指觸摸。因爲不一樣的緣由，Android 設計風格習慣上將選項卡按鈕放在靠近屏幕頂部的位置；若是放置在屏幕底部，會形成無心的物理按鈕按壓。

視覺風格

每一個平臺都會經過色彩主題、圖標風格、標誌、小部件繪製來定義本身的視覺風格。使用平臺視覺主題不只僅是爲了美觀。平臺主題創建了用戶指望，即應用程序中的用戶交互要符合平臺慣例。

 

回頁首

性能

雖然 javascript 的性能在不斷改進，但移動設備仍然面臨性能挑戰。與筆記本和臺式計算機系統相比，它們使用的處理器沒有那麼強大，卻要和較低的網絡帶寬抗爭。

 

回頁首

多設備使用

通常來講，大部分智能手機用戶只用一個手機。另外一方面，許多人在多種設備上使用同一應用程序。一個用戶可能在 iPod Touch、Blackberry 手機、Android 平板電腦以及運行 Microsoft Windows 的筆記本上訪問同一應用程序。 就用戶而言，設備類型本質上就是同一內容空間的不一樣查看器。

多平臺、多設備設計因爲設備類型之間的差別而變得複雜。智能手機擅長在任意時間地點進行簡短交互，完成集中目標。我的計算機擅長在相對固定的場所進行繁複的交互，處理複雜的信息，在各個任務間切換。平板電腦交互介於智能手機和筆記本之間。

多設備設計須要深思熟慮，在下面這些競爭性需求方面作出不可避免的妥協：

• 充分利用每種設備的功能
• 有效地解決各類設備的侷限
• 在全部設備上提供類似的用戶體驗

爲了提供良好的用戶體驗，智能手機上的 Web 應用程序每每須要支持與臺式計算機至關的各類功能。在手機上顯示時，您可能須要刪除部分在臺式計算機上可行的功能，或者添加一些在移動環境下可用的功能。很難判定複雜 Web 應用程序中的哪些功能在移動設備上顯示不是很重要。

這沒有訣竅可言。您必須在可能用到某個應用程序的設備環境下，仔細地瞭解和驗證各個功能的使用狀況，而後將功能與設備匹配。表 1 概述了移動和臺式設備用戶體驗的不一樣。

表 1. 移動和臺式用戶體驗區別

移動設備	臺式設備
簡潔集中的交互。 發微博或短消息。	單一任務的持續交互。 撰寫備忘。
設備上有更多幹擾中斷。 在智能手機上查收郵件時接到電話。	較少的干擾中斷。 在筆記本上查收郵件時使用手機接聽電話。
頻繁改變環境。 空中旅行時（上飛機、下飛機等）使用手機。	不多改變環境。 在臺式計算機上使用電子數據表應用程序。
趨向於事務性交互。 查看天氣預報。	支持非事務性交互。 撰寫報告。
瀏覽多於交互。 翻閱照片。	瀏覽和交互對半。 編輯假日照片集。
頁面加載更具破壞性。 移動 Web 瀏覽體驗。	頁面加載破壞性較小。 桌面 Web 瀏覽體驗。
體驗簡單 閱讀電子書。	更能承受複雜性。 使用文字處理程序。
相對較差的響應時間。 地圖升級。	良好的響應時間。 高度身臨其境的遊戲。
更強的社交性。 電話、短信、全球社交、共享應用程序的相對重要性。	較弱的社交性。 辦公效率應用的相對重要性。

首先，爲多設備使用場景進行設計時，用戶數據在用戶訪問應用程序的全部設備上共享是很重要的。在提供相同內容的定製「視圖」時，須要考慮到應用程序的設備類型實例。

 

回頁首

移動 Web UI 最佳實踐

目前爲止，咱們已討論了移動 Web 的使用挑戰，包括多平臺應用程序的幾個考慮。本文其他內容將探討設計移動 Web UI 的最佳實踐。

 

回頁首

使用一個工具包

從嚴謹的面向開發的角度來講，庫、工具和框架能夠減小工做量。使用標準 UI 組件庫能夠節省大量的開發和測試時間，這些時間能夠用於低級的設計、編碼、處理瀏覽器差別、測試、調試和維護。經過確保經常使用控件外觀和行爲與預期同樣，高質量的 UI 組件庫還能夠改善使用的便利性。

Dojo Toolkit 1.5 版本介紹了基本的移動 UI 功能。1.6 版和 1.7 測試版包括本機應用程序上的表明性 UI 控制功能和交互。面向 Web 2.0 和移動設備的 WebSphere® Application Server Feature Pack 包含了 Dojo Toolkit 1.7，以及若干有用的應用程序服務和圖示可視化功能。

 

回頁首

響應設計

移動 Web 應用程序主要的設計挑戰是：如何爲一個顯示在不一樣屏幕上（從幾英寸的方塊，大到平板電腦、筆記本，甚至使用更大顯示器的設備）的應用程序建立積極的用戶體驗？響應 Web 就是設計原則，以及一系列試圖解決這一問題的技術。

響應 Web 設計的目標是使每一個網站或者 Web 應用程序看起來好像是爲其所在的設備和瀏覽器專門設計的。或許，「響應 Web」更應該被稱爲 「更具響應性的 web」，由於 Web 每每須要解決非最大化瀏覽器以及各類尺寸和分辨率的顯示器上的內容顯示問題。移動設備尺寸更小，更具多樣性，於是這個問題更爲突出。

響應 Web 實現依賴於使用 CSS、媒體查詢以及 JavaScript 來根據設備調整內容顯示。媒體查詢 是CSS3 的子規範，使您可以將不一樣風格的頁面與不一樣媒體或者顯示特徵結合起來。例如，根據設備屏幕的高度、寬度、寬高比以及分辨率來選擇一個風格頁面。

本文不詳細討論如何實現響應設計。在 響應 Web 設計：它是什麼以及如何使用 和 關於響應設計的 List Apart 中會對若干技術進行描述。本文其他部分將提供幾個經常使用設計方法的概述。

響應佈局

複雜佈局每每在較大的顯示器上運行良好，但在智能手機上沒法使用。相反，閱讀和導航極爲簡單的內容佈局看起來很無趣，當基板面充足時甚至是極度無聊的。許多手持設備能夠不斷變化方向。設計良好的響應內容自動調整其佈局來適應設備的尺寸和方向。

當設備屏幕和分辨率過小而難以支持多列時，一個方法就是將多列布局從新格式化爲單一列布局。如圖 2 和圖 3 所示。

iPad 應用程序有時會利用常見的「左邊導航欄 - 右邊內容欄」模式，以下所示。這在較大的屏幕上顯示良好，可是不適用於較小的，手機大小的設備。

圖 2. iPad 上固定的分屏

在這種狀況下，移動 Web 應用程序能夠設計爲左邊的導航列表單獨顯示在一個視圖，而內容顯示在第二個視圖（圖 3）。您可使用 Dojo 工具移動小部件 FixedSplitter 和 FixedSplitterPane 來實現這一方法。

圖 3. iPhone 上固定的分屏

選項卡行是響應設計的另外一個關注點。如上所述，iOS 設備將選項卡行置於視圖底部，而 Android 設備將其放在視圖頂部。Safari 移動 Web 瀏覽器遵循 iOS 慣例，將瀏覽器導航控件放置在視圖底部的選項卡行，如圖 4 所示。Web 應用程序遵循選項卡在底部的慣例也會產生問題，由於瀏覽器和應用程序選項卡行會重疊。解決方案很簡單。在移動 Web 應用程序的 HTML 頭文件中放置 meta 標籤 <meta name="apple-mobile-web-app-capable" content="yes" />，這樣，當用戶將一個應用程序連接添加到主屏幕時，就會抑制瀏覽器工件，如圖 4 的 b 部分所示。

圖 4. 選項卡行在 iOS 和 Android 中的位置

爲了不相似問題，而且遵循合適的 Android 應用程序準則，Web 應用程序應該使用媒體查詢，將選項卡行放置在 Android 設備頂部視圖下方（圖 4，b 和 d）。

響應小部件

由於設備所用的物理控件不一樣，軟件按鈕在 Android 和 Blackberry 設備上會與物理按鈕重複，因此在這些設備上查看 Web 應用程序時，應將其隱藏。

小部件的尺寸是另外一個要考慮的因素。由於顯示因分辨率（每英寸的像素）不一樣而不一樣，因此移動 UI 設計準則每每以物理大小單位進行表示。建議最小觸摸目標尺寸在 7 毫米到 10 毫米的正方形之間（這些尺寸就是從 iPad 2 的 36 - 52 像素正方形，到 iPhone 的 Retina 顯示的 90 - 128 像素正方形）。目標之間的最小空間應爲 1 – 2 毫米。

響應內容

有時，只是從新組織頁面上的內容不足以應對顯示尺寸的變化範圍。您不該該期待將每一個應用程序硬塞進 2×3 英寸大小的長方形中，它們還能保持可用性。使用模式在小型和大型設備上每每是不一樣的。小型設備最適用於簡短的、專一的交互；大型設備適用於較長的、更爲繁複的交互。例如，您手機上的天氣預報應用程序可能只包含敏感地理位置的當前和將來的狀況。同一應用程序的桌面 Web 版本可能提供更多內容，當前和其餘地區的天氣歷史，天氣事件的文章或者視頻，等等。

經過有選擇地只顯示最重要的內容，或者使用連接將次要場景移動到另外一頁面，文本內容能夠按比例縮小。

圖像能夠在大型和小型設備上響應式地縮放。有許多方法能夠實現這一目標。最簡單的方法就是容許圖像自行縮放，但這樣可能會影響性能。當大型圖像縮小時，用戶會很難看清重要的細節。一個替代方法就是在移動設備上提供極小的圖像，經過觸摸進行放大，在臺式計算機瀏覽器上全尺寸顯示。在其餘狀況下，建立多個圖像也是可行的，這樣能夠只顯示重要功能，而且有選擇地顯示接近目標設備分辨率的圖像。

視覺的一致性

各個主要的設備平臺都有本身的視覺信號，它們是由顏色面板、圖標風格，以及印刷格式定義的。爲某一設備設計的應用程序在其餘供應商的設備上看起來格格不入。從視覺風格和交互上對應用程序進行調整，使其適應顯示設備，這樣會很大程度上知足用戶在其設備上有一致性體驗的指望。

dojox.mobile.deviceTheme（Dojo 1.7 測試版）模塊支持的平臺主題如圖 5 所示。您可使用這一模塊自動檢測設備類型，併爲目標設備設置合適的主題。

圖 5. Android、Blackberry 和 iOS 的 Dojox 移動主題

交互的一致性

響應設計涉及的不只僅是處理顯示差異。設計還必須根據目標設備是否使用物理按鈕（例如，返回鍵、主屏鍵以及選項鍵）來對應功能，考慮如何隱藏和顯示虛擬按鈕使其更易於響應。設備瀏覽器會處理其餘設備間的交互差別。

 

回頁首

重複利用設計實現最佳用戶體驗

採用 UI 設計模式更便於使用，緣由有兩個。

• 從定義上，模式是經常使用設計問題通過證實的解決方案。部分模式是經過正式使用測試獲得驗證的，而其它則是經過設計的 「天然選擇」 獲得驗證的。假以時日，不可用的設計將會被拋棄，而良好的設計則被效仿。
• 由於模式是經常使用的設計實踐，因此它們爲用戶所熟悉。基於模式的 UI 每每無需用戶學習。

在網絡上有一些移動 UI 模式的網站；pttrns 和 Mary Sheibley 的 Mobile-Patterns 是最全面的。這兩個網站都提供了經常使用設計風格的實例。雖然這些模式庫沒有提供設計準則，但它們能夠做爲設計靈感，幫助您設計利用其餘應用程序用戶體驗的 UI。

 

回頁首

讓用戶選擇

除了可移動性以外，移動設備和傳統的計算機設備還有兩個差異，即點擊的準確度和打字的便利性。對於這兩種狀況，傳統的計算機界面都優於移動設備界面。觸摸輸入界面觸覺反饋較差，精確度也較低。不管使用小型的物理鍵盤仍是虛擬鍵盤，與全尺寸計算機鍵盤的性能相比，移動設備上的打字速度和精確度都比較差。當設備使用虛擬鍵盤時，打字將是一種破壞性操做 — 鍵盤的出現使大部分視圖變得模糊。

建議：

• 若是可能，讓用戶進行選項選擇，而不是要求他們輸入文本。
• 爲用戶提供足夠大的觸摸交互目標（例如，10 毫米的正方形）。
• 當須要選項過大或者鍵盤輸入不可避免，提供自動完成或者選擇清單過濾，儘可能減小打字輸入。
• 運用 HTML5 豐富的輸入類型功能，爲輸入（文本、數字、電話、日期、時間，或者 URL）提供優化的虛擬鍵盤，避免用戶手動切換鍵盤來獲取不經常使用的字。

 

回頁首

與主頁保持緊密聯繫

小巧的顯示和粗大的手指就意味着導航元素和內容必須爭奪移動設備屏幕上的空間。所以，內容和導航每每必須顯示在不一樣視圖。深次層的導航就顯得很單調，並且浪費用戶內存。

與移動設備設計的許多方面相似，導航應該儘量簡潔。若是可能，導航應保持二或三層，並保證有一個方便的方法返回到應用程序的「主」視圖。在 iOS 設備上，這極可能意味着在部分視圖上須要提供虛擬主屏按鈕和返回按鈕。經過 Android 設備訪問時，這些按鈕沒必要顯示，由於 Android 提供了物理的返回按鈕和主屏按鈕。

 

回頁首

向用戶說明如何使用

移動設備解決小型屏幕尺寸的一個方法就是支持手勢交互。例如，無需拖動滾動條控件功能，用戶能夠用手指在頁面上滑動，實現縱向或者橫向滾動。滾動條控件能夠減少到最小尺寸，或者作成臨時可視的位置指示器，由於可視控件圖形（例如上/下按鈕和滾動條「拇指」功能）已經再也不須要了。在同一視圖中能夠有不一樣操做的多個手勢可用，而不須要有任何可視的控件功能佔據空間（例如，用手指收縮來開/關縮放，向右/左滑動來翻頁，向上/下滑動來滾動，以及用點按來關閉）。

手勢節省屏幕空間的同時，也是須要代價的。僅僅提供手勢控件，那麼用戶可能不知道什麼活動是可用的。補救方法就是經過視覺線索提供暗示，稱之爲情景支持，來引導用戶如何與視圖交互。這些可視情景支持的確耗費了一些空間，可是它們的使用頻率遠低於做爲觸摸目標的控件。

可視情景支持的一個簡單的例子就是在清單項中的 「>」，它表示視圖跟隨點觸變化。其餘許多情景支持都是基於物理對象的實際環境的。例如，Apple 的 iBook 使用一個物理的書籍象徵來表示翻頁手勢。Spinner 小部件用本身的圖形提供可視的情景支持。在這種狀況下，拇指和滾軸控件的視覺隱喻代表上和下來拖拽以改變數值。

 

回頁首

多用圖形

移動 UI 一般多采用圖形。圖形設計引人注目的應用程序每每比純文本的應用程序更受青睞。這不只僅是由於美感，並且設計精良，圖形豐富的 UI 每每還提供許多實踐獲益。良好圖形設計能輕鬆地和用戶交流，並引發用戶的興趣。正如以前所述，豐富的可視控件情景支持能夠更高效地「告訴」用戶如何與設備交互。比起數據的文字或者表格描述，這些信息更容易獲取據統計，統計可視化每每可以提供更多更容易獲取的信息。

如圖 6 所示，Dojo 工具 1.7 版本提供許多豐富的圖形和可視化小部件，它們已經被優化用於移動 Web 應用程序。

圖 6. Dojo 圖形和可視化小部件

 

回頁首

避免移動 Web UI 設計陷阱

在設計您的移動 Web UI 時，請避免如下常見的陷阱。

不加改動

移動 Web 瀏覽器會顯示許多未經修改的 Web 應用程序。不管哪一個嘗試過在智能手機上使用未修改的 Web 應用程序的人，都知道這隻能讓人很是失望或者惱火。複雜的 Web 應用程序不適用於手機，由於手機屏幕小、觸摸交互不許確，且網絡帶寬不夠。

忽略性能

較差的性能幾乎不被用戶所允許，特別是有替代應用程序時。

保持本機移動應用程序儘量簡單對 Web 應用程序來講特別有用。較大圖像、頁面加載以及其餘服務器獲取都會影響性能，並會讓用戶注意到響應間隔。

依賴於幫助

如以前所述，在目標清晰的簡短交互中傾向於使用移動應用程序。這類使用意味着用戶不肯學習如何與設備交互。

應用程序的使用應該很是直觀不須要幫助。這對全部 UI 來講都是必須的，可是與幫助內容的交互在用戶看來就是他們與目標之間的額外任務。當移動 Web 應用程序足夠直觀時，就再也不須要幫助 UI 和幫助內容了，這樣就減小了下載到設備的代碼和內容。

誤用創造性

在移動應用程序設計上，引入新的交互技術、獨特的圖標，以及可視的處理時須要特別注意。用戶會理解那些在外觀和行爲上與他們使用過的其餘應用程序相似的應用程序。非必需的創新交互和樣式會增長用戶須要幫助的可能性。

忽略瀏覽器的交互

從定義上來看，移動 Web 應用程序在移動 Web 瀏覽器上運行。與桌面 Web 同樣，瀏覽器會在 Web 應用程序中顯示額外用戶界面層。和桌面 Web 程序相似，當用戶對應用程序內以及瀏覽器中的導航控件同時具備訪問權限時，就會出現導航問題。若是可能，在 koisk 模式下運行您的應用程序，並在應用程序內提供全部須要的導航。

 

回頁首

結束語

經過開發和部署移動 Web 技術，有關爲多設備平臺開發本機應用程序的許多問題都是能夠避免的。然而，解決移動設備和移動 Web 應用程序所特有的設計問題可以保證使用的方便性。

設計移動 Web 應用程序時，若是考慮到平板電腦，必須對小設備規格和各類設備尺寸給予更多關注。因爲移動平臺設備的供應商和運營商所形成的 UI 差別，設計必須適應各個平臺的特性。Dojo 1.7 中可用的標準化控件和本機設備主題，使得移動 Web 應用程序的設計和開發更爲簡單。