- 原文地址：Tab Bars are the new Hamburger Menus
- 原文作者：Fabian Sebastian
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：Rydensun
- 校對者：foxxnuaa Park-ma
這篇文章，我們將會討論一種失去控制的導航模式。
通常，我不喜歡只吐槽一些不好的 UX 設計，也不喜歡僅僅指出一個問題。相反，我一直努力給出一些建議和解決方案。這次情況有些不同：解決方案很明顯 —— 就是 tab bar —— 但是近些年，這個解決方案的最初意圖有些迷失，導致了同樣的老問題。在我們探討解決方案之前，是時候再次討論這些問題了。但凡事一步一步來：
歷史課程
2014 年，Apple 在考慮移動導航應該如何工作時，提出了一個底層的改變。在那之前，“漢堡式選單”或“抽屜式導航”（Material Design 官方命名）在移動應用導航裡最為流行。在 2014 年，WWDC 演講 “設計直覺性的使用者體驗” 中， Apple 基本上打碎了這種設計元素並且建議使用一種不同型別的導航 —— 如 tab bars。
WWDC 演講 “設計直覺性的使用者體驗” (來源： developer.apple.com/videos/play…)
這個 WWDC 演講像病毒式的擴散，全世界的 UX 和 UI 設計師開始探討漢堡式選單的弊端：
- 為何並且如何避免漢堡式選單
lmjabreu.com/post/why-an… - 漢堡式選單的替代方案 —— UX Planet
uxplanet.org/alternative… - 消除漢堡按鈕 —— TechCrunch
- techcrunch.com/2014/05/24/…
- 漢堡式選單和隱藏式導航違背了 UX 設計原則 — NN Group
- www.nngroup.com/articles/ha…
從那開始，漢堡式選單開始消失並且 tab bar 替代它作為預設方案。2015 甚至谷歌（抽屜式導航之父）都開始引入一種“底部導航”（等於 iOS 中的 “tab bar”）到他們自己的安卓應用和 Material Design 指導原則中。這看起來是滿足直覺性導航目標的最佳解決方案。設計師們開始思考他們想要實現的目標。
底部導航, 谷歌 Material Design 指導原則 (來源: material.io/design/comp…)
導航目標
簡述: 一個導航簡單來說是要告訴使用者三件事:
- 我在哪？
- 我還可以去哪？
- 當我到那時我能找到什麼？
Tab bar 滿足了所有的 3 個問題。它在每個螢幕中都是可見的，因此可以一直給你視覺化的引導。它展示出在資訊架構中你在哪裡（選中的 tab 會高亮），你可以去哪裡（其他的 tab）並且告訴你你將會在那裡找到什麼（圖示和描述性的標籤）。你可以接觸更深層次的內容（從父級螢幕到子螢幕），這個過程中，你並不會丟失上下文聯絡和你在應用中的位置。
換句話說: Tab bar 是移動導航一個完美的解決方案。至少他們曾經是 —— 直到設計師們開始在使用它們時不再去考慮“為什麼？”。他們在考慮真正的問題之前先去考慮解決方案，忘記了什麼是 tab bar 最初要去實現的。現在 tab bar 經常像 2014 年前漢堡式選單那樣被使用。
Tab bar 的問題
看看下面的 UI，你喜歡的 Medium iOS 版 app，試著發現它的問題：
截圖: Medium iOS 版本 (文章模組)
當使用者從上層檢視導航至子檢視（比如文章），子檢視會覆蓋包括 tab bar 的整個螢幕。
截圖： Medium iOS 版本 (個人設定)
現在，讓我重新看一下導航的三個目標：
- 我在哪？
- 通過在子檢視隱藏導航，使用者不再知道他是在 app 的哪一個上層頁面。使用者會丟失他在整個資訊架構中的位置。
- 我還可以去哪？
- 通過隱藏其他的上層頁面，使用者便不能夠直接導航至 app 的其他區域。相反，他們需要先返回至資訊架構的頂部。
- 當我到那時我能找到什麼？
子檢視上僅有的一個導航元素是一個不附帶任何描述的小小的左箭頭。它不會告訴使用者，通過點選它，你會到哪裡。
Medium 可能在引入 tab 導航方式時有最好的意願，這也是其他成千上萬的 iOS 和 Android app 有的意願。它在頂層檢視時工作很完美，但他們在子檢視上的實現，卻是沒有滿足任何一個導航目標。
子檢視就像一個 模態檢視，遮擋住了整個導航系統（tab bar），但他的動畫展示卻像一個子檢視（從右向左），並且展示了一個後退連結（箭頭）。但模態並不是一個不好的東西。“模態通過阻止使用者做其他事情，直到他們完成了當前的任務或是取消這個訊息或者檢視，來吸引使用者注意力” (蘋果). 但是模態也需要使用模態動畫（iOS：動畫從底部到覆蓋整個螢幕）並且包含完成和取消按鈕來退出模態檢視。模態檢視只是用來完成短期任務的，這些任務是自我包含的程式並且只可以被完成或是取消，比如寫一個郵件，在日曆上新增一個事件，取消一個通知等。他們並不是被意圖用來當做一個詳情介面或是來代替一個子檢視。那些子檢視並不是一個自我包含的程式並且他們也不是隻可以被取消或是儲存的。
一些人可能會說，對於這些模態的嚴格用法也有一些特殊情況，例如全屏詳情頁面，就想一張單獨的圖片。通過隱藏 app 的整體 UI（如 tab bar）來創造吸引力和減少注意力分散。在這些情況下，通常會使用一個自定義轉場動畫來解釋這些模態的不尋常用法。然而，Medium 的文章詳情可以被考慮成為一個全屏的想也頁面，但是缺少一個自定義專場動畫。而且，那個差不多的設定頁面是絕對不可能這麼被考慮的。
自定義的針對內容的轉場動畫 (來源: material.io/design/navi…)
谷歌和蘋果的做法
只有在極少數情況下，蘋果和谷歌會在某個問題上保持意見一致。這就是其中一個極少數的情況。蘋果和谷歌的指導原則中都鼓勵設計師在使用 tab bar（底部導航） 的時候，將它一直顯示在應用的每一個螢幕上：
“當底部導航被使用時，應該在每個螢幕的底部都顯示” — 谷歌 Material Design
“Tab bar 只有在鍵盤顯示時才隱藏” — 蘋果 Human Interface Guidelines
蘋果相當嚴厲的遵守自己提出的規定，在其 app 的每一個自螢幕上都顯示 tab bar，比如 Apple Music, Photos, Podcasts, Health 或 Files。
Tab bar 在 Google Photos vs Apple Photos
然而谷歌經常打破自己的規定，因其經常在子檢視上隱藏底部導航。當 Youtube（谷歌開發）一直保持底部導航的可見性時，Google Photo 和 Google+ 卻在子檢視中隱藏掉它（如相簿和群組）。Material Design 指導手冊中從來沒有明確的要求設計師把底部導航放到每一個子檢視中，但卻要求它被新增到“每一個螢幕”中，這其中並沒有指出這些螢幕在資訊架構中的層次。
蘋果一直都是在每個 app 底部都使用 tab bar，谷歌經常看起來是在每個螢幕底部都使用底部導航。這樣做，谷歌就製造了一個子螢幕，它既不是一個真正的子檢視（因為沒有明顯的主導航），也不是一個模態檢視（因為它不是一個自我包含的程式，沒有取消和儲存按鈕）—— 它是一個介於兩者中間的東西。然而這些介於中間的螢幕是一個正在變大的問題。理論上，谷歌確實是引入了等價意義上的 tab bar，但實際上他們可能只是引入了另一個漢堡式選單。許多 iOS 開發者隨後都適應了“谷歌方式”的 tab bar 使用方法。通過這樣做，他們忘記了最初為什麼 tab bar 會替代漢堡式選單。
*編輯於 28.05.2018: 如 Craig Phares 指出的,這是因為 iOS 和 Android 的開發工具對於 tab bar 的使用處理方式不同。Xcode 會自動將導航新增至每一個 View Controller。然而，安卓開發者需要耗費許多時間與努力在保持導航持續可見性上。 保持 tab bar 在每個新 activity 上可見. (Read more)
結論
為什麼谷歌要這樣使用底部導航？並且他們希望設計師如何使用這些中間物，模態子檢視? 我不清楚。我很希望能夠聽到谷歌關於這個的觀點！我也很希望聽到你們關於這個話題的觀點. 目前為止，這是我的建議:
- 在模態檢視和子檢視之間劃清界限並且知道何時去使用哪一個
- 只有在自我包含的程式下使用模態檢視 (包含某些特殊情況下的全屏詳情頁面)
- 對於其他所有的頁面使用子檢視
- 展示tab bar / 底部導航於每一個檢視 包含子檢視
- 隱藏導航欄（頂部）或是 tab bar（底部）在你滑動時，如果你想吸引使用者注意力並且最大化螢幕使用面積（比如文章等）
Tab bar 是新的漢堡式選單嗎? 某種意義上是的。如果正確使用的話，它們都是很強大的導航元素 (是的，某些情況下漢堡式選單的確 有意義). But once you start using tab bars for the sake of using tab bars (because everybody does), 但只要你開始使用 tab bar 僅僅是因為別人也用的話，你正在失去對於導航目標的認知。同樣的事情，4 年前也發生在漢堡式選單上，因此不要停止去思考“為什麼？”。
溝通是關鍵
歡迎留言： www.fabiansebastian.com
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。