我们曾经提到过,汉堡菜单将成为移动端设计的主流模式——然而根据数据研究表明,汉堡菜单的弊大于利 汉堡菜单到底好还是坏?这个话题非常微妙。 我将尽量在本文中保持客观的态度,向各位展示汉堡菜单的问题所在,解决问题的方案,至于如何对待这种设计模式,我相信仁者见仁,智者见智。 一、问题所在 难于发现 效率低下 在某些平台下,和平台固有的导航设计模式有所冲突 无法一瞥既得 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,可以滑动标签栏。但是也有缺点,容错率较低,点击手势和滚动手势可能会冲突,可能会出现误操作。