而下圖所展示的是擁有傳統(tǒng)的固定導(dǎo)航系統(tǒng)(tab欄)的模式，其中的功能模塊一目了然，入口始終保持可見：

3.與系統(tǒng)的導(dǎo)航模式?jīng)_突

所有問題當(dāng)中最突出的就是這一點(diǎn)了。例如在iOS當(dāng)中，我們很難在不引起沖突的情況下將菜單按鈕與標(biāo)準(zhǔn)的回退按鈕同時放置在導(dǎo)航欄里。

我們即需要在導(dǎo)航欄里放置漢堡包圖標(biāo)來喚出菜單，也需要回退按鈕使用戶能夠退回上一級內(nèi)容。最后，要么就是如上圖所示的擁擠不堪的方案，要么就是取消顯性的導(dǎo)航，強(qiáng)迫人們一次次的右滑來回到初始界面并喚出側(cè)邊欄菜單。

4.不夠一目了然

在默認(rèn)狀態(tài)下，你無法獲取某個特定模塊的信息，因為菜單本身就是隱藏的，要了解模塊當(dāng)中的信息，你首先要經(jīng)由菜單進(jìn)入模塊才可以。

當(dāng)然，也可以像Jawbone UP應(yīng)用那樣直接通過圖標(biāo)來代表信息。但這種方式的擴(kuò)展性不強(qiáng)，你很可能需要針對不同類型的內(nèi)容維護(hù)一套多個圖標(biāo)，最終不得不通過一種更通用的方式來呈現(xiàn)信息提示，以減少復(fù)雜性;從“一目了然”的角度講，結(jié)果還是差不多。

而固定的tab欄，在任何上下文環(huán)境中都可以讓用戶清晰的了解到每個模塊當(dāng)中所發(fā)生的事情，并讓他們能夠隨時進(jìn)入相關(guān)界面。

用戶的認(rèn)知

作為設(shè)計師，我們可能會為了節(jié)約可用空間而不得不使用漢堡包模式;不過，在現(xiàn)實當(dāng)中，人們究竟是怎么看待界面的?這方面我們可能存有誤解。你認(rèn)為人們可以看到眼前的一切，其實他們只能注意到某個焦點(diǎn)區(qū)域，即使整個屏幕的尺寸很小。

節(jié)約屏幕空間——我們可以嘗試通過其他不會對導(dǎo)航造成負(fù)面影響的方式來達(dá)成這一目標(biāo);那些最基本的人機(jī)交互設(shè)計原則仍然需要遵守，例如通過一目了然的方式為用戶提供反饋、展示應(yīng)用當(dāng)前的狀態(tài)等等。

何時使用漢堡包菜單

嚴(yán)格的講，按照我們之前的分析，漢堡包菜單真正有意義的用法不是很多，多數(shù)情況下還是要盡量避免使用;不過例外也仍然存在。

IRCCloud是一個不錯的例子，在這里，漢堡包菜單模式是利大于弊的，因為IRCCloud同時存在兩套導(dǎo)航，通過漢堡包菜單，用戶可以在同一個界面環(huán)境中去到頻道菜單和會員菜單中進(jìn)行導(dǎo)航。

這種用法是可以接受的。它的內(nèi)容界面只有一級結(jié)構(gòu)，不再有下級界面，無需一層層的前后導(dǎo)航，因此不會發(fā)生導(dǎo)航?jīng)_突的情況。

不過即使是這樣，我們也可以看到，導(dǎo)航欄中的信息負(fù)載已經(jīng)相當(dāng)嚴(yán)重了。

其他負(fù)面結(jié)果也比較明顯。右側(cè)的會員菜單按鈕占據(jù)了通常情況下用來放置行動按鈕的位置，與當(dāng)前界面相關(guān)的操作無處擺放。設(shè)計師別無選擇，只能將各種與上下文相關(guān)的操作集成在左下角設(shè)置按鈕喚出的行動菜單當(dāng)中。

這也引出了本文的下一部分。

替代方案

最簡單直接的替代方案就是傳統(tǒng)的tab欄。

順便說一句，側(cè)邊欄菜單模式對于不良的信息架構(gòu)永遠(yuǎn)是來者不拒的，因為你總能很輕易的向里面添加項目，而不會產(chǎn)生直接的后果，直到用戶展開菜單。

將側(cè)邊欄菜單移入底部tab欄，你也有機(jī)會重新梳理產(chǎn)品的信息架構(gòu)。下圖演示了將側(cè)邊欄菜單各條目移入tab欄的方式，你可以根據(jù)里面的彩色小點(diǎn)看出信息架構(gòu)是怎樣重新整合的。

啟示

信息狀態(tài)可以直接呈現(xiàn)在tab欄當(dāng)中。

tab欄中導(dǎo)航項持續(xù)可見，點(diǎn)擊一次即可切換不同的模塊。

不存在手勢上的沖突。

使用傳統(tǒng)形式的tab欄不意味著我們無法解決縱向空間缺乏的問題，例如在滾屏?xí)r隱藏頂部的導(dǎo)航欄;位置始終固定的tab欄本身就可以用來呈現(xiàn)當(dāng)前界面屬于哪個模塊，使我們不需要一直依靠導(dǎo)航欄來呈現(xiàn)標(biāo)題等信息。

關(guān)鍵就在于不要隱藏導(dǎo)航信息，允許用戶直接訪問導(dǎo)航項，并且不要在手勢上與其他操作產(chǎn)生沖突。

擴(kuò)展性如何?

我們舉的例子都是基于iOS的，所以有可能用到的導(dǎo)航控件就是iOS的tab欄或工具欄。那么如果你的導(dǎo)航項超過5個該怎樣處理呢?

這種情況本身不太理想，而且搞不好也說明著你的app在信息架構(gòu)方面不是很合理。但是如果導(dǎo)航項確實超過5個，那么通常的做法就是讓第5個tab成為入口，也就是“更多”，使用戶能訪問到更多的導(dǎo)航項。

此外，可滑動的工具欄也是你可以考慮的模式，就像Rookie實現(xiàn)的那樣。不過這種模式的代價就是在同一個欄中的點(diǎn)擊與滑動手勢有可能帶來的誤操作。

要記住，相比于導(dǎo)航系統(tǒng)來說，這種模式其實更適合于作為工具欄，為操作行為提供容器。

此外在實際當(dāng)中，這種模式有可能帶來另一個問題，就是當(dāng)你選中其中某個tab或操作后，再將欄整體滾動，那么界面中的內(nèi)容有可能無法與底部欄中的選項建立關(guān)聯(lián)。Rookie的解決方案是，當(dāng)你選中某個功能后，工具欄整體會隱藏起來;完成該項任務(wù)后，底部欄會重新呈現(xiàn)。

本文作者?C7210