我们曾经提到过，汉堡菜单将成为移动端设计的主流模式——然而根据数据研究表明，汉堡菜单的弊大于利
我将尽量在本文中保持客观的态度，向各位展示汉堡菜单的问题所在，解决问题的方案，至于如何对待这种设计模式，我相信仁者见仁，智者见智。
一、问题所在
难于发现
效率低下
在某些平台下，和平台固有的导航设计模式有所冲突
无法一瞥既得
1.难于发现
“如果看不到，那么自然便想不到”
传统的经验是：最重要、最常使用的功能放置在首屏。然而汉堡菜单打破了这一惯例。用户首先要去了解汉堡菜单是可以激活/关闭的——尽管汉堡菜单现在极为流行，但是很多应用都会在用户初次使用时提示用户，否则一些新手用户很可能无法在主屏上找到主要功能。
2.效率低下
当用户知道在侧边可以开启导航菜单后，新的问题出现了：这种设计模式会强迫，逼迫用户打开应用之后立马开启侧边菜单，否则无法进行操作。
相对于下面传统的标签栏导航设计，我们可以看到，传统的设计模式，所有功能/元素直接陈列在主屏幕中，用户打开应用后可以立即操作。
3.和平台固有的导航模式有所冲突
在iOS平台下，问题尤为突出，和iOS标准的导航设计模式有所冲突，iOS中，一般左上角是返回。而汉堡菜单的开启图标，一般也位于右上角。
如果设计师执意要采用汉堡菜单这种导航设计模式，那么在一些层级丰富的应用设计中，麻烦便凸显:既然左上角用来放置汉堡图标，那么便和返回按钮冲突了。有时候便需要滑动手势来进行层级切换——然而，这种操作模式并不直观。
4.无法一瞥既得
现在的主流设计观念是：尽量让用户直接与信息进行交互。然而汉堡菜单所代表的导航模式，信息无法一瞥既得，用户需要打开侧拉菜单，才能发现信息。
上图是Jawbone UP的应用:摒弃了底部标签栏导航模式，将通知放在右上角，和汉堡图标遥相对应。
这种简化好么？不见得，虽然视觉简化了，但是功能没有简化多少，换言之。设计者简化了视觉，却提高了应用的理解难度（以及操作复杂度）——好看的未必适用。
相反，看看Twitter的标签栏导航，一瞥既得，减少了用户的理解难度，同时让用户可以直接导航。
5.认知问题
当提到侧拉菜单和汉堡图标的时候，有一个理论被支持者反复提及：可以节省屏幕空间，提高阅读区域，进而提高可读性。
但是又何必为了节省屏幕空间而违背一些最基本的人机交互定则？应用需要有焦点区域，应用需要有明确的导航，让用户知道自己身处层级的何处。
注意：或许是时候去重新理解人机交互理念了，这样才能避免华而不实的设计错误出现。
二、解决之道
尽管有很多论述指出了汉堡图标的问题所在，但是并没有人提出解决方案。
1.首先要思考的是，这种设计模式在何种情况下有效？
我个人认为，汉堡菜单设计模式不太实用，仅仅在个别案例中有效。
IRCCloud便是一个优异的案例，它证明了汉堡菜单导航模式的价值所在——辅助用户进行频道切换（左）和展示频道成员（右）。
在这个案例中，汉堡菜单是可行的，因为主界面没有子界面，没有层级上的堆叠。（当层级比较复杂时，便需要考虑一下是否要摒弃汉堡菜单了)
虽然这个案例很棒，但是很明显，这款应用的界面有些臃肿，信息过载，信息架构需要重新设计一下了。
右侧的侧拉菜单展示了频道成员，左侧的侧拉展示了频道列表。用户可以选择切换频道，选择用户。但是没有太多地方去展示行为控件——因此设计者将操作按钮放在了左下角。整体看起来非常的冗杂。
2.那该采用怎样的导航模式？
侧边菜单会导致糟糕的信息架构，尤其是在层级复杂的应用设计中。
解决方案是重新审视信息架构
上图便是改动方案，左图中的彩色小点转换为右图中标签栏中的标签。
谨记:
1.要在标签栏中清晰的展示用户所处的功能界面。
2.要保证所有功能元素的可见性和可达性。
3.不要有导航手势的冲突。
解决了侧边菜单所导致的交互问题之后，其实用标签栏导航同样可以节省屏幕空间：根据滚动方向来选择是否隐藏导航栏——请看Facebook应用和Safari。固定的标签栏能够清晰的暗示用户当前所处的位置。
[忍不住多说几句]网站不要无脑抄袭iOS的导航模式，对于某些重形网站来说，重新审视一遍信息架构，再进行移动端设计，比完全照搬iOS导航模式的效果要好得多。
3.如何扩展标签栏导航模式
下图所给的案例全部基于iOS，可以解决标签栏扩容问题。
某些情况下，应用的功能点超过了5个（标签栏大致可以容纳5个标签），可是如果需要扩展怎么办？目前主流的标签栏导航模式中，都采用下图这种办法，提供了一个“更多”图标，点击后会进入另外一个界面，这种效果并不理想，因为跟侧拉菜单一样——功能被隐藏了。如果要扩展的内容超多，可以考虑使用这种方法。
另外一种方法可以参考Rookie，可以滑动标签栏。但是也有缺点，容错率较低，点击手势和滚动手势可能会冲突，可能会出现误操作。
