編輯導讀：瀏覽網頁的時候，我們常常都能看到右上角有「漢堡菜單」，它們通常是三行堆積在一起，形狀類似於一個漢堡。而標籤欄則是直接把具體的導航分類列出來，讓用戶根據目的做出選擇。本質上來說，這兩種導航方式截然不同，但是有些時候標籤欄只是一種新的漢堡菜單。本文作者對此展開了說明，與大家分享。
在本文中，我們來討論一種失策的導航模式。
通常，我不想只抱怨糟糕的UX設計，也不想只指出問題。相反，我總是嘗試提出解決方案。這次是另一回事了：解決方案很明顯-它的標籤欄-但該解決方案的初衷在最近幾年迷失了，導致了同樣的老問題。在我們開始討論解決方案之前，是時候再次討論問題了。
2014年，蘋果在移動導航應如何工作方面引發了根本性的轉變。在此之前，「漢堡菜單」或「導航抽屜」（官方的Material Design命名）是最常見的移動導航解決方案。在2014年WWDC演講「 設計直觀的用戶體驗 」中，Apple基本上否定了此設計元素，並建議使用不同類型的導航（例如標籤欄）。
WWDC演講「設計直觀的用戶體驗」
WWDC的討論廣為流傳，全世界的UX和UI設計師開始談論漢堡菜單的弊端：
從那時起，漢堡菜單開始消失，標籤欄將其替換為解決方案。2015年，甚至是導航抽屜之父的Google也開始在自己的Android應用程式和《材料設計指南》中引入「底部導航」（即iOS「標籤欄」）。它似乎是滿足直觀移動導航目標的最佳解決方案，設計師開始考慮他們想要再次實現的目標。
底部導航，Material Design設計指南導航目標
快速回顧：「導航」必須告訴用戶的三件事：
標籤欄滿足所有3個要求。它在每個屏幕上都是可見的，因此始終為你提供視覺定向。它顯示了你在信息體系結構中的位置（活動標籤突出顯示），可以去的地方（其他標籤）以及在那裡可以找到的內容（圖標和描述性標籤）。你可以訪問更深的內容（從父屏幕導航到子屏幕），而不會丟失上下文和您在應用中的位置。
換句話說：標籤欄是一個完美的移動導航解決方案。至少是這樣-直到設計師開始使用它們而沒有考慮「為什麼？」。在考慮實際問題之前先考慮解決方案時，他們忘記了標籤欄最初試圖實現的目標。如今，標籤欄的使用方式與2014年之前使用漢堡包菜單的方式相同。
查看以下UI，你最喜歡的Medium iOS應用，並嘗試找出問題所在：
屏幕截圖：Medium 應用
一旦用戶從頂層視圖導航到子視圖（例如，文章），該子視圖就會覆蓋整個屏幕，包括標籤欄。
屏幕截圖：Medium（個人設置）
現在，讓我們再次看一下三個導航目標：
Medium包含選項卡導航時可能有最好的意圖。數以千計的其他iOS和Android應用程式也是如此。它可以完美地在頂級視圖上運行，但是它們的執行無法滿足子視圖中導航的每個目標。
子視圖通過覆蓋整個導航（選項卡欄）而表現為模態視圖（彈窗），但它的動畫效果類似於子視圖（從右到左），並顯示反向連結（箭頭），類似於子視圖。模態根本不是一件壞事。「模態通過阻止人們在完成任務或關閉消息或視圖之前執行其他操作」（Apple）。
但是模態還需要使用模態動畫（iOS：從底部到屏幕動畫），並包括完成和取消按鈕以退出模態視圖。模態視圖僅用於獨立任務的短期任務並且可以完成或取消，例如寫郵件，在日曆中添加事件，取消通知等……它們不打算用作詳細視圖或替換子視圖。這些子視圖不是一個自包含的過程，不能被取消或保存。
有人可能會爭辯說，這種限制性使用模態是有例外的，例如對於全屏細節視圖（如單張照片）。隱藏應用程式的整體用戶界面（如標籤欄）可創建焦點並最大程度地減少幹擾。在這種情況下，通常使用自定義過渡來解釋模態的不常見用法。
雖然「Medium」文章可以被視為缺少自定義過渡和關閉功能的全屏詳細視圖，但應用程式的設置視圖絕對不能。
沉浸式內容的過渡
蘋果和谷歌只有在極少數情況下才同意某個觀點。這是那些罕見的情況之一。Apple和Google的準則均鼓勵設計人員在應用程式的每個屏幕上一致使用標籤欄（底部導航）：
「使用時，底部導航欄出現在每個屏幕的底部」 – Google Material Design
「顯示鍵盤時，[僅]隱藏標籤欄[…]」 — Apple人機界面指南
Apple通過將標籤欄添加到其應用程式的每個子屏幕（例如Apple Music，Photos，Podcast，Health或Files）中，非常嚴格地遵循其自身規範。
Google相冊和Apple相冊的標籤欄
另一方面，Google經常通過隱藏子視圖的底部導航來打破自己的規則。儘管Google提供的Youtube始終保持底部導航的可見性，但Google相冊和Google+會將其隱藏在子視圖（如相冊和群組）中。《Material Design 設計規範》從不明確要求設計者將底部導航添加到子視圖，但他們要求他們將其添加到「每個屏幕」而不指定信息體系結構中的級別。
Apple始終按應用程式使用標籤欄，而Google似乎經常按屏幕使用底部導航*。這樣，Google創建的子屏幕既不是真實的子視圖（因為沒有可見的主導航），也不是模態視圖（因為這不是具有取消和保存按鈕的獨立過程）–在兩者之間。
這些中間的屏幕是一個日益嚴重的問題。從理論上講，Google確實引入了等同於標籤欄的標籤，但實際上，他們可能只是引入了下一個漢堡菜單。後來，許多iOS開發人員改編了使用標籤欄的「 Google之路」。這樣一來，他們就忘記了標籤欄最初取代漢堡包菜單的原因。
Google為什麼以這種方式使用底部導航？他們希望設計師如何使用這些中間的，模態的子視圖？我不知道。這些是我的建議：
標籤欄是新的漢堡菜單嗎？從某種意義上講，它們是。如果使用正確，它們都是強大的導航元素。但是一旦為了使用標籤欄而開始使用標籤欄（因為每個人都這樣做），你將失去對每次導航的最重要目標的關注，同樣的事情發生在4年前的漢堡菜單上。因此，不要停止思考「為什麼？」。
原作者：Fabian Sebastian
本文由 @Fyin印跡 翻譯發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。