侧拉菜单——弊大于利的导航模式.pdf

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