Android 應用中十大常見 UX 錯誤

作為一個長期使用 Android 的使用者，我在使用 Android 應用的時候經常遇到各種各樣的互動上的問題，並且早就想整理它們寫一篇文章了。但是由於懶惰和拖延，這篇文章一直處於草稿的狀態。正巧，這期 ADiA 中，Android 開發團隊為我們著重強調了當下 Android 應用中很常見的，應該避免的錯誤。

Android 開發者關係團隊每天都會試用無數的 App 或者受到無數的開發者發來的，請求評測的 App。在評測如此之多的應用之後，他們總結出了一些最常見的錯誤，並且在這期節目中為大家呈現出來。

在正式介紹這些錯誤之前，我想稍微提一句。這些錯誤是非常具有普遍意義的錯誤，也就是說，你用十個應用可能就會碰見這十個錯誤，甚至你會在一個應用中碰見全部十個錯誤。這種情況在天朝顯得更加嚴峻。所以，希望這篇文章能讓大家擺脫摸著石頭過河的窘境，直接的避免一些常見的錯誤。

十大使用者體驗”反模式”，Android 開發者聯絡團隊為你用心呈現，每個典型錯誤都有個有趣的小標題，希望大家看 (乖) 得 (乖) 開 (中) 心 (槍)。

第十：你必須載入完這些東西……否則！

這裡的載入實際上指的是左圖中的那種，一個圈圈轉啊轉的對話方塊。這種對話方塊的出現是應該要避免的，另外，比起這麼一個對話方塊，那些不響應 Back 操作的對話方塊實在太不合理。

解決方案其實也很簡單，採用嵌入式的載入指示即可。當然如果你能做到實現在後臺載入好資料那就更棒了。

第九：你摸我不到！

首當其衝的問題是過小的觸控區域。Android Design 中專門強調過，所有可觸控的物件都應該有至少 32dp 高，理想的大小是 48dp，除非你的目標使用者是嬰兒等手特小的人。

另一個很糟糕的錯誤是沒有觸控反饋。有些開發者不想使用標準的按鈕控制元件，但是標準按鈕的好處就是它有提供觸控反饋的視覺效果。對於使用者而言，摸到沒有反饋的按鈕會讓他們認為你的應用（比它本身的速度）慢。對於使用者而言，感知速度是他們能體會到的，而真正的載入速度和執行速度反而沒有感知速度那麼容易被使用者體會到。另外，亮起的觸控反饋還能指示出實際的觸控區域。比如說一個列表，當使用者按下某一列表項的時候，這一項所處的一整行都會亮起，但是兩邊會留有 16dp 的空白，這樣便相當於告訴使用者，這個列表項最靠近螢幕邊緣的 16dp 不是觸控區域。

第八：設計 ≠ Photoshop

首先，同學們不要學習右邊小圖上的那個變態。我知道大家都對 PS 能實現的各種各樣的效果很在行/感興趣，但是不當的/過度的使用這些效果只會讓你的應用看起來顯得很過時或者更糟糕——很業餘。

當你設計你的應用的時候，請務必將注意力優先放在內容而不是那些高光上。使用者裝了你的應用並不是為了看閃閃發光的按鈕，所有的這些視覺設計到最後都應該是為了內容服務，而不是為了裝飾而裝飾。

另外，請務必保證應用內視覺風格的一致性。沒用使用者會希望看到一個一半 Holo 一半草泥馬的應用。點名批評一下 Feedly 這種外表光鮮亮麗, 設定卻像是侏羅紀時代的應用。另外，一個應用中不應該有太多的按鈕/選框/對話方塊樣式，一個就夠了——直接呼叫 Android 風格的控制元件是個簡單有效的辦法。

還有一些開發者，對於細節的忽視實在是到了令人髮指的地步，比如說不一致的度量，錯誤的間距，鬼畜的用色（如我之前的微信 Redesign☺），喪病的字型選擇……這些都是會令使用者感到不爽的細節，作為開發者沒有理由忽視他們。

第七：侏羅紀來客

如果你的應用是 2009 年的時候做的，那麼你的使用者可就要遭殃了……

