被 「阉割」 的分享与应用间的墙

经常使用国内应用的读者应该不会对这个题目感到陌生 —— 很多国内大公司的应用都自己 「实现」 了一套 「独特」 的分享方式, 里面只有自己家的应用, 想分享给其他应用要么得费点儿心思找入口,  要么根本就不允许.

在我看来引起这种行为有四个原因: 流量内引构建闭环, 第三方玩家破坏规则, 国内用户习惯, 继承自 iOS 上的恶习.

首先是构建闭环. 这点很好理解, 假设我是腾讯新闻的 PM, 我当然希望用户在我的客户端看完新闻之后, 分享给朋友圈, 腾讯微博, QQ… 这样, 用户的分享行为就会带来其他腾讯应用的流量. 同理网易新闻等一些大厂旗下的应用也很容易朝着这条路走去, build walls not bridges. 题主例子中网易新闻客户端就把自家的易信放在了分享的最前面, 很明显是有引导流量的用意.

其次是第三方玩家破坏规则. 因为开放的分享接口, 所以你可以经常看到很多应用的分享按钮会带出长长的一串应用列表, 很多用户不一定会用到的应用也会出现, 这对用户会产生一定的心理压力. 更糟糕的是, 由于列表是默认按照拼音顺序排列的, 所以某些没节操没下限的国内应用在命名的时候玩往名字前面加空格或者奇怪的符号, 在后面加 “(推荐设为默认)” 这样的小手段来”引导”用户, 这不是什么好现象.

第三点和第二点比较难以分开, 国内的社交网络基本由几大巨头垄断, 而国内用户一般使用的社交网络也就被限制在比较大的那几个上, 像微博微信人人, 只要把这些覆盖到, 基本上就可以满足绝大多数用户的分享需求了, 同时也省得用户每次面对一大串应用名字不知所措, 何乐而不为?

最后是继承自 iOS 的恶习. 我们知道 iOS 一直没有一个完善的应用间通讯机制, 跨应用分享内容需要靠开发者自己搭建通道来实现 (说实话当我第一次看到 Reeder 的分享列表的时候还是震惊了), 所以 iOS 上往往只有几个分享选项. 而有些厂家则直接在 Android 上全盘照搬了这一点, 让 Android 应用也显示和 iOS 版本一样的分享选项, 理由五花八门, 常见的有”提供一致的跨平台体验”云云, 这里就不赘述了.

就我看来, 我最推荐的分享方式是像 Pocket 和 Timely 一样的:

3b0726be4bf7b45b8376c9d16ffc0568_r

希望国内这些公司还是早日抛弃成见, 不要再往 Android 里添加高墙了.

 

「数据? 那是什么? 能吃么? 好吃么?」

在近一年前, 腾讯终于扭扭捏捏地把微信改成了靠近 Android Design 的样子. 虽然外表有那么点儿 Android Design 的味道, 但设计却十分糟烂, 被无数用户吐槽. 结果到了八月, 微信又把 UI 改回了 iOS 风格.

我 100% 不认为腾讯因为 5.2 被用户唾骂而放弃 Android Design 是什么明智的决定, 与其因为碰了一次钉子就认为 “Android Design 不符合用户的使用习惯”, 不如好好研究 Android Design, 在遵循规范的前提下把微信做得更好.

很多人拿后台数据说话, 我就解释一下数据好了. 数据不是真理, 数据也可以被轻易的操作. 就拿这次微信来做例子:

对比对象一方是使用了很久 (从 Android 2.X 时代起微信就一直是 iOS 风格 UI), 成熟 (就算是在 iOS 上微信的 UI 也很难说是优秀, 所以这里用成熟) 且用户习惯 (如前述, 微信老用户都习惯了这套) 的 iOS-Like UI;

另一方是新推送的 (新年前才推送更新), 设计糟烂 (和 Android Design 貌合神离, 只是套了个皮, 完全没能体现对 Android Design 理解且存在大量违背 Android Design 设计之处) 且没有任何引导(一个全新设计拿到用户手中居然没有给任何的事先说明和引导教程) 的 Android Deisgn;

