Android 應用中十大導航設計錯誤
原文網址連結：http://www.geekpark.net/topics/199244
1.將導航項放在 Action Overflow 裡
我應該已經不止一次在各種 App 上看到有人把導航項放在 Action Overflow 中了。經常被放進 Action Overflow 的導航有"主頁"，"商店"，"我的資訊 (微信，twitter 中槍)"，甚至一些分類。但是 Action Overflow 真的不是導航項該去的地方，別忘了這地方是ActionOverflow，是用來放操作的。還有另一個很重要的原因是，在很多有著 Menu 按鈕的手機上，應用中是不會顯示 Action Overflow 的，他們得被 Menu 鍵喚出，可見性太低了，而且關於 Menu 鍵還有一大堆問題 (這裡就不展開了)。
2.錯誤的導航層級
這個錯誤也是頗為常見的。在 Android 中我們有很多常見的導航方式，比如 Tabs，Spinners 和 Drawer。這些導航方式當然是可以搭配著使用的，但是當你搭配使用這些導航方式的時候，請注意他們之間的層級關係。當你規劃你的導航層級的時候，一般情況下是要構造一個樹狀結構，在一個層級下有其他的子層級，以此類推。在 Android 中，不同層級一般對應著不同的導航方式。而錯誤的用法是，比如上圖中那樣的，用 Tab 作為最高導航層，Spinners 作為次層，而 Drawer 作為最次層。在 Android 上，這三個導航方式對應的層級是遵循著比較嚴格的規定的。
上圖呢才是一般情況下的正確做法。通常情況下，Drawer (如果有的話) 代表著最高的導航層級，然後則是 Spinners，再次是 Tabs。如果你有超過三級的導航層級，我們強烈建議你把最頂端的幾個都放在 Drawer 中 (只有 Drawer 能容納超過一個導航層級，因為 Drawer 中的專案能夠以合理的方式展開)，然後把剩下兩個層級分配各 Spinners 和 Tabs。當然，實際上作為一個移動應用，簡化層級也是非常重要的，我們強烈的不推薦你在應用中採用非常深的導航層級，這隻會讓使用者感到困惑。
還有一點需要注意的是，雖然在上面的示意圖中 Spinner 和 Drawer 共存而且看起來 Spinner 在 Action Bar 上 (Drawer 實際上在 Action Bar 之下)，但是在實際應用中，當用戶劃出 Drawer 的時候，你應該讓 Drawer 漸變成另一副模樣 —— 只留下在應用中全域性通用的操作，比如搜尋，隱去其他的東西，比如 Spinners，換成 App 的名字。這樣的話就不會產生導航層級上的困惑了。
另外，關於 Drawer，我們還有另一期專門介紹它的 ADiA:Android Design 趨勢——Navigation Drawer。
3.不能滑動切換的 Tabs
在 Android 中，Tab 幾乎是綁定了橫向滑動的操作。使用者對 Tabs 的期望就是他們可以被滑動。如果你在頁面上採用了 paginate (ViewPager) 內容，那麼內容上的滑動操作就會和 Tabs 的全域性滑動產生混淆。當然，如果頁面中只有一小部分是可以滑動的內容 —— 比如一個非全屏的圖片瀏覽，那麼這麼做是完全沒問題的，只要不與 Tabs 本身的滑動手勢衝突即可。
正確的做法很簡單，只要把橫向的 ViewPager 給改為縱向就行了。當然，如果你有其他的解決方案也很好，只要規避與導航的手勢衝突就可以了。
4.深層/頑固的 Tabs
什麼叫做"深層"的 Tabs? 要解釋深層，一般來講我們用"淺層"來做對比。在 Android 上，Tabs 應該是淺的。你用 Tabs 來作為試圖更變，或者分類切換之用，而不應該在 Tabs 之內再有層級和歷史。通常情況下，Tabs 只應該在導航介面出現。在上圖的例子中，使用者點選一個專案，理應開啟一個全新的頁面，而不是重新整理 Tabs 下的內容。這種持續出現的 Tab 就是我們所說的深層 Tabs，或者說在 Tabs 之內有歷史。
之所以不這麼做的原因是，當你離開了這個 Tab，比如說滑動到了另一個 Tab 上的時候，你就把這個 Tab 置於了一種尷尬的境地 —— 現在這個 Tab (對於使用者而言不可見) 應該顯示什麼呢? 當用戶從另一個 Tab 回到這個 Tab (無論是點選還是滑動) 時，他應該保持原來的樣子 (顯示內容) 呢，還是顯示列表? 在這種情況下，使用者會很容易的感到困惑。為了避免這種尷尬，我們建議 Tabs 最好做得淺一些。
另外，若你的 Tabs 堅持不變的話，很大程度會影響到 Back 的作用。當用戶切換到不同的 Tab 並且在這個 Tab 中做了一些操作之後，Back 的作用就會變得不甚明確。如果你非得在同一個檢視內顯示新內容，那麼我們建議你採用 Drawer，Drawer 才是為全域性內容切換而生的。
上圖顯示的才是正確的做法，開啟一個新的，沒有 Tabs，有 Up 的介面，而不是繼續顯示 Tabs。
5.溯回 (反向遍歷) Tabs
前面說的 Tabs 不應該深層，同樣也提到了 Tabs 不應該包含歷史。什麼叫做不因該包含歷史呢? 就是指，你在 Tabs 上的操作不能被 Back 溯回。同一個導航層級是不應該被溯回的。
6.溯回 (反向遍歷) Drawer
和 Tabs 一樣，Drawer 中的導航項也不應該被溯回。理由同上。當用戶在不同的導航項中切換時，你應該重置任務狀態。在不同的導航專案中切換就像是切換到不同的應用中一樣 (比如說，在 Google+ 中，Photos Tab 根本就是另一個應用。。。)。在使用者按下 Back 的時候，你應該退出應用，或者回到應用的主介面 —— 這裡的主介面是指哪個自然狀態下的初始介面，一個你特別希望使用者 (同時使用者也特別期待能夠容易地) 回到的地方。
7.深層的 Navigation Drawer
前文說過，一個移動應用不應該有複雜的結構。如果你需要特別多的導航層級，那麼說明你真正應該做的其實是簡化你的應用結構。Drawer 存在的意義是提供一個穩定的導航樞紐，讓使用者不需要記住自己在什麼地方，他只要開啟 Drawer 就能自然的明白一切。但是，如果在 Drawer 裡面彈出了一個次級 Drawer 會把很多人逼瘋。
Drawer 雖然有能力承載多個導航層級，但是正確的做法不是這樣的。
當你需要在 Drawer 中放入多個導航層級的時候，不應該以新彈出一個 Drawer 的方式，而是應該以展開/摺疊的方式呈現這個子層級。展開和摺疊並不會造成整個控制元件的劇變，同時能展示給使用者少多一些的專案。關於 Drawer 上的導航項以及觸控區域的設定，在Android Design中另有提及。
如果你的導航層級真的很深，你可以單獨做出一個次級導航頁 展示所有的導航專案。比如說，在 Play Music 中，曲庫下的 Tabs (藝人，專輯，風格，曲目) 其實完全可以做成 Drawer 中的次級導航項，但是把它們分散到 Tabs 中能夠更好的優化導航。(上圖這樣則是有點類似腹肌式的導航方式。當然，最好不要只是在上面寫著文字，可以往裡面新增點圖片啊，內容預覽什麼的)
8.錯誤的 Drawer 轉場
我們在這裡說轉場的時候，是意味著過渡動畫和一個有著 Drawer 的介面和沒有 Drawer 的介面之間的切換。下面兩個錯誤都和這個轉場有關。
當用戶開啟 Drawer，按下其中一個專案之後，他不應該被帶去一個有著 Up 箭頭的新介面。所有在 Drawer 中呈現的導航項，都應該在其介面中顯示 Drawer 指示 (比如說，"漢堡")。而且，當用戶通過 Drawer 從其中一個導航項進入另一個導航項，他不應該看到標準的檢視切換動畫 (漸變 + 放大，常見於進入新介面/新活動時)，而應該是一個細緻而迅速的漸隱 + 漸顯動畫，伴隨著 Drawer 的關閉而完成。同樣的動畫也應該應用在 Action Bar 的轉變上。還有一個對於開發者而言常見的討論是，應該用 Activity 還是 Fragment? 這個問題並沒有標準答案，也很難回答。一般來說還是視情況而定 —— 它實現起來難度如何? 對於我的應用而言靠譜嗎? 如果你有什麼建議的話當然歡迎評論。
上圖展示的就是正確的做法，在 Action Bar 上顯示 Drawer Indicator。
9.不顯示 Up 箭頭
上文說過，所有出現在 Drawer 中的導航頁面都應該顯示 Drawer 指示，這點反過來也是一樣成立的 —— 沒有顯示在 Drawer 中的東西就不應該顯示 Drawer 指示。比如在上圖，當用戶進入某個內容的時候，Drawer 指示依然顯示。實際上，這個內容頁已經不是導航頁了，也沒有在 Drawer 中顯示，這裡是應用更深的層級，已經不歸 Drawer 管了。這裡應該顯示的是 Up。
在顯示 Up 同時，你也可以允許使用者以邊緣滑動的方式喚出 Drawer。你不需要總是顯示 Drawer 指示來告訴使用者可以喚出 Drawer，因為在次級介面中喚出 Drawer 是某種意義上的"進階使用者操作"。有人發現了，那很好，沒人發現，不要緊，通過 Up 他們依然能夠找回 Drawer。另外，你可以看看 Google Play Newsstand 是如何處理在沒有 Drawer 指示的地方處理 Drawer 的 —— 漸變動畫真的非常重要。
10.右側導航
前文說過，Android 上有個規律就是"導航靠左，操作靠右"。對於從左向右閱讀的使用者而言，左側導航項能夠更好的強調導航層級。另外，由於 Spinners 只能出現在左側，Tabs 也往往將最左側的一個設為預設，右側的 Drawer 與這些操作距離過遠。而且，Drawer 指示放在左邊，操作的時候向左回縮，如果在右側使用 Drawer 的話就會遇到各種各樣的視覺隱喻衝突。
正確的做法就是如上圖所示。當然，如果在從右向左的語言環境下 (比如說，希伯來文什麼的，不過我覺得我們國家的開發者應該不怎麼會去做希伯來語適配吧……)，那當然是應該反轉這些東西的位置。
轉載於:https://my.oschina.net/agileai/blog/469598