這裡最先要提到的問題就是 Menu 鍵，或者說，選單按鈕的恥辱。我們現在已經有了 Action Bar 來取代侏羅紀時代的選單鍵了不是嗎？需要向下相容也不是個藉口，因為如果你設定了適當的引數，那麼 Overflow 按鈕就不會在有實體選單鍵的機器上出現。當然，你也可以讓有實體選單鍵的機器強行顯示 Action Overflow 來增加它的可見性。但是，無論怎麼樣，都不要讓選單鍵只能通過實體 Menu 鍵 (在只有虛擬鍵的機器上就會變成 Nav Bar 右側的三個小點) 撥出。

雖然說現在 Android 最新的 API 已經到了 Lv 18，但是你並不一定要設定 targetSdkVersion 大到 18，只要是 16 以上就行了。如果你把 API 設定到 Lv 14 甚至更低，你的應用就會強制在 Nav Bar 上顯示三個小點，這對於某些裝置比如 HTC One 的使用者而言實在是一件不能更痛苦的事情了。

還有一種情況就是繼續沿用 Android 2.3 甚至更古早的視覺風格。這種 App 有時候看起來還算挺 Holo 的，但是當你按下按鈕或者列表項的時候，Android 2.3 樣式的橙色的視覺反饋出現了（如 MIUI），或者捲動的時候看到了 2.3 樣式的滾動條，或者載入的時候看到 2.3 樣式的圈圈等等。這絕對不是使用者想要的。說道載入時的圈圈，Roman Nurik 稍微強調了一下，Holo 樣式的載入環其實是兩個圈以不同的速度反向同時旋轉，能夠製造出比起單圈更為順滑的動畫。

第六：純血的雜種 Android

這裡的原則性問題是：不要違背“純血 Android”的規約。

就和標題一樣，這一章的內容是在說，不要從別的平臺上搬運元素到 Android 上。這個問題我在往期的文章裡也提到過很多次，這裡就不展開說了。幾個特別要注意也是常見的錯誤：

• 右箭頭：次級導航在 Android 上是沒有水平方向的對映的。換句話說，次級導航和橫向導航是兩碼事
• 底部標籤欄：對於 Android 而言, 頂部才是屬於標籤欄的位置
• 從其他平臺”借鑑”視覺樣式：Android 使用者想要的是 Android 應用

第五：導航就是我的品牌

不要試著重新發明輪子。應用中導航在 Android 中已經有了成熟的定義，把應用名稱放在 Action Bar 中間，或者用 iOS 樣式的 Top Bar 都是很愚蠢的行為。請直接用 ActionBarCompat，如果有需要在更早的版本上實現 Action Bar，那麼 Action Bar Sherlock 也不失為一個好的選擇。

另外 Drawer 是用來放主要的導航元素的，像搜尋和設定之類的東西放進 Overflow 就行了。此外，螢幕內容滑動露出 Drawer 這種方式也是不建議的（具體請詳見之前的介紹文章 Android Design 趨勢——Navigation Drawer）。

既然這篇文章講的是誤區，那麼這裡就尤其要強調一下不應該放進 Drawer 的東西。首先最上面的主頁探索購物和個人資料是完全沒問題的。中間的搜尋應該放進 Action Bar，因為這是一個很常見的”動作“，而且不是一個”導航元素” 。設定，幫助，關於和反饋都是應該放進 Action Overflow 的東西另外，廣告什麼的絕對不要有。也沒有必要在 Drawer 中推廣自己的 App，這些東西放進”關於”裡倒是可以的。至於”我姐妹的朋友有個網站我保證它很有意思請務必去看看”這種東西，趁早刪了為妙。

第四：自制的非 Android 風格的分享

首先注意一下，這裡提供的三個截圖都是正面的例子。

實際上，強大的應用間分享一直是 Android 的強項。Android 系統也提供了很方便的分享功能（ACTION_SEND）。開發者完全沒必要也不應該人為的把分享的目標限定在某幾個應用上。另外，自制的符合 Android Design 的分享功能也是不錯的選擇，比如右圖的 Timely，還有沒出現在圖片中的 Pocket，它們針對分享的內容 (文章和應用) 預設列出了幾個比較推薦的分享方式，同時也允許使用者點選 More 來選擇其它的應用，免得使用者面對一長條的列表不知所措。

