正确的使用 Navigation Drawer

译注: 这篇文章来自博客 Android UI/UX, 作者为 Taylor Ling.

这篇文章在现在看来恐怕很快便会显得不合时宜了, 因为 Google 刚刚更新了他们的 Google+ 应用, 采用了新的导航方式并抛弃了 navigation drawer. 当然, 我是丝毫不认为 Drawer 会很快淡出我们视线的.

在最近到来的 Gmail 更新里, Google 终于把它的 drawer 形式进行了统一 (比如在低层级界面中也可以通过边缘滑动唤出 drawer, 而且也把设置/帮助/反馈等操作放进了里面), 我个人是相当乐于看到这样的情况的, 因为有了这样的事实基础, 我们就可以更好的谈论谈论这个设计模式的一致性 (我认为 Google+ 和 YouTube 迟早也会改成这样的). (译注: 同感, 现在的 Google+ 看起来更像是个过渡版本) 我假设你已经看过这两篇关于 navigation drawer 是如何降低了用户活跃度为什么以及如何避免汉堡菜单的文章 (如果你比较关注和 UI/UX 相关的新闻的话), 如果没看过的话, 建议你看一下 —— 这两篇文章都很有意思. 在 Zeebox 的案例 (文章一) 中, 我不太能理解为什么他们会决定采用 navigation drawer —— 显而易见的是这个应用并不需要采用 navigation drawer, 如果让我来设计的话我也许会采用 QuickReturnTabs (就像现在的 Google Play Newsstand 中那样), 来适当的增加屏幕可用空间 —— 尽管如此, 还是感谢他们提供了一个算是有参考价值的 A/B 测试. 这两篇文章 (以及我相信还有很多我没看到的) 都想要传达这样的观点: navigation drawer 是一个糟糕的设计模式, 请务必不惜一切代价回避它. 但是我在这儿显然是要唱个反调: 在 Android Design 的语境中, 你应该放心的使用它 —— 但是仅在真的有必要且经过仔细思量的前提下.

理解 Android 中的 Navigation Drawer

在 iOS, 尤其是在 iOS 7 中, 侧边菜单确实是与导航元素 (尤指返回键) 和侧滑返回操作 (但这个操作并不是真正的全局通用操作, 如果我记错了的话请不吝指正) 冲突, 但是这和 Android 上的情况完全不同. Android 上的 navigation drawer 要复杂得多, 边缘侧滑手势被保留用于从任意一个导航层级接入 navigation drawer (当然我知道在这个地方可见性是一个问题), 这保证了即使你在应用的深处也能令顶层导航有很好的可访问性. 在 Luis Abreu 的文章中那最关键的限制, 即平台导航模式冲突, 在 Android 上便不复存在了 (当然, 我知道他说的是 iOS 7).

信息结构 (Information Architecture, IA) 调整

对于 Luis Abreu 提出的, 关于当你采用 navigation drawer 时应当作出信息结构调整的观点, 我还是非常认同的 —— Navigation drawer 并不是一个能解决所有导航需求的万用解. 无论何时, 站在更高的角度来重新思考应用结构, 以便找到如何通过移除那些无益于展现内容的不必要的层级/信息以达到减少导航深度的方法, 都是件好事: 在 Android Design 中, 有一个写得不错的应用结构推荐.

姿势正确

example

如果在经过了仔细的考虑之后依然觉得有必要使用 navigation drawer 作为顶级导航方式, 那么请, 并且以正确的姿势用. 并不是说我限制你的发挥, 而是因为作为一个需要被大量使用的交互方式, 它最好还是保持在设计规范的约束之内以维持一致性, 让用户觉得熟悉与可靠. 我们总是希望用户能”一次学习, 终身使用”, 尤其是站在整个操作系统的角度上来看 —— 我是不太想说这样的话, 但是每一个 Android 开发者与设计师都有责任在建立和维持 (注) 一致性这方面贡献自己的力量, 这样用户们就不必面对支离破碎的交互方式愁眉不展了. 用户越快的掌握如何使用一个应用并做到他们想做的事情, 他们就越满意.

注: 我知道时至今日有些 Google 自家应用依然没能与最新的 navigation drawer 设计模式保持一致, 但是我很确定他们正在改进. 别忘了 navigation drawer 花了多长的时间才进化为今天这个模样的. 早在 2012 年我就已经写过一篇关于导航抽屉的文章了!

“眼不见为净”

在 Anthony Rose 的关于 navigation drawer 的文章和在下面展示的来自 Luke Weoblewski 的推文中, 他们试图告诉我们, 当导航方式不是那么直观的时候, 用户的参与度便会降低 (尽管我不是很能确定在 Luke 的图表中到底是以什么作为参数的).

Bk8y16lCYAEGORy @lukew: 直观总是赢家.