对比的结果可以说是显而易见的.

若 Android Design 一方同样是使用了很久, 设计经过深思熟虑且尽可能完全符合 Android Design (在这里姑且不谈超越) 且做出了合适的引导与教程, 你觉得数据会是什么样子的呢?

另外, 关于 “用户不知道也不会在意 Android Design” 这样的论点: 用户完全没必要知道什么规范, 用户当然也喜欢用脚投票, 而这并不妨碍开发方在这个规范的框架中做出优秀趁手的产品. 在微信这个事件上, “用户用脚投票选择 iOS UI” 这个现象只能说明 “微信的 Android Design 做得很烂“, 而不能说明 “Android Design 不适合微信”.

产品经理也当然没必要满嘴 Android Design 或者 Action Overflow, 但是如果他们不知道如何用好 Android Design 或者 Action Overflow, 就是他们的失职.

NovaDNG 2014 年度应用

又到了一年一度写年终总结的时候了… 这一年因为参加了工作的缘故, 锋客这边文章的更新频率大幅下降了, 所以这几天我会搬运一些知乎上的回答过来.

然后就是这篇文章的正题, Best of 2014!按照时间排序~

vivino 2

发布于一月份的 Vivino 是一款酒友应用, 能够识别酒标, 在线评酒和为你发现身边的酒庄/酒吧

2014-12-11 06.04.32_framed

发布于二月份的 Muzei 是一款动态壁纸, 在每天推送一张世界名画做壁纸之余又添加了模糊效果不至影响主屏使用, 藉由开放 API 的便利又有着数百款插件可供选择

2014-02-22 01.09.59_framed

同样发布于二月份的 Type Machine 是一款系统应用, 能够像时光机一般拯救因为意外丢失的文字

2014-03-21 00.37.29_framed

发布于三月份的 Link Bubble 是一款浏览器, 能够最大限度地利用等待载入的时间

(没有图)

同样发布于三月份的 Pixl Preview 是一款设计工具, 它能让设计师直接在 Android 手机上预览 Photoshop 上的设计稿

Mode

发布于四月份的 Google Camera 是一款相机, 能够拍摄球形全景与后期模糊照片, 界面极端简洁

2014-04-28 07.07.34_framed 2014-04-28 07.11.42_framed

同样发布于四月份的 Scene 和 CloudMagic 分别是一款操作新颖的图片浏览器与一款集成了非常多有趣功能的邮件客户端

2014-07-15 13.36.44_framed

发布于七月份的 Journey 是一款设计精良的日记应用, 在遵循了 Material Design 的同时提供了 Markdown 支持, 并且有 Web 端与 Chrome App

2014-12-26 04.55.46_framed

同样发布于七月份的 Unclouded 是一款设计精美的云盘管理器, 可以方便地查看与管理复数账号的 Google Drive, Dropbox, Box 与 OneDrive.

WT 03

发布于八月份的 Weather Timeline 是一款天气应用, 精致的动画与有趣的 「天气时光机」 功能带来了很多惊喜

2014-12-12 05.03.48_framed

发布于十二月的 Action Launcher 3 是一款桌面应用, 接近原生 Google Now Launcher 的外观与趁手的 Cover, Shutter 快捷操作让桌面的效率倍增

以上就是 NovaDNG 的 2014 年 Android App 精选集~

Android UI 设计工具 (Photoshop, Android 5.0, Nexus 4)

Material Design UI Toolkit for Nexus 4 版本 0.1 发布.

大概在十个月前, 我踏着 +Taylor Ling 走过的道路, 将他制作的 Android UI Design Kit 4.4 移植给 Nexus 4 使用. 一晃将近一年过去, Android 5.0 发布, Nexus 6 开始流行. 显然有很多人认为 Nexus 4 已经是落后的, 被遗忘的设备了.

但是 Nexus 4 作为我最喜欢的 Nexus 设备, 我显然希望 Nexus 4 在手中能够继续焕发活力, 更何况 Google 也依然在给 Nexus 4 推送最新的 Android. 于是早些时候我许下了诺言, 答应不论如何一定会把这套工具更新到 Android 5.0.