第三：利用 WebView 來模仿原生應用

如果你上過 YouTube 的話應該不難看出，左邊的應用整個就是源自 YouTube 網頁版的 ADiA 播放列表，只不過加了個 Action Bar 罷了。而右邊則是一個很不錯的例子，一個第三方的 ADiA 應用。它採用了響應式設計和原生介面，繼承了 Google+ 的評論和話題功能，提供每期 ADiA 幻燈片的檢視功能，還有節目提醒，是一個非常棒的應用。

利用 WebView 來模擬原生應用並不是個聰明的選擇，因為實際上他的性質是欺騙使用者。如果你試圖用 WebView 來呈現 Android 的核心 UI 控制元件， 效果不會很好。而且，這麼做也會造成執行效率的降低，於使用者而言就是不順滑，反應慢。

不要僅僅是為了”登陸 Android 平臺”而把一個 web app 打包成 APK 釋出，Web App 就讓它以 web App 的形態存在吧，Android 歡迎 web Apps。使用者可以把 web Apps 以書籤的形式固定在桌面，完全沒必要專門釋出一個偽裝成本地應用的 web App。實際上，使用者使用瀏覽器的時間越來越多了，瀏覽器的平均效能也在不斷提升，你並不會因為沒有釋出本地應用就流失使用者。所以完全不必要為此擔心。

當然，並不是說完全的禁止使用 WebView。舉個例子，GMail 就採用了 HTML 來渲染郵件內容並且效果很棒，四次元之前也一直是採用 WebView 來進行圖片瀏覽。

第二：貧弱的首屏互動

無論對於什麼樣的應用，首屏的重要性都是不言而喻的。開門見山的要使用者註冊，使用啟動畫面都是很糟糕的。使用者更希望應用能直接給它帶來內容，而登入和註冊都最好留到萬不得已的時候再做（微博這樣的東西除外）。另外，先讓使用者明白你的應用到底是幹嘛的然後再要求註冊，是比較合理的。

而正確的做法則是應該整合流行的社交網路登入選項，並且檢測使用者是否已經安裝了它們的客戶端，如果有，就可以直接通過客戶端驗證登入，能夠大大減少輸入使用者名稱和密碼的麻煩。實際上，你可以做盡可能多的事情幫助使用者快速通過註冊和登入，而不是讓他們感到煩躁。在這方面，整合 G+ 登入的應用的體驗就是極好的，我只需要按下登入按鈕，選擇賬戶，許可許可權就行了，比起國內各種應用的輸入使用者名稱/郵箱/密碼要便捷太多。

另外，你也可以採用展示動畫/圖片幻燈來告訴使用者你的應用是幹什麼的。這方面做得很好的是 Next Browser。

第一：Android ≠ 豎屏手機

Androi 裝置千千萬，並不是只有豎屏的手機。糟糕的平板支援或者橫屏支援只會給你的品牌帶來負面的影響（如 MIUI 自帶應用都還沒有支援橫屏）。

有很多人確實是會橫著用手機的，比如說那些用車載底座/充電底座的使用者。橫屏支援的方式有很多，請挑選最合適的方案。而且這裡的重點其實是，不要強迫使用者只使用某個方向的裝置。

另外，Android 平板的佔有率也在不斷變多，雖然手機和平板間的界限越來越模糊，但這可不是不提供平板支援/優化的介面。Android 裝置幾乎囊括了從 3″ 到 10″ 間的所有尺寸，所以合理的利用響應式設計吧，它能提供更為合理的多屏支援。仔細考慮留白，佈局和其他設計，不要忽視那些平板使用者。 只要一兩個小時的 XML 工作就能讓你做到很多東西。

到這裡，十大常見錯誤就都說完了。如果你覺得還有什麼常見的錯誤，請在評論或者微博評論或者 G+ 評論中告訴我。

自人人都是產品經理