正确的使用 Navigation Drawer.docxVIP

2014 年五月 21 日由?NovaDNG?发布 | 类别:?Android Design 研究会,?译文?| Tags:?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 中, 有一个写得不错的应用结构推荐.姿势正确如果在经过了仔细的考虑之后依然觉得有必要使用 navigation drawer 作为顶级导航方式, 那么请用, 并且以正确的姿势用. 并不是说我限制你的发挥, 而是因为作为一个需要被大量使用的交互方式, 它最好还是保持在设计规范的约束之内以维持一致性, 让用户觉得熟悉与可靠. 我们总是希望用户能”一次学习, 终身使用”, 尤其是站在整个操作系统的角度上来看 —— 我是不太想说这样的话, 但是每一个 Android 开发者与设计师都有责任在建立和维持 (注) 一致性这方面贡献自己的力量, 这样用户们就不必面对支离破碎的交互方式愁眉不展了. 用户越快的掌握如何使用一个应用并做到他们想做的事情, 他们就越满意.注: 我知道时至今日有些 Google 自家应用依然没能与最新的 navigation drawer 设计模式保持一致, 但是我很确定他们正在改进. 别忘了 navigation drawer 花了多长的时间才进化为今天这个模样的. 早在 2012 年我就已经写过一篇关于导航抽屉的文章了!