等到 Material Design 终于发布正式版的时候, 就到了我兑现这个诺言的时候了. 十个月前我还可以直接从 Taylor 的 Nexus 5 Toolkit 里搬运控件到 Nexus 4 上, 但是 Taylor 还没有做 5.0 的 Toolkit. 所以这个版本里所有的控件都是我自己画的.

于是就有了这么一套设计工具, 给和我一样怀旧的人.

Nexus 4 Toolkit Light Notification Center_framed Nexus 4 Toolkit Light Drawer_framed

Nexus 4 Toolkit Light Menu_framed Nexus 4 Toolkit Light Search_framed

Nexus 4 Toolkit Light Picker_framed about_framed

作为 0.1 版本自然是完成度很低, 目前只做了白色主题, 还缺失了很多在 Material Design 文档中尚未明确的控件. 有兴趣的同学就下载来用用吧. 欢迎补全.

下载地址: 度盘, Google Drive

导航抽屉到底归属于哪个层级?

这篇文章译自 +Juhani Lehtimäki 的博文 Navigation Drawer – Where Does it Belong in the View Hierarchy? 英文能力过关的同学可以直接去看原文~

事情本来是没那么复杂的…

Screen_Shot_2014-10-10_at_14_44_20

Android Design | Navigation Drawer

但是一切都变了. 我们常说 “先破而后立”, 当导航抽屉成为 Google 设计规范的一部分时, Google 明确告诉我们该这么做, 而且提供了可以让开发者直接调用的工具.

难道说 Google 在一开始的时候犯了个错误? 也许第一眼看上去这样做是对的, 但是从规范上看来确实是有些问题的.

所以现在规范改变了. Google 调整了这些东西. 在新的 Material Design 规范中, Navigation Drawer (现在被叫做 Side Nav, 侧边导航栏) 一跃来到了所有东西的顶端.

Screen Shot 2014-10-10 at 14.53.59

 

Material Design | Layout

我们现在又一次来到了变革的潮流中. Google 正在不断的改变自己与应用的设计, 与此同时很多变数也随着这些改变来到. 虽然我个人是很希望看到 Google 能统一他们使用侧边导航栏的方式并且对开发者们传递一个明确的信息…

Screen Shot 2014-10-10 at 11.46.56

也许你会问, “但是层级又有什么关系呢? 反正他们都 ‘能用’ 不是么?”

我认为这很重要, 事关重大. 这关系到用户是如何认知他们正在操控的物件. 如果抽屉式主要的导航方式, 那么它就是最不能出错的.

层级关系能让用户明白现在他正在操作的东西归属于应用的哪个部分.

2014-10-07_20_08_41_framed_2

上图展现了早先版本中抽屉所处的层级, 而新的 Photos 应用也遵循了这样的层级. 在我看来这么做有两个地方有很大问题:

  1. 首先, 抽屉在这个位置暗示了 Action Bar 在我导航到其他入口的时候不会有变化… 但是它却变了.
  2. 其次, 当抽屉展开时, Action Bar 上的按钮还是有效的, 但是它们的效果对象却是被遮住了一半 (在手机上被遮住更多) 的那些项目.

令人困惑, 不是吗?

 

2014-10-07_20_08_31_framed_2

最新版的 Google Hangouts 则采用了与 Tab 平齐的抽屉. 这给了用户 “当我从抽屉中导航到别处时, Tab 不会受到影响” 的暗示, 问题是, Tab 还是会受到影响的. 这种结构明显是错误的.

 

2014-10-07_20_08_22_framed_2

最新版的 Newsstand 中抽屉的表现是最接近 Material Design 规范中提到的 Google 应用了, 我认为这样的实现是很棒的, 而且是正确的. 当我从抽屉中导航的时候, 所有的内容都会改变, 包括 Action Bar. 这与现实的对应是最紧密的.

2014-10-10_09_08_58_framed

