交互設計探秘抽屜導航的前生今世

 

　　@沐沐成長中 ：Google不久前剛剛更新了他們的Google+應用，采用了新的導航方式並拋棄了navigationdrawer。一時之間，又引發了一系列關於NavigationDrawer利弊的討論。

　　Navigationdrawer又被稱為“OffCanvas“、”hamburgernavigation“、”sidenavigation“、“slidemenu”等等，雖然叫法不一樣，但大致都是同一種形式的導航。

　　NavigationDrawer的前世今生

　　據考究，Navigationdrawer最早源自於Youtube，如下截圖。

　　而“三道槓”的icon最早出現在1981年NormCox設計的個人工作站XeroxStar。

　　詳細見“Wheredoesdraweroriginatefrom?”

　　2012年，Youtube、Facebook、Path等應用紛紛使用了Navigationdrawer這樣的導航方式，一時之間引發了廣泛的關注，甚至可以稱為一種設計的趨勢。

　　Facebook

　　Path

　　但由於沒有統一的規范，各個產品的抽屜導航設計也各不相同，為了控制Android平台日益混亂的抽屜交互方式，2013GoogleI/O大會之後，Google將NavigationDrawer納入了AndroidDesign規范當中，隨後大量應用開始采用這種交互模式。

　　2014GoogleI/O大會剛剛結束，筆者會持續跟進，敬請關注後續更新。

　　備受爭議？

　　關於Navigationdrawer利弊的討論也一直不停，直到2014年5月，Googleplus更新，去掉了抽屜導航，一時之間，又引發了熱烈的討論。

　　可以說Navigationdrawer的出現也是應需而生，較之PC，移動設備屏幕尺寸較小，可以說“寸土寸金”，抽屜導航最明顯的一個優勢就是節省屏幕空間，讓導航“藏”在側滑抽屜裡，釋放了更多的空間給主要內容。

　　再者，Navigationdrawer實際上是開辟了另一種新的導航模式，區別於在此之前的幾種主要導航模式：腹肌式(Six-pack)、下拉欄式(Spinner)、選項卡式(FixedTabs)，它(Navigationdrawer)彌補了其他幾種模式在非頂級視圖間進行導航的缺陷——用戶必須退回頂級視圖，在頂級視圖切換分類之後再進入其他內容，也就是說Drawer的好處就是能夠提供在非頂級視圖間導航的能力。

　　如下圖所示，從3.3跳轉到4.2，如果用其他導航，需要逐級回到頂級視圖再逐級進入最終頁面，但是Drawer可以方便快捷的實現頁面之間跳轉。

　　然而自抽屜導航出現初期就一直伴隨著質疑，甚至LuisAbreu用“為何以及如何避免使用漢堡導航?”作為文章標題，其對於Navigationdrawer的態度可見一斑。

　　當然，還有AnthonyRose用Zeebox的實踐經驗告訴我們，“抽屜導航可能會降低你產品一半的用戶參與度”。(自備梯子)

　　對NavigationDrawer的質疑大致可歸納為以下幾點：

　　1. 可發現性低;

　　2. 在某些平台下，和平台固有的導航設計模式有所沖突;

　　3. 低效，並非一瞥即得。

　　大多數質疑聲都集中在這個Drawer的可發現性上，他們認為“如果看不到，自然也就想不到”(Outofsight，outofmind)，在默認狀態下，Drawer都是隱藏的，與傳統的經驗——最重要最常用的功能放到首屏相悖，用戶比較難發現隱藏的導航，增加了認知負擔。

　　其次，在iOS平台下，官方標准的導航模式一般左上角是返回，而且支持左滑(從左往右滑動)返回的手勢操作;Drawer也是將icon放到左上角，這樣就產生了如下圖的沖突，actionbar的左上角有多個icon，而且交互模式類似，如下圖。

　　再次，特別是在信息層級扁平的產品中，Drawer只是在視覺上簡化了界面，功能並沒有減少，“隱藏”其實是增加了“呼出抽屜”的操作，讓原本直接操作的過程變得復雜了。很難想象如果微信的Tab導航變成Navigationdrawer之後，會是怎樣一番吐槽的場景。

　　需要理清的問題

　　NavigationDrawer作為一種導航模式，已經不僅僅是Android平台獨享，iOS甚至Windows平台都有類似的模式，當我們提到抽屜導航，其實應該是指廣義上的，跨平台的。

　　雖然都是“Drawer”，但“此Drawer非彼Drawer”，不可混為一談。這種混為一談在NavigationDrawer的各種褒貶爭論中屢見不鮮。

　　例如飽受诟病的“沖突”問題——“左滑返回”與“左滑呼出導航”沖突，其實就是混淆了平台特性。之所以認為是沖突，是建立在如下基礎之上的，即“在產品任何一個層級均可激活抽屜導航”(詳見 Android官方文檔，自備梯子)，所以需要預留左滑手勢為呼出導航，於是指出與系統手勢(左滑返回)沖突。

　　請注意，前者是Android的規范，但後者是iOS啊!所以針對這樣的問題，應該按照不同的平台分別對待，尋找解決方案。

　　以iOS平台的知乎為例，使用NavigationDrawer，但是並非任何一個界面都可呼出導航(誰讓iOS規范裡沒規定呢，啧啧)，進入詳情頁後，左滑和左上角back都只是返回操作，需要切換到其他詳情頁或者返回問題列表頁才能呼出導航菜單，沖突問題得到解決。

　　誠然，只看Android，即使是官方規范中也還是存在一些沒能完美解決的問題，例如到達具體詳情頁面，ActionBar上UPicon與Drawericon有一定意義上的沖突，保留任何一個都不那麼完美。但這是另一個問題了，不是麼?

　　被遺棄？

　　不久前，Googleplus更新，去掉了Navigationdrawer的導航形式，於是有人大呼風靡一時的抽屜導航將被遺棄，但筆者認為並非如此。問題不在於遺棄與否?而在於如何不被遺棄?換句話說就是如何正確的使用Navigationdrawer?

　　Navigationdrawer作為一種導航的模式，有其應用的場景和價值，而其備受诟病的“難以發現”問題也隨著用戶的長期使用下逐漸弱化，使用習慣的培養使得現在用戶再看到“三道槓”已經不再像兩年前那樣不知為何物了。

　　在哪些場景下建議使用抽屜導航呢?Android規范中已經總結的較好，有興趣的可點擊鏈接查看，這裡簡要概括如下：

　　1. 頂級視圖超過3個;

　　2. 低層視圖交叉導航;

　　3. 導航層級很深;

　　4. 導航樞紐：用戶需要頻繁訪問導航。

　　上述場景，其他平台也同樣適用。抽屜導航只是眾多導航的一種，需要考慮清楚使用場景謹慎使用。

　　如何正確使用?結合筆者觀察的一些使用Navigationdrawer的app，提供如下建議：

　　1.新手引導，初次進入app，默認展開抽屜，然後自動收起;可以考慮設置展示頻率，例如前50次默認展開;

　　2.區分平台，因地制宜。可以針對不同平台，做不同的解決方案，只借用抽屜的優勢，不必局限於Android官方文檔裡規定的交互模式。筆者體驗、觀察了數十個抽屜導航的APP，下面將以android平台的亞馬遜和iOS平台的知乎為例，以供參考。

　　Amazon(Android)

　　Android平台使用Navigationdrawer的APP之中，數Amazon最符合Android規范，例如Actionbar固定不動，即使是進入更深層級的界面，Actionbar也一直顯示導航icon，可隨時激活抽屜導航，支持從邊緣左滑，但不支持從屏幕中間左滑，所以不存