在一些情况下确实是这样的. 这个统计报告看起来非常唬人 —— 但我不认为我们看到了这些案例的全貌. 用户参与度降低意味着什么? 是意味着用户们不再在应用内探索了, 还是意味着第一屏 (也就是主界面) 对用户而言已经足够了? 会不会是意味着用户们在应用内 (因为干扰减少了) 以更快的速度与更少的操作完成了他们想要做的事情呢? 如果我的应用能够帮助用户提高效率, 我会把这样的结果视为一个成就 —— 毕竟这很大程度上意味着我的应用能让用户更快的达成目的. 当然, 我也非常赞成”眼不见为净”的设计理念, 但是这并不意味着我们必须要把所有的东西都暴露给用户, 毕竟每个 UI 元素在交互中都扮演着不同的角色, 他们都有着独一无二的重要性. 所以当你又一次需要用到 navigation drawer 的时候, 确定你是真的需要它 —— 你看, 新版的 Google+ 应用就证明了有时候, navigation drawer 也并不是唯一的选项 (译注).

延伸阅读: 由饭本前设计师 +Stephen Day 写的《从 Google+ 更新说说 Navigation Drawer》

小米平板的变数

MiPad

昨天, 作为中国 Android 界影响力最大厂商之一的小米推出了自己的平板. 这台小米平板有着亲民的价格, 看起来高得吓人的配置, 以及依然不知道什么时候能买到的悬念. 另外一个亮点是, 小米平板采用了和 iPad mini with Retina display 一样的屏幕分辨率, 而小米甚至直接宣称这是为了“方便移植 iOS 应用与游戏”.

那么, 小米平板能为颓靡的中国 Android 平板应用注入一剂兴奋剂, 带来正向的促进吗?

这里看法比较悲观: 小米平板也许并不会带动大量开发者适配平板应用, 而最终会发展成一个新的”小米平板生态”.

小米平板最大的卖点, 从官方宣传来看应该是阅读. 小米平板的官方网站专门用了一整个页面来展示其优秀的阅读器和阅读效果. 甚至连 MIUI 在功能上的优化等都是一笔带过 —— MIUI 页仅仅是提及了平板适配系统应用 (所谓适配无非是拉大了应用并使内容充满屏幕, 也并没有应用到 Android 标准大屏解决方案的多分栏布局等) —— 且依然花了很大篇幅渲染优异的阅读体验, 而办公功能更是只用了一张图片草草说明. 而实际上, 小米平板作为一个消费内容的娱乐平板, 本身已经自带了足够多的内容资源了 —— 阅读方面有前面大肆渲染的多看, 音乐和影视都有自己的资源 (小米平板宣传页), 而这些资源才是小米的盈利重点. 可以说, 小米平板对第三方应用的需求其实很小, 只要开发者能适配游戏就可以满足作为一个娱乐板的所有需求.

而游戏方面, 小米采用了和 iPad 一样的分辨率, 暗示 (简直是明示) 游戏开发者”之前在 iPad 上用的素材只要原封不动搬过来用就可以了”, 一段时间内, 应该会有一些游戏开发商愿意针对它进行适配.

实际上, 这其中还有很多变数. 比如普及度. 如果没记错的话, 今天发布会说的是”六月中旬公测”, 结合小米一贯的饥饿营销 (或者说卖期货) 手段, 以及 Tegra K1 的铺货时间, 也许等到年底这台平板都不能得到很好的普及. 更何况在中国, 连三星 Galaxy Tab Pro 等大厂产品都没能引起广大应用开发商的重视, 可以认为大部分开发者认为平板用户很难对他们产生价值, 由此可以推断, 一个等到年底都不能经常在街上看到的平板不太可能让他们积极的去适配.

不过还有另一个变数, 那就是米粉. 俗话说会哭的孩子有奶喝, 会闹的粉丝有应用适配. 先前魅族 Smart Bar 就是个活生生的例子, 这家企业用微乎其微的市场占有率 (存疑) 逼迫很多应用不得不为其适配 Smart Bar. 魅族用户齐心协力尚能做到到这样, 小米依靠其更多 (也更会吼) 的用户能做到些什么, 还是有些值得期待的.

 

另外还有一个值得担心的地方就是, 如果有大量未经重新设计就”搬运”到 Android 平板上的 iOS 应用, 又会对国内的 Android 平板生态带来什么影响? 答案无非就是让一些国产应用在平板上回到三年前手机应用的起点罢了 —— 至少有是有了. 只不过这一次和三年前的手机恐怕会有点不一样. 如果小米平板真的普及了, 而且能一统国内 Android 平板界, 那么恐怕到那时再试图推行 Android Design 的难度就不是一般大了. 更重要的是, 如果这一天真的到来了, 甚至没有说服开发者在平板上不采用 iOS 设计的理由.

另外, 还有一种可能就是, 很多应用不是将应用本身进行平板适配, 而是完全照搬 iOS 的方式出一个平板专用应用 (就像在 Android 2.3 时代一样). 这对任何人都是没有好处的, 但是很难说服开发者不这么做 (在小米平板统一国内 Android 平板界的前提下). 而如果要直接做 Responsive Design, 也不太可能做到手机模式和平板模式两套 UI 风格. 如果开发方倾向于直接把手机应用做 Responsive, 那么对大家来说都是大好事, 如果不是, 那对小米来说是好事, 对其他人迟早会造成问题的.

最后说句题外话, 如果有开发者愿意为 Android 平板 (而不是只为小米平板) 适配自己的应用, 请参看: Building a Dynamic UI with FragmentsMulti-pane LayoutsAndroid Design in Action —— 编与集.