把 Drawer 设置为最高层级也可以很有效地避免发生上图这种视觉错误 (当 Action Bar 在滑动时隐藏了的时候).

好吧, 一切都在不断的变化, 而 Google 看起来也还没拿准主意. 我还是希望 Google 能早日找回一致性, 这样我们开发者和设计师才能跟进. 在那之前, 我们还是谨慎为妙.

当然, 改变熟悉的事物绝不是一件容易的事情. 我在 Google+ 上发起了一个投票希望看看大家的意见. 从结果看来改变是要花些时间的…

Screen Shot 2014-10-10 at 15.22.25

Splash Screen 是魔鬼, 不要在你的应用中加入这东西!

回国快一年了. 既然人在国内, 就免不了用到各式各样的国产应用. 而偏偏安卓应用的质量还大多不太能看, 问题数不胜数. 我写下这篇文章, 借此来谈谈在安卓应用上最常见的一个问题: Splash Screen.

 

实际上, Splash Screen 算是一件很有历史的东西了. 它的起源大概可以追溯到早年 PC 游戏和各类大型桌面软件上 —— 这些应用软件在启动时需要加载大量的资源, 又不能让用户产生软件死掉的感觉, 所以一个游戏或者软件加载的时候, 就会显示一个启动画面, 然后带上一个进度条什么的, 让用户知道这个软件是在加载中而不是死掉了 (当然, 还有一些软件确实是一面显示着启动画面, 一面死掉了…).

而在移动应用上采用 Splash Screen, 又可以追溯到 iPhone 刚刚发布的时候 —— 当然, 那个时候的“启动画面”还不是 Splash Screen. 最早的启动画面是一张仿画面造应用内容的画面, 或者干脆就是一张应用截图:

launch_image

(Image credit: Cyril Mottier)

iOS 应用利用这样的一张启动画面, 令用户认为应用已经载入, 与此同时在后台拉取应用数据与资源, 并稍后呈现给用户. 这样的方式取得了不错的效果, iOS 很快给大家留下了“启动速度快”的好印象. 毕竟早期 iPhone 宥于硬件条件限制, 很多应用从点击图标开始加载到可用状态几乎都要花上两三秒. 如果显示一个黑屏, 那确实是太令人不耐烦了. 而到了今天, 随着硬件机能的飞跃, iOS HIG 里已经不再建议开发者把应用截图作为启动画面, 而是建议开发者尽最大努力避免启动画面 (As much as possible, avoid displaying a splash screen or other startup experience).

实际上, 标准的 Android 应用的启动也是这么一个逻辑: 先载入应用的框架 (当然, 在 Android 上不是图片, 而是实打实的应用框架), 同时在后台拉取应用内容, 之后呈现给用户. 详见: Android Design in Action —— 初期体验. 上一个版本的知乎 Android 客户端就是这么做的, 体验也相当之不错.

smoothlaunch

(Image Credit: +Android Developers)

可以看到, 从最开始 Apple 就没打算让启动画面变成现在的 Splash Screen 的模样. 但是不知从什么时候开始, 越来越多的开发方开始打起了这块屏幕的歪心思. 开始的时候仅仅是在框架图片上加个公司 Logo 强化一下品牌什么的, 然后就不知不觉的变本加厉, 连框架图片都不要了, 直接变成了一张公司 Logo, 甚至是广告什么的…… 启动画面就这么变了味儿, 演化成了 Splash Screen.

目光转回安卓这里. 大家都应该知道, 在国内, 尤其是国内的大公司, 安卓从来都是 iOS 的附属品, iOS 方面怎么搞, 安卓方面也亦步亦趋跟着. 于是当大家在 iOS 应用上把启动画面搞成了各种公司 Logo 和广告之后, 安卓应用当然是逃不了一劫, 只能乖乖跟着改. 而且在国内, 他们甚至可以在 Splash Screen 上加入可以点击的链接……

那么, 为什么 Apple 和 Google 都把 Splash Screen 看作过街老鼠, 恨不得除之而后快呢?

