抽屉式导航怎么用？这4种场景教你正确的设计姿势.pdf

抽屉式导航怎么用？这 4 种场景教你正确的设计姿势 2012 年， path 首先使用了汉堡菜单作为产品的导航方式来替代原本的标签页的导航方式。一时引起 了各大厂商的跟风， Youtube 、facebook 等App 都纷纷把自己的导航改成了抽屉式导航。但由于没 有统一的规范，各个产品的抽屉导航设计也各不相同，为了控制 Android 平台日益混乱的抽屉交互 方式， 2013 Google I/O 大会之后， Google 将 Navigation Drawer 纳入了 Android Design 规范当中， 随后大量应用开始采用这种交互模式【 1 】。 不过慢慢的，包括 youtube 和facebook 在内的很多 app 都将抽屉式导航换回了原来的标签页导航， 从此，对于抽屉式导航的争辩就一直没有断过。并且慢慢的，对于抽屉式导航的批评渐渐多于肯 定【 2 】。我摘取其中的两则批评如下。 …上图的 APP 将选项卡（ tab row ）变成抽屉式导航菜单（ drawer menu ），用户在相应功 能间的切换率急剧下降。 …很多用户还没有建立起相应的心理模型（尤其是抽屉式或者汉堡 包菜单）尽量将 APP 的核心功能放在用户可以看得到地方。 —— 能露出来， 就别藏着 触摸操作中，手势永远要比点击优先级低。现代触摸操作习惯毕竟只流行了几年，然而传 统 PC 上的操作习惯已经实行了将近 20 年。所以通过滑动来切换 Tab 不会比点击切换来的直观 。 —— 石头们 总结一下，对于抽屉式导航的批评主要有如下几点： 1. 可见性不好： 2. 操作复杂。 抽屉式导航的切换可以直接点击，如果 Tab 放在上方可以直接滑动切换。但是抽屉式 导航的切换就要先呼出侧边栏，然后再点击，相对比而言，操作更加繁琐。 3. 与现有的交互方式冲突。 抽屉式导航可以从屏幕左边缘向右滑动唤出，与 iOS 的后退操作冲突。 但是这本来就是 Android 的设计规范，并不一定适用于 iOS ，所以我觉得的这个批评不成立。 但是，正如那句老话 垃圾是放错地方的资源“ ”，我始终相信，没有不好的交互设计，只有不适合产 品使用场景的交互设计。所以抽屉式导航也是有它的正确使用方法的。 首先关于这个入口的问题，我觉得暂时是无解的，但是这是可以通过长期的用户教育来实现的。正 如现在的开关键（一个圆圈加一条杠），这个设计其实并不能一目了然地让人知道这是开关键，但 是经过长期的使用，现在大部分人都会知道这是开关键。所以，这个问题就只能交给时间来解决了 。 但是除此之外，上面的批评 1，2总结一下就是切换麻烦（批评 3不太站得住脚）。只是，如果产品 的导航不需要频繁切换呢？如果有其他的切换入口呢？那么问题就迎刃而解了。那么有没有产品是 这样的呢？答案是：当然有。下面我就结合一些例子来讲讲抽屉式导航的正确使用方式。 1. 导航模块有主次 抽屉式导航的使用场景首先一点是：导航的模块是有主次之分的。相对比于常用的标签式导航而言 ，抽屉式导航的模块之间主次区分更加明显。 基于以上三点，标签式导航模块之间的区分不是特别大。 但是对于抽屉式导航而言，以上三点都不成立。所以，相对而言，抽屉式导航的第一个模块的重要 程度要远远大于其他的模块。也就是说，当不同导航模块之间存在明显的主次之分时，才可以考虑 使用抽屉式导航。 举个例子，豆瓣一刻的导航模块如下： 一刻的导航 如上图，因为豆瓣一刻的资讯都是严格按照每天为单位的，一刻的目的也是希望你当天阅读完当天 的内容。所以，一刻的核心使用场景是当日事当日毕，当天的内容（即 今日一刻“ ”模块）的优先级 远远大于其他模块。其他模块是为次要场景设计的，即使渗透率不高，对于产品的影响也不大。 2 、次要模块可以有快捷入口 对于次要的模块，我们并不需要严格保证模块的渗透率。但是，假如我们可以提高次要模块的渗 透率，又何乐而不为呢？既然抽屉式导航的可见性不高，操作繁琐，那为什么不可以另辟蹊径？设 置一个可以见高，操作便捷的