[譯] Tab Bar 就是新的漢堡菜單

• 原文地址：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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。