首先最明显的一点就是, 现在的机能与应用配合, 已经不需要那么长的时间来加载应用资源了 (但是即使时至今日, 依然有一些应用由于优化差劲等原因, 依然需要耗费很多时间来启动, 比如, Path……). 在理想的状况下, 用户点开这个应用到应用已经完全准备就绪之间的时间, 应该是短于一秒甚至五百毫秒. 这个时候加入 Splash Screen, 只会拖慢应用的启动.

其次, 启动画面会打断用户的思考. 很多时候, 用户是在心里带着一个特定的任务打开应用的 (比如, 计算器.当然,也许知乎用户并不会经常带着任务打开这个应用吧). 此时如果应用给用户闪了一个带有其他信息的 Splash Screen, 有一定的几率会导致用户一瞬间忘记掉自己原先的任务 —— 在先前的一篇文章里, 我怒斥了 Smartisan ROM 计算器那极为糟糕的设计, 就是因为它的界面设计会让用户在启动它的瞬间看到视觉错觉而导致忘记自己原先的任务. 对于计算器这样一个应用, 让用户忘记自己打开它是为了什么, 简直是不可饶恕的错误. 同理, Splash Screen 的加入也让很多其他的应用犯下了这样的错误.

而在 Android 上, 这个问题会变得更为严重 —— Android 作为一个多任务系统, 非常经常需要在应用之间跳转. 当用户心里带着任务从另一个应用跳转到这个带有 Splash Screen 的应用时, 他有可能会因为被 Splash Screen 吸引而一时忘掉了自己原先进入这个应用的目的, 严重的阻碍了跨应用交互体验.另外, 由于多任务的特性, 应用往往会有很多个不同的入口 —— 有的时候是直接进入主屏幕, 有的时候是进入某个子层级.有的应用更因为加入 Splash Screen 而打断了导航流程, 体验极其糟糕.

若是要在应用中加入 Splash Screen, 就必然需要额外的资源. 很多国内应用的 Splash Screen 是一张图片, 而在 Android 屏幕分辨率如此碎片化的今天, 准备 Splash Screen 使用的图片无疑会占用很多空间. 更令人感到哭笑不得的是, 有些国产应用的启动器没有为不同的屏幕分辨率/比例进行优化, 在 Nexus 4, 魅族 MX 2/3 这样非主流/标准分辨率的机器上显示的就是一张拉伸过的图片, 丑陋之极.

不管你的 Logo 有多好看, 都没必要专门用一个 Splash Screen 来展示 —— Android 标准 Action Bar 上已经留了一个位置给应用的 Logo (Oops, 如果这个应用采用的是 iOS UI 的话, 那 Top Bar 上确实是没有放 Logo 的地方呢). 更何况, 想要呈示应用品牌的话还有很多更好的办法, 为什么非要选择 Splash Screen 这种最不讨喜的办法呢?

更重要的是, 不管你的 Splash Screen 做得多精美好看, 它都是在浪费用户的时间.而当 Apple 最早提出启动画面得概念时, 是为了让用户觉得应用启动迅速, 响应灵敏. 而这个出于好意的决定今天却被各个开发商用来无端浪费用户的时间. 作为一个移动应用, 内容和功能才是第一要义, 而应用多显示一毫秒 Splash Screen, 就是多浪费了无数用户一毫秒时间. Android 的设计原则中, 特别强调了 Simplified My Life 以及 Make important things fast, 不就是为了避免用户的时间被无端浪费? 开发方没有任何的理由给用户增加无谓的等待. 人们已经在生活中等待了足够多的了: 等地铁, 等红灯, 排队, 等待网页内容加载, 等待下载, 化妆/等待伴侣化妆…… 为什么还要再让他们在应用里浪费时间呢? 更何况, 智能手机本就是为了减少我们的等待而生的.

这篇文章的部分观点整理自 +Cyril Mottier 的博客 Splash Screens Are Evil, Don’t Use Them! 与 +Roman Nurik 的博客 A mobile design anecdote on perceived latency and touch feedback — Fast can sometimes feel slow.

正确的使用 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》