ANDROID應用中十大常見UX錯誤

 　　Android 開發者關系團隊每天都會試用無數的 App 或者受到無數的開發者發來的請求評測的 App，在評測如此之多的應用之後，他們總結出了10個最常見的錯誤。

　　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 罷了。而右邊則是一個很不錯的例子，一個第