Material Design in Action — 猿题库

猿题库是一款免费的手机做题软件,在中学学生中拥有一定的人气。

猿题库很早之前就发布了 Android 版本的客户端,但猿题库的联合创始人,郭常圳先生,并不认同 Android Design (或者现在的 Material Design),而且认为应用程序的设计规范,应当由开发商来决定。

然而当我试用猿题库的时候发现,这个应用对其进行 Material Design 的适配,其实并不困难。因此就有了对其进行重新设计的念头。

由于郭先生对 Android / Material Design 以及对跨平台应用遵守规范的误解,我会在展示作品之前,先简单说一说我心目中的跨平台应用应该是如何设计的。

跨平台应用应该怎么做?

现今,绝大部分的移动互联网应用,都会选择开发双平台(iOS 和 Android)或多平台的跨平台客户端。

iOS 的情况比较简单,因为绝大多数公司都会遵循 iOS 的设计规范,很少出现把别的平台的设计风格“搬”到 iOS 上的情况。然而 Android 就要复杂得多了。

Android 在 4.0 之前是没有一个统一标准的规范的,默认控件也比较丑陋,于是开发商们就“怎么方便怎么来”,基本上都把 iOS 风格的控件和交互直接照搬到 Android 上。

情况在 4.0 之后有了改观,Google 为 Android 打造了更加美观的 Holo Theme ,并且提出了 Android Design 规范,从此 Android 应用的设计风格开始进入了新的时代。

然而现在的 Android 应用并没有呈现出“大一统”的状态,而是一个“分水岭”的状态。一边是大部分国外的公司和开发者的应用,经过几个 Android 版本的迭代之后,绝大部分已经遵循了 Android Design,同时有些应用已经开始遵循 Material Design 以期在最新的 Android 5.0 Lollipop 中拥有更好的表现;另一边是大部分国内公司和开发者的应用,纵使 Android Design 已经推出了多年,他们仍然视而不见,继续使用 iOS 的那一套设计风格。

这其中也有一些例外,微信在 5.2 版本中做了一个不太好的尝试,开始试图让微信遵循 Android Design 规范。但这次尝试十分短暂,在受到了用户的批评后,他们马上在 5.4 版本里换回了 iOS 风格。

因此,有人提出,用户不需要跨平台应用针对不同平台做不同的设计。这个观点是对的吗?个人认为,不对。

虽然使用 iOS 风格的设计在 Android 上“又不是不能用”,但如果你想为自己的应用从观感,使用体验等各个层次来一个全面的提升,还是应该试着去遵守平台的规范。

更不用说 Material Design 在 Android 5.0 上提供了非同寻常的使用体验,极具个性的动画效果,能为应用带来优秀的视觉享受。

Weibos

微博官方客户端(iOS 风格)和 Blacklight 微博客户端(Material Design 风格)在 Android 5.0 上运行效果的对比

所以,用户需要,有必要,有权利在不同的平台上用上遵循规范设计,体验更好的应用。

我看跨平台应用——“求同 存异”

前面提到了,微信曾经在 5.2 版本里短暂地尝试了一下 Android Design ,结果在 5.4 中,又被用户“骂回去”了。

微信这么做对吗?当然不对。新事物总是需要学习的,微信应该做的是在下一个版本当中对 5.3 的风格继续改进,而不是当缩头乌龟。

微信 5.2 的设计为什么会被用户骂?很简单,UI 大改,用户自然需要学习,而之前的 iOS 版本设计风格的 UI 和新的 Android Design UI 之间,几乎毫无瓜葛,用户一时摸不着头脑,于是就开始骂娘了。

这是 Android Design 的错吗?当然不是!事实上,微信在 iOS 和 Android 上的设计,都只能算是非常一般而已。在 5.2 版本上的所谓 Android Design 风格还十分简陋,都有很大的提升空间。

最主要的是,微信在不同平台上的设计,割裂感太大了。

Android and iOS

What the f…?

如上图所示,iOS 版本和 Android 版本(5.3)的微信,简直可以说是两个应用。如果用户从 iOS 版本切换到 Android 上,肯定会产生不适应感,而这是优秀的跨平台应用不应该做的。

在我看来,优秀的跨平台应用必然共有一个特征——求同存异。

以下是一些优秀的跨平台应用(图片来自 NovaDNG):

between 2

Duolingo 3

Instapaper 2

RB1

 

从上面的应用展示中,大家可以看出这些应用让用户能明确体验到应用在不同平台间的差别,又不至于产生不适应感,学习成本也较小。同时,在界面设计上都遵循了相应的平台规范。

这,就是“求同存异”的内涵。用户在使用这些应用的时候,没有那种硬生生的割裂感,只需要很短的时间就能适应在新平台上的操作。

所以,所谓“分裂”其实只是因为应用自己做得不够好,而不是平台规范的错。同样,如果应用做得足够好,用户也不需要太久时间就能适应新的平台设计。

Talk is cheap,show me the…

OK.

其实在我试用猿题库的时候就发现了一个事实——这款应用看上去一副 iOS 样,其实交互上已经很接近 Android Design 了,最典型的就是那个 Drawer 。

所以我觉得猿题库是款很可惜的 App ,明明只要付出一点点努力,就可以在 Android 平台上变得更好…

于是我自己动手制作了一套猿题库重新设计的效果图,仅供参考。这只是一种尝试,我相信,肯定还会有其他比我更好的实现方法,关键是肯不肯做。

1.登录画面

vs1

状态栏和导航栏都进行了 Translucent 化,为的是更有冲击力的第一观感(好像听上去和 Nova 差不多…)。稍微更改了一下 Logo 和按钮的布局,原来的按钮样式被换成了 Boarderless Button.

这里偷个懒,直接放上新用户的引导界面,省去登录界面了。

2.引导界面

vs3

vs2
…到了这里,大家应该明白我前面“可惜”的意味了吧?我只是做了很小的改动(换成标准的 App Bar 和控件,列表改成标准的两栏布局,去掉了那个箭头,仅此而已),整个界面就已经很 “Materialized” 了…所以我这里改动不多。接下来就是主界面了。

3.主界面

vs4

原版上方的概览画面面简直就是硬伤,排版在我看来非常混乱。所以在这次重设计中,我试着用卡片的方式承载这部分内容,同时把内容尽量规整地向中间靠拢。至于底部的 List ,我更新了样式,原来的”+”图标改成了现在的”Expand More”图标,写题的图标也做了小许改进。

vs4.1

Drawer 在原版就已经出现了,于是我只对 Drawer 样式做了修改,使其更贴近 Material Design 的 Drawer 样式。

vs4.2

原来右上方的“更多”按钮被我更换成了“More”,新页面展示也变成了 Drop Down Menu.

4.写题界面

vs5

这个界面可以说改动也很大。首先是 App Bar 上的 Actions 都去了他们该去的位置(计时器的字体也做了修改,并且加粗处理)。至于底部的 Drawer (暂时找不出更好的方式描述这个模块),我把原来的拖动区域整合到了 Drawer 里,以使整个界面看上去更加简洁。选题界面的标题,内容和按钮位置也进行了微调。

vs5.5

练习报告界面。还是之前在主界面那里的问题。排版混乱。于是我按照之前主界面的思路,重新排了版,将原来底部的按钮换成了 Flat buttons.

写在最后

相信大家都发现了,我重制的界面其实不多,一部分原因是我懒(,另一部分原因是,这个应用需要做的绝大部分都是控件的修改和细节上的优化,因此不需要大幅度地推翻重建,只需要完成一两个模块做为演示,我相信就能带来一定的启发。

除此之外,猿题库还有一些问题需要改进,例如去掉 Splash Screen 等等。但不可否认的是,这款应用对中学生来说,帮助是很大的。希望开发团队能够认真考虑一下,拿出一个更好的 Android 版本。

写在最后的最后

这是我第一次对 Android 应用做较为系统的界面重制,在这里要再再再再次感谢 NovaDNG ,没有他的影响,我现在也不会往 Designer 的方向发展。

祝大家在 2015 年一切顺利~

Android Design in Action —— 十大导航错误

slides.001

大家好, 这里是 2014 年第一期正式的 ADiA 教程. 在上一次的设计错误文章里, 我们已经简略的提过了一下导航设计上的错误, 这一次, 我们就这个话题展开, 指出一些大家在设计应用导航时经常被犯下的错误以便警示大家.

 slides.002

十大导航设计”反模式”, Android 开发者联系团队为你用心呈现~ 希望大家看 (乖) 得 (乖) 开 (中) 心 (枪)~

 

1. 将导航项放在 Action Overflow 里

slides.003

我应该已经不止一次在各种 App 上看到有人把导航项放在 Action Overflow 中了. 经常被放进 Action Overflow 的导航有”主页 (脑子一定是被保险柜夹了)”, “商店 (有时其实可以理解)”, “我的信息 (微信, twitter 中枪)”, 甚至一些分类. 但是 Action Overflow 真的不是导航项该去的地方, 别忘了这地方是 Action Overflow, 是用来放操作的. 还有另一个很重要的原因是, 在很多有着 Menu 按钮的手机上, 应用中是不会显示 Action Overflow 的, 他们得被 Menu 键唤出, 可见性太低了, 而且关于 Menu 键还有一大堆问题 (这里就不展开了).

还有一点很重要的就是, 在现在的 Android 上, 界面 UI 已经逐渐形成了一个规律 —— 导航靠左, 操作靠右. 如果你硬是要把导航放进 Action Overflow, 无形中也会违背这个规律.

 

2. 错误的导航层级

slides.004

这个错误也是颇为常见的. 在 Android 中我们有很多常见的导航方式, 比如 Tabs, Spinners 和 Drawer. 这些导航方式当然是可以搭配着使用的, 但是当你搭配使用这些导航方式的时候, 请注意他们之间的层级关系. 当你规划你的导航层级的时候, 一般情况下是要构造一个树状结构, 在一个层级下有其他的子层级, 以此类推. 在 Android 中, 不同层级一般对应着不同的导航方式. 而错误的用法是, 比如上图中那样的, 用 Tab 作为最高导航层, Spinners 作为次层, 而 Drawer 作为最次层. 在 Android 上, 这三个导航方式对应的层级是遵循着比较严格的规定的.

slides.005

上图呢才是一般情况下的正确做法. 通常情况下, Drawer (如果有的话) 代表着最高的导航层级, 然后则是 Spinners, 再次是 Tabs. 如果你有超过三级的导航层级, 我们强烈建议你把最顶端的几个都放在 Drawer 中 (只有 Drawer 能容纳超过一个导航层级, 因为 Drawer 中的项目能够以合理的方式展开), 然后把剩下两个层级分配各 Spinners 和 Tabs. 当然, 实际上作为一个移动应用, 简化层级也是非常重要的, 我们强烈的不推荐你在应用中采用非常深的导航层级, 这只会让用户感到困惑.

还有一点需要注意的是, 虽然在上面的示意图中 Spinner 和 Drawer 共存而且看起来 Spinner 在 Action Bar 上 (Drawer 实际上在 Action Bar 之下), 但是在实际应用中, 当用户划出 Drawer 的时候, 你应该让 Drawer 渐变成另一副模样 —— 只留下在应用中全局通用的操作, 比如搜索, 隐去其他的东西, 比如 Spinners, 换成 App 的名字. 这样的话就不会产生导航层级上的困惑了.

另外, 关于 Drawer, 我们还有另一期专门介绍它的 ADiA: Android Design 趋势——Navigation Drawer.

 

3. 不能滑动切换的 Tabs.

slides.006

在 Android 中, Tab 几乎是绑定了横向滑动的操作. 用户对 Tabs 的期望就是他们可以被滑动. 如果你在页面上采用了 paginate (ViewPager) 内容, 那么内容上的滑动操作就会和 Tabs 的全局滑动产生混淆. 当然, 如果页面中只有一小部分是可以滑动的内容 —— 比如一个非全屏的图片浏览, 那么这么做是完全没问题的, 只要不与 Tabs 本身的滑动手势冲突即可.

slides.007

正确的做法很简单, 只要把横向的 ViewPager 改为纵向就行了. 当然, 如果你有其他的解决方案也很好, 只要规避与导航的手势冲突就可以了.  

 

4.  深层/顽固的 Tabs

slides.008

什么叫做”深层”的 Tabs? 要解释深层, 一般来讲我们用”浅层”来做对比. 在 Android 上, Tabs 应该是浅的. 你用 Tabs 来作为视图更变, 或者分类切换之用, 而不应该在 Tabs 之内再有层级和历史. 通常情况下, Tabs 只应该在导航界面出现. 在上图的例子中, 用户点击一个项目, 理应打开一个全新的页面, 而不是刷新 Tabs 下的内容. 这种持续出现的 Tab 就是我们所说的深层 Tabs, 或者说在 Tabs 之内有历史.

之所以不这么做的原因是, 当你离开了这个 Tab, 比如说滑动到了另一个 Tab 上的时候, 你就把这个 Tab 置于了一种尴尬的境地 —— 现在这个 Tab (对于用户而言不可见) 应该显示什么呢? 当用户从另一个 Tab 回到这个 Tab (无论是点击还是滑动) 时, 他应该保持原来的样子 (显示内容) 呢, 还是显示列表? 在这种情况下, 用户会很容易的感到困惑. 为了避免这种尴尬, 我们建议 Tabs 最好做得浅一些.

另外, 若你的 Tabs 坚持不变的话, 很大程度会影响到 Back 的作用. 当用户切换到不同的 Tab 并且在这个 Tab 中做了一些操作之后, Back 的作用就会变得不甚明确. 如果你非得在同一个视图内显示新内容, 那么我们建议你采用 Drawer, Drawer 才是为全局内容切换而生的.

slides.009

上图显示的才是正确的做法, 打开一个新的, 没有 Tabs, 有 Up 的界面, 而不是继续显示 Tabs.

 

5. 溯回 (反向遍历) Tabs

slides.010

前面说的 Tabs 不应该深层, 同样也提到了 Tabs 不应该包含历史. 什么叫做不因该包含历史呢? 就是指, 你在 Tabs 的操作不能被 Back 溯回. 同一个导航层级是不应该被溯回的.

 

6. 溯回 (反向遍历) Drawer

slides.011

和 Tabs 一样, Drawer 中的导航项也不应该被溯回. 理由同上. 当用户在不同的导航项中切换时, 你应该重置任务状态. 在不同的导航项目中切换就像是切换到不同的应用中一样 (比如说, 在 Google+ 中, Photos Tab 根本就是另一个应用… ). 在用户按下 Back 的时候, 你应该退出应用, 或者回到应用的主界面 —— 这里的主界面是指那个自然状态下的初始界面, 一个你特别希望用户 (同时用户也特别期待能够容易地) 回到的地方.

 

7. 深层的 Navigation Drawer

slides.012

前文说过, 一个移动应用不应该有复杂的结构. 如果你需要特别多的导航层级, 那么说明你真正应该做的其实是简化你的应用结构. Drawer 存在的意义是提供一个稳定的导航枢纽, 让用户不需要记住自己在什么地方, 他只要打开 Drawer 就能自然的明白一切. 但是, 如果在 Drawer 里面弹出了一个次级 Drawer 会把很多人逼疯.

Drawer 虽然有能力承载多个导航层级, 但是正确的做法不是这样的.

slides.013

当你需要在 Drawer 中放入多个导航层级的时候, 不应该以新弹出一个 Drawer 的方式, 而是应该以展开/折叠的方式呈现这个子层级. 展开和折叠并不会造成整个控件的剧变, 同时能展示给用户少多一些的项目. 关于 Drawer 上的导航项以及触摸区域的设置, 在 Android Design 中另有提及.

slides.014 - 2

如果你的导航层级真的很深, 你可以单独做出一个次级导航页 展示所有的导航项目. 比如说, 在 Play Music 中, 曲库下的 Tabs (艺人, 专辑, 风格, 曲目) 其实完全可以做成 Drawer 中的次级导航项, 但是把它们分散到 Tabs 中能够更好的优化导航. (上图这样则是有点类似腹肌式的导航方式. 当然, 最好不要只是在上面写着文字, 可以往里面添加点图片啊, 内容预览什么的)

 

8. 错误的 Drawer 转场

我们在这里说转场的时候, 是意味着过渡动画和一个有着 Drawer 的界面和没有 Drawer 的界面之间的切换. 下面两个错误都和这个转场有关.

slides.015

当用户打开 Drawer, 按下其中一个项目之后, 他不应该被带去一个有着 Up 箭头的新界面. 所有在 Drawer 中呈现的导航项, 都应该在其界面中显示 Drawer 指示 (比如说, “汉堡”). 而且, 当用户通过 Drawer 从其中一个导航项进入另一个导航项,  他不应该看到标准的视图切换动画 (渐变 + 放大, 常见于进入新界面/新活动时), 而应该是一个细致而迅速的渐隐 + 渐显动画, 伴随着 Drawer 的关闭而完成. 同样的动画也应该应用在 Action Bar 的转变上. 还有一个对于开发者而言常见的讨论是, 应该用 Activity 还是 Fragment? 这个问题并没有标准答案, 也很难回答. 一般来说还是视情况而定 —— 它实现起来难度如何? 对于我的应用而言靠谱吗? 如果你有什么建议的话当然欢迎评论.

slides.016

上图展示的就是正确的做法, 在 Action Bar 上显示 Drawer Indicator.

 

9. 不显示 Up 箭头

slides.017

上文说过, 所有出现在 Drawer 中的导航页面都应该显示 Drawer 指示, 这点反过来也是一样成立的 —— 没有显示在 Drawer 中的东西就不应该显示 Drawer 指示. 比如在上图, 当用户进入某个内容的时候, Drawer 指示依然显示. 实际上, 这个内容页已经不是导航页了, 也没有在 Drawer 中显示, 这里是应用更深的层级, 已经不归 Drawer 管了. 这里应该显示的是 Up.

slides.018

在显示 Up 同时, 你也可以允许用户以边缘滑动的方式唤出 Drawer. 你不需要总是显示 Drawer 指示来告诉用户可以唤出 Drawer, 因为在次级界面中唤出 Drawer 是某种意义上的”进阶用户操作”. 有人发现了, 那很好, 没人发现, 不要紧, 通过 Up 他们依然能够找回他们需要的导航. 另外, 你可以看看 Google Play Newsstand 是如何处理在没有 Drawer 指示的地方处理 Drawer 的 —— 渐变动画真的非常重要.

 

10. 右侧导航

slides.019

前文说过, Android 上有个规律就是”导航靠左, 操作靠右”. 对于从左向右阅读的用户而言, 左侧导航项能够更好的强调导航层级. 另外, 由于 Spinners 只能出现在左侧, Tabs 也往往将最左侧的一个设为默认, 右侧的 Drawer 与这些操作距离过远. 而且, Drawer 指示放在左边, 操作的时候向左回缩, 如果在右侧使用 Drawer 的话就会遇到视觉隐喻冲突.

slides.020

正确的做法就是如上图所示. 当然, 如果在从右向左的语言环境下 (比如说, 希伯来文什么的, 不过我觉得我们国家的开发者应该不怎么会去做希伯来语适配吧…), 那当然是应该反转这些东西的位置.

 

以上就是本期 ADiA 介绍的全部十个导航设计错误. 如果你有更多的常见/不常见错误, 或者对于上面提出的错误有更好的解决方案, 当然欢迎评论.

最后, 一如既往的感谢 +Roman Nurik 和 +Nick Butcher 的 Android Design in Action 活动.

Android Design in Action —— 初期体验

slides.001

我们知道, 很多时候, 如果不是非常必须的应用话, 一个应用被安装到用户手机上的头几分钟对于这个应用而言可以说是生死存亡的关键时刻 —— 有相当大数量的应用就在这几分钟被用户丢进了垃圾桶 (有些”负责”的用户还会去 Play Store 给个一星). 那么, 作为开发者/设计师, 如何让你的应用挺过这关键的几分钟, 得以在用户的手机里活下去? 这就是我们将要在这期 ADiA 中讨论的话题 —— 登录体验/初期体验.

如果你想要让你的应用熬过那至关重要的几分钟而得以存活, 那么营造一个良好的初期体验就是不二法门.

不知道你还记不记得十大常见 Android UX 错误中提到的第二大 UX 错误, 即贫弱的首屏交互? 这里的首屏交互很大程度上指的就是初期体验. 之所以把这一点单独拎出来写一篇新文章, 是因为首屏交互和初期体验实在是太重要了.

首先, 不要显示启动画面. 这里的启动画面尤其指的是比如一个硕大的应用 Logo 或者广告什么的, 比如新浪微博, 比如微信, 比如 QQ… 记住, 内容第一, 而前面提到的那些应用的启动画面并不是内容. 彰显品牌是很重要, 但正确的方式是用 Action Bar 图标和颜色来做这种事情. 比如在 Google Play 中, 几个应用和分类都采用了不同的 Action Bar 图标和颜色来彰显品牌.

很多人认为启动画面的很重要的作用是提供加载时间. 但是, 就算你真的需要一个画面来缓冲加载时间, 你也应该至少显示出你的应用的框架 (比如 Action Bar 和 Fixed Tabs), 或者一个自制的, 动态的 Loading Spinner (比如布卡漫画布卡娘… 可惜的是布卡漫画自己有个 Splash Screen). 这样的话用户至少可以进入设置, 查看你的应用的不同的区域, 甚至开启 Drawer 看看里面有什么东西… 这些都能够更好的减轻用户的焦虑感. 当然, 如果是用户第一次打开这个应用 (刚刚安装完), 是可以显示一个欢迎画面的. 比起显示启动画面更糟糕的是显示全屏的启动画面, 那就是错上加错了 —— 要不咱再来个启动音乐和不识别按键操作凑齐三件套得了?

讲完了启动画面, 我们来说说引导界面.

对于一般的应用而言, 绝大多数情况下在用户第一次打开它的时候都应该给出一个引导界面以告知用户这个应用是干嘛的, 该怎么用, 是不是需要登录, 等等.

*上面图片中的内容参见 Android Design.

Android Design 中提到”不要显示用户不需要的帮助信息, 除非事不得已”, 引导界面就是一种事不得已的情况.

尽量避免强制打断的引导界面. 实际上, 比起使用专门的引导界面, 在应用内的引导 (也就是行内式) 是我们更推荐的. 行内式的引导界面就像是图中 Google Play Movies 中显示的那样, 引导作为一张内容卡片存在, 可以很容易的被消除掉, 也可以在显示引导的同时显示内容 (只要往下卷动就行了). 这样, 用户就能很清晰的认识到这个应用能做什么. 而且, 这个卡片中提供了最初始的操作 —— 购买影片, 可以说是这个应用里最初始的操作 (你需要先购买影片才能在影片库里浏览).

上图就是一个典型的强制打断式引导界面. 可以看出, 这个引导界面和应用几乎是两个东西, 游离于应用本身之外. 除非你的应用有非常非常非常重要的东西一定要让用户全部看完 (即使他们之前已经用过这个应用了), 否则尽量提供一个快速跳过引导的按钮.

当然, 除了应用本身, 别忘了利用好 Google Play —— Play 提供了给你展示视频和截图的机会, 你可以好好利用视频和截图介绍你的应用. 而且这些介绍都是在用户把应用拿到手之前做的, 不会影响到用户的使用. 不过, 这毕竟是 Play Store, 不是引导画面, 所以尽量选择一些对用户而言有吸引力, 能展现应用价值的画面/截屏吧. 当然, 别忘了提供应用在不同尺寸设备上的截图. (Play Store 会根据截图把你的应用加上平板适配的标签…)

还有一种不错的引导方式就是通过列表的空状态进行引导. 空白状态是个非常好的告诉用户该干什么的机会. 这样做的好处就是当列表不再是空状态的时候这些引导就很自然的不存在了, 而且这也属于一种行内式的引导.

还有一种引导方式就是提供预载内容. 对于很多需要展示内容的应用而言, 在初次启动的时候就展示一些预先添加好的内容, 比如上图股票应用中的那些默认的股票, 能很好的帮助用户认识的应用的作用与样貌.

大多数时候你都会需要你的用户注册或者登录你的应用.

但是实际上, 你应该尽量延缓用户的登录操作 —— 如非必须, 允许用户在非登录状态下浏览你的应用, 等到登录能带来必要而明确的好处时, 再询问用户是否登录. 事实上, 用户宁愿等到他们完全明白自己为什么需要登录之后, 再进行登录操作. 不要一打开应用就劈头让用户登录. 很好的一个例子是 Tumblr, 在你打开 Tumblr 之后, 它会先展示一些默认的优质内容, 你可以随意浏览, 当你点到个人账户 Tab 或者点击 Like 或者 Reblog 的时候, 他才会问你是不是需要登录 (没登录的话这个 Tab 和操作就是没用的). 同样的, 国内的一些应用比如 Bilibili 动画, 也不会强行要求用户登录.

输入用户名/邮箱/手机号和密码总是一件很麻烦的事情, 如果你能提供更快更方便的登录方法那就再好不过了. Android 的很大好处就是可以通过接入第三方帐号来进行方便的登录, 比如在国外应用上非常常见的通过 Facebook, Twitter 和 Google+ SDK 登录, 只要用户有安装这三个应用在他们的设备上, 就可以不需要输入用户名密码, 直接授权登录, 极大的简化了登录流程. 当然, 在国内的应用恐怕就没法用的这三个方便的登录方式了, 不过我们有微博…

对于 Google+, 还有一个独特的好处就是, 如果你提供了 Google+ 登录的话, Play Store 能够提供 OTA 登录的能力, 特就是说当你的应用被安装到用户的手机上时, 就已经登录好了他的帐号, 而无需用户再去登录一遍.

当然, 你最好也提供一个注册的功能. 但是, 尽量把注册流程弄得简单易懂, 毕竟, 在手机上输入复杂的密码还是一件很痛苦的事情的. 打开一个网页也是不建议的.

简化后的注册画面大概是像上图那样, 只留下 Email 地址栏和密码栏, 因为只有这两个是最重要的, 其他都可以推迟. 这样用户就不会在看到注册画面的时候被一大堆需要填的文本栏给吓到.

Google Play Service 提供了让你读取用户账户登录的邮箱的 SDK. 好好利用这个功能, 因为往往用户在手机上登录的邮箱就是他打算用来注册这个服务的邮箱. 提供邮箱建议可以让用户省去输入邮箱的麻烦, 你也可以采取自动补全的方式来补完用户的邮箱 (@ 后面的东西, .com 之类的, 就像在第一次登录 Android 上的 Google 账户时你完全不需要输入 @gmail.com 因为这会自动补齐), 毕竟输入邮箱是一件挺麻烦的事儿.

你甚至可以把密码作为可选项, 因为用户总是可以在以后重置密码的, 当然你也可以替用户生成一个密码, 反正不会有用户没事就登出 – 登录玩儿的. 用户自己设置的密码也不一定就是很好的密码, 很多用户用相同的一套密码在不同的账户上, 也许是很简单的密码, 但是如果你强行要求用户在密码里加入符号和大写字母的话, 他们又会觉得很烦.

这样, 用户就只需要输入邮箱 (的前几个字母!) 就可以点击注册了, 多棒~ 最后, 你也可以把键盘上的 Done/Next/回车变成注册键, 最大程度的简化用户的操作. 另外, 在 ICS 以及之后的版本中, 系统可以提供用户的姓名和头像, 这些信息都可以被你调用, 能够省下让用户在输入/设置一遍的麻烦.

最后要提到的是屏幕覆盖叠加层.

关于覆盖叠加层, 总体而言就是一句话: 尽量避免 (笑). 有些东西其实是完全不需要提示的, 比如 Drawer 或者 Action Bar, 你不需要一再告诉用户这些东西该怎么用. 当然, 你可以在第一次打开应用时展开 Drawer 告诉用户他们的存在.

当然, 有些自定义手势还是有必要告诉用户一下的. 比如在新版 YouTube 中, 在视频最小化的状态下有两个自定义手势操作 (关闭和最大化), 这对于大多数用户而言都是未知的, 所以在这里告诉用户该怎么做就是很有必要的了.

 

以上就是这期 Android Design in Action 的内容了, 希望它能帮助你改进你的初期体验~ 一如既往的大力感谢 Android Developers Relation Team 的 +Roman Nurik, 和 +Nick Butcher 的 Android Design in Action 活动. 最后依然感谢结画的题图 (onboarding, 哈哈)~

Android Design in Action —— 一起来食 Kit Kat

design_elements_landing

就在今天, Google 悄然发布了 Nexus 5 和 Android 4.4. Android 4.4 虽然依然只是 0.1 的版本号升级, 但是却带来了非常巨量的区别. 这期 ADiA 的特别节目, 我们就来遍历一下在 Android 4.4 中, Android Design 有了哪些变化.

slides.003-001

我们要提到的第一件事情就是今天随着 Android 4.4 一起发布的新设备 (等一下, 是不是反了?), Nexus 5. Nexus 5 作为新一代 Android 展示机, 它有着 5″ 大小, 1080p 的屏幕. 这里有些数据是你没法从配置表中看到的. Nexus 5 的屏幕对应着 640 x 360 dp, 和 Glalxy Nexus 是一样的, 而比 NexusNexus 4 略窄. 而它的屏幕 (逻辑) 密度 XXHDPI (480 dpi), 而不是 440 dpi (实际密度). 另外顺便提一句, 现在 1080p 的设备越来越多了, 且不说 HTC One 和 Galaxy S4, 国内的魅族和小米也一起跨进了 1080p 的大门, 所以当你开发应用时, 请无论如何准备好 XXHDPI 的资源.

slides.004-001

在 Android 4.4 中, 系统 UI 变得更加的中性. 在之前的 Android (4.0-4.3) 上, 系统颜色是很显眼的蓝色. 触摸反馈和其他高亮颜色也都是这种高对比度的蓝色. 在很多情况下, 这样的蓝色会和应用中采用的个性化颜色产生强烈的冲突. 在 Android 4.4 中, 系统的颜色不在那么显眼, 而是更多的采用了中性的, 灰调的颜色以避免和应用的颜色产生冲突. 有了这样的铺垫, 你就可以更加放心的在你的应用上采用丰富的颜色了.

对了, 别忘了去看看 Android Design 的新章节 “Your Branding“, 在这个新章节中, Android Design 将教你如何更好的凸显你的品牌特色 —— 包括用色, Logo 和图标. 在这个方面, Press 做得非常好.

slides.006-001

在 Android Design 的 Your Branding 中, 特别提到了图标制作这一点. 在之前的 ADiA 节目文章中, 我们就强调过图标制作的重要性. 当你需要自己制作一套图标的时候, 请让这套图标的表意符合 Android 自带图标的表意. 这里举了个栗子, 比方说, 你想要在应用中使用 iOS 7 风格的图图标. OK, 这没问题. 但是, 请把 iOS 7 的分享图标换掉, 重新画一个相同风格, 但是近似 Android 中分享图标的新图标, 而不是直接把一整套 iOS 7 的图标给复制过来. 通过重新画这些表意不容的图标, 用户才不会在看到新图标的时候感到困惑 —— 说真的, 我第一次用新的 Safari on iOS 7 的时候, 完全不能理解那个图标的意思. 我一直以为, 那个图标要么是上传, 要么是关闭当前标签页.

slides.007-001

正如先前提到过的, 在 Android 4.4 中, 整个系统的颜色都变得更加的中性. 原先个性强烈的 Holo 蓝色被大量替代为不那么显眼的颜色. 比如, 你会发现, 系统自带的按钮的”按下”指示高光从原先的 Holo 蓝色高亮 + 外圈变成了 10% 黑色遮罩. 当然, 当你在自己的应用中要用到按钮的时候, 把 10% 黑色遮罩换成你的应用品牌颜色的遮罩即可. 请参见 Android Design 中的相关论述.

实际上, 10% 黑色遮罩在光线充足的环境下, 可见性是明显低于某种颜色的遮罩的. 所以尽量不要偷懒直接使用 10% 黑色遮罩, 而是用品牌颜色, 或者 Holo 蓝色 (如果你的应用没有强烈的品牌颜色的话) 遮罩来加强触摸反馈的效果.

slides.008-001

在 Android 4.4 中, 沉浸式体验的重要性得到了再次强化. Android Design 中专门加入了一个章节对新的全屏模式进行了论述. 在这个章节中, Android Design 详尽的描述了你的应用应该在什么时候, 以何种方式进入全屏模式.

全屏模式又分为两种, 一种叫后撤式 (Lean Back), 另一种叫做沉浸式 (Immersive). 后撤式已经在之前的系统中被广泛使用了 —— 当你在观看 YouTube 视频的时候, 大部分时间是不会去碰屏幕的. 这种情况下, 虚拟键和状态栏都会自动隐藏, 但当你触摸屏幕的时候, 它们又会出现.

slides.009-001

而沉浸式则不太一样, 在沉浸式全屏状态下, 对屏幕的操作并不会唤出系统栏. 想要唤出系统栏, 你必须从屏幕的上/下边缘向屏幕内划入. 沉浸式的全屏状态更适合游戏和阅读这样的操作. 在你第一次进入一个应用的沉浸式全屏状态时, 系统会进行提示.

那么, 以前的低调模式 (Low-Profile Mode/Lights Out Mode) 怎么办? Google 的建议是, 在新系统上采用全屏模式, 在 4.3 和之前的系统中采用低调模式.

slides.010-001

Android 4.4 另一个很重要的改变就是透明系统栏. 新的系统栏是渐变透明的, 可以最大限度的允许屏幕显示更多内容, 也可以让系统栏和 Action Bar 融为一体, 仅仅留下最低限度的背景保护以免通知通知栏内容和 Action Bar 文字/图标难以识别.

slides.011-001

除了主屏幕, 你也可以在应用中利用到半透明的系统栏. 这里有一个地图应用的 Demo, 你可以看到, 地图扩展到了整个屏幕上. 还有一点很重要的事, 那就是注意使用背景防护. 背景防护一般是采用渐变黑色, 以保证和状态栏图标能够产生一定的对比度. 在这样的状态下, 尽量避免使用标准 Action Bar, 而是使用 Translucent Action Bar. 这方面的内容, 在以后的 ADiA 中会提到.

slides.012-001

也许你已经注意到了, 在 Nexus 5 上, 启动器图标出奇的大.

在一般状况下, 启动器图标的大小是 48dp 的方型. 但是, 在 Nexus 5 上, 启动器图标比一般情况下大 25%, 达到了 60dp 大. 而 Nexus 5 是 XXHDPI 的设备, 所以 60dp 就相当于 180px. 这时候, 你就只能采用更高分辨率 —— 也就是 XXXHDPI, 640dpi (顺便我一直觉得这种叫法太脑残了, Adam Koush 自己在念的时候都忍不住笑了) 大小的图标. XXXHDPI 大小的图标对应长宽为 192px. 实际上, 这正是一般情况下平板 UI 的主屏上显示图标的方式. 所以, 你总是需要准备一个比素材更高分辨率的启动器图标以备不测…

而且, 千万别认为”反正 Nexus 5 也就那么几台, 大不了我不优化了”, 别忘了 Google 将会把 Nexus 5 使用的启动器在 Play Store 发布以供非 Nexus 机型使用… 到时候你就准备好哭去吧.

slides.013-001

在 Android Design 的更新中, 两种新的手势被正式归纳入麾下, 他们就是双击和双击拖动. 双击在一般情况下相当于自动缩放. 比如, 在 Chrome 中, 当你双击一个内容块的时候, Chrome 会将网页放大到使这个内容块与屏幕等宽的大小. 而当你再次双击的时候, Chrome 会返回原先的大小. 另外, 就像是在 Gmail 中一样, 双击放大原本就填充宽度的文字块之后, 应该尽可能的把这些内容进行重排以让它们符合屏幕的宽度, 而不是让用户去横向卷动以阅读完整行文字.

双击缩放, 有个很明显的问题就是, 有的时候你并不能确定双击之后到底是缩, 还是放. 这时候我们就引入了双击拖动这个手势. 在 Google Maps (和新版的 Chrome Beta) 中, 双击拖动能起到定向放大的作用 —— 当你双击向上拖动时, 就是放大, 向下拖动, 就是缩小.

比起双指缩放, 双击和双击拖动的好处就在于它们非常便于单手操作.

slides.014-001

这个… 不需要我多说了吧? 虽然屏幕录像功能不会给你的设计或编程带来好处, 但是有很多别的优点, 非常实用, 你将不再需要花钱购买一个屏幕录制应用, 并且担心录像质量的问题了.  你也可以在开发者设置中打开显示触摸点功能, 这样就可以在屏幕录像中捕捉到触摸点了. 如下图. 这些录像对于制作你在 Play Store 中的描述视屏而言大有帮助.

pointer_spot_anchor pointer_spot_hover

slides.015-001

最后一点就是场景切换. 在 Android 4.4 中, 系统自带的切换动画有了很大的不同. 我们将其称为布景与转场. 你可以对应用中的场景进行定义. 系统会自动在不同的场景中采用不同的转场动画. 对于开发者而言, android.transition.TransitionManager 是必须查看的部分. 对于设计师而言, 你需要告诉开发者, 在什么样的场景下, 你想要使用什么样的动画. 现在, 定义不同的动画已经比以前要容易太多了.

最后, 一如既往的感谢 +Roman Nurik+Nick Butcher 和 +Adam Koch 的这一期 Android Design in Action 特别篇.

Android Design in Action —— 编与集

slides.001

大家好, 这是久违了的 Android Design in Action 栏目. 本期 Android Design in Action 介绍的是如何更好的, 合理的展现一个集合 (Collection).

 

slides.003

首先, 我们明确一下概念: 什么是集合? 集合就是一组物体. 对于 Android 应用而言, 基本上集合就意味着一个列表的项目, 比如最常见的书单和购物清单, 等等.

 

slides.004

说道集合, 我想大家都应该对上面的三种表现方法不陌生吧, 他们分别代表了最常见的基本布局 —— 列表, 网格与 viewpager. 这期 Android Design 我们将着重研究前两种.

 

slides.005

我们将从两个方面入手进行讨论 —— 集合的使用与集合的变更. 其中, 集合的使用又包含了提纯内容与响应式布局, 变更包括了添加/消除, 重排序与物件操作.

集合的使用

提纯内容

slides.007

对于一个集合而言, 这些操作是非常重要的: 快速卷动, 首标, 改变视图与排序:

在左边的联系人应用中, 每个字母都被归纳为一个分段, 每个分段都有一个置顶首标. 带有首字母索引的快速卷动与置顶首标可以帮助用户更快的进行模糊的范围查看. 而在卷动时, 首标保持在列表的顶端, 同时 Indexed Scroll 也会提示当前的首字母;

中间的图库应用中, 为了让用户方便的以不同方式查看缩略图, 图库在 Action Bar 上提供了一个切换视图的下拉菜单. 另外, 你可以注意到, 在当前文件夹的名字下方, 用小一号的字体标识了当前的视图模式, 这也是一种不错的提示方式;

右边的第三方应用中, 它采用了一个 Action Bar 图标附加下拉菜单提供了变更排序方式的功能. 对于 Android 而言, 这些都是很基本而常见的提纯内容的方式与行为.

 

slides.008

接下来要讲到的操作, 就是真正的”提纯”操作了. 这些提纯操作直接影响到项目, 会使屏幕中显示的项目减少, 精炼. 他们更像是过滤器.

最常见的项目提纯操作就是标准的搜索功能了. 他能直接显示出与用户输入相符的项目. 比如在联系人中, 搜索能直接显示出你搜索的联系人. 当你有很大的项目总量时, 搜索能提供非常不错的效果;

第二种项目提纯操作是集合过滤器. 作为例子的 Pocket 提供了这样的过滤功能, 它能让列表中只剩下某种类型的项目, 比如文章, 视频或者图片. 值得注意的是, 过滤器作为一个”操作”被放置在 Action Bar 中, 但是它同时又提供了下拉菜单, 所以具有一个 Spinner 的标识符 (右下箭头) (就像图库等应用的分享操作一样);

最后一种, 也是我最喜欢的一种, 是过滤器 Drawer. 当你采用了左侧 Drawer 来提供应用内导航的时候, 有没有思考一下, 右侧是不是也能放一个 Drawer, 这个 Drawer 又能干些什么呢? 对于一个集合而言, 右侧 Drawer 作为过滤器的好处是显而易见的. 这个过滤器能够让用户在设置过滤阈值的时候实时预览到结果, 对于用户体验而言是很大的改进. 另外, Drawer 也可以通过从右侧边缘划入的手势展开, 非常便利. 有一个需要注意的地方是, 如果你要在 Drawer 中使用示意图中那样的滑块选择器, 请一定要小心不要让左右拉动滑块的操作和对 Drawer 的操作产生冲突 —— 如果你用过 Feedly (版本 17) 的那个脑残 Drawer, 你就会明白为什么我要特地强调这一点了.

关于右侧 Drawer 还有一点需要注意的是, 在 Android Design 中, 导航用的 Drawer 是放在左边的. 不要把导航 Drawer 放在右侧. 右侧 Drawer 的定制性更强, 可以变成你需要的任何东西.

响应式布局

当我们谈论集合的时候, 我们很难想象一个集合会以某一种固定的形式出现在你的面前. 各式各样的集合会以不同的大小不同的形状显示在不同的设别上. 就以列表做例子, 列表在小屏幕上是个不错的选择, 但是当你在一台大屏幕设备上横屏查看一个被放大的列表, 那么体验就必然是很差劲的了 —— 空间被浪费了, 信息显示也太多了.

于是, 怎么解决这个问题呢?

slides.010

最简单的办法就是, 把列表变成一个框格. 对于开发而言, 列表和框格都不是很有难度的东西. 只要为不同的屏幕提供不同的布局, 就可以很轻松的解决很多问题. 尤其好用的场景是, 当你的列表是由图片和标题文字组成的时候.

 

slides.011

第二个方法就是把框格中的内容交错排布. 我们称之为错落集合. 这就比单纯的从列表变为框格要来得更高级了. 这么做会让你的集合变得更漂亮. 同时, 你也可以给不同的项目以不同的权重, 让用户注意到这些项目中更值得注意的东西.

 

slides.012

如果你巧妙的将列表, 框格和错落集合搭配使用, 你就既能得到更多的展示空间, 又能拥有极佳的排版效果. 这方面的例子就是 Pocket. Pocket 在不同的屏幕上采用了不同的布局方式: 在小屏幕上采用常规的带图列表, 7″ 平板上使用框格布局, 更大的平板上则采用错落集合. 通过这种方式, 他们避免了很多应用在平板上有过大的留白的问题 (以前的 ADiA 上反而是建议留白… Pattrn 就是采用了留白的例子).

 

slides.013

当你考虑”在不同的设备上显示内容”这么个问题的时候, 不妨跳出以往的框架, 考虑响应式布局. 最简单的办法, 就是在大屏幕上采用”列表|详细”布局. 这样, 你就可以依然采用小屏幕上采用的列表布局, 同时能够在大屏幕上取得不错的显示效果.

 

slides.014

当你需要不同大小的图片的时候, 中心裁切会帮你大忙. 在牺牲掉一部分图片的前提下保持原图片的比例, 中心裁切可以帮助你很容易的制作框格视图和错落布局中使用的图片. 关于图片的详情, 我们会在以后的文章中介绍.

 

slides.015

提到排版布局, 不得不提到最近非常流行的一种设计风格, Google 将其称之为”由内而外式设计”. 所谓的由内而外的设计, 就是把内容放在最优先, 把你想要展示的内容放在最显眼的位置, 而不是从一个空白画布和网格开始, 生硬的往里面填东西. 而这种设计风格的最直观的体现, 就是卡片 —— 内容块.

slides.016

slides.017

slides.018

当我们开始考虑展示内容的时候, 我们会注意到内容有不同的形式. 相应的, 我们也应该选择不同的展示方式. 就卡片而言, 我们可以采用大卡片, 中卡片或者小卡片, 竖排的卡片或者横排的卡片. 这些卡片都代表着不同的内容. 当你确定了你将要采用哪些卡片 (展示方式) 之后, 你就可以开始把这些卡片放到屏幕上了 —— 在 Photoshop 中新建画布, 开始工作.

slides.019

slides.020

多放几个这样的卡片, 你就做出了一个最基本的集簇.

slides.021

slides.022

在你做出了一个基本集簇之后, 你就可以在这个基本集簇上进行扩展了. 刚才做的不同大小的卡片这时候便派上了用场, 利用不同大小或者横竖的卡片来替换原本全部是大号的卡片, 能够起到区分优先级与合理利用空间的作用.

slides.023

当这些集簇在设备上显示的时候, 你就需要意识到, 不是每个设备都能完整的显示一个集簇. 而集簇的排布方式同时也应该顺应页面的卷动方式 —— 假设这里采用的是纵向卷动, 那么也许使用更多横向的卡片会更加合适.

slides.024

在更大的设备上, 集簇能够被完整的显示, 这时候更重要的就是如何排布他们才能制造更佳的视觉效果了.

综上, 所谓的从内而外式设计, 就是从最小的控件开始, 以展示信息为优先, 一步步向外扩展, 最后构建出一个合理的框架, 而不是先搭建框架, 然后再一步步向里面填入内容.

slides.025

举个例子, 这是 Play Store 中的电影卡片. 对于一部电影, 最重要的展示信息就是海报, 标题, 价格与简介. 于是我们制作了三种不同尺寸的卡片, 每一种都能充分的展示前述的四种信息.

slides.026

之后需要做的, 就是在不同的设备上显示合适尺寸的卡片了. 当然, 也许你会希望一次性显示很多个项目, 那么只要合理的将卡片整理组合成集簇即可.

 

合集的变更

有的时候, 用户可以向集合中添加项目, 也可以删除它们; 这些项目或许可以被移动, 被操作. 那么如何使这些集合上的变更行为变得更为友好呢?

增删项目

对于一个可以被用户变更集合而言, 添加和移除项目是最为基础的操作.

slides.028

往集合中添加项目的方法有很多, 一般情况下, 最常见的方式就是在 Action Bar 上提供一个”新建/添加”功能键. 比如说, 在上图左的联系人应用中, 这样的按钮让用户创建一个新的联系人/联系人组;

不过这么简单粗暴的添加新项目方式显然不是我们所推荐的. 很多时候, 我们都被一种想法束缚: 添加作为一个动作/操作, 应该位于 Action Bar 中. 不过, 我认为不妨换个思路来看看. 比起用一个专门的按钮来提供新增功能, 不如试试行内式/嵌入式的新建方式. 比如, 图中的 Play Music 在电台列表的顶端提供了新建电台的按钮, 而 Keep 则做的更好, 它在列表的末尾提供了一个颜色略浅一些的”新建项目”来告诉用户”这并不是一个项目, 而是类似幽灵的存在”, 而当用户点击这个项目的时候, 就相当于激活了这个项目, 让它从幽灵变成实体. 可以看出, 行内式/嵌入式的添加功能可以更好的与已有项目融为一体;

还有一种不错的添加方式是空白状态. 当用户第一次安装/开启应用时, 他们面对的很有可能是一个空白的页面. 那么, 比起冷冰冰的告诉用户”这里没有内容”, 为什么不利用空白状态, 提示用户自己创建内容以作为新建项目的指示呢? 在图中的 Keep 中, 内容区域的那个 Create a reminder 就是一个巨大的按钮, 用户触摸这个区域, 就会进入新建提醒的界面. 这个方式对于大部分用户自建内容的列表都适用.

slides.029

当你没法在 Android Design 给出的标准图标中找到你需要的图标时, 那么就得考虑自己制作新图标了. 制作 Action Bar 图标有一种普遍的规则, 就像制造一个新的单词一样. 我们把图标本身视为词根 —— 比如添加群组中的群组 (三个小人) —— 把操作视为后缀 —— 比如添加群组中的添加 (加号) —— 这么一来, 一个图标就做完了~

ic_action_new_account ic_action_new_label ic_action_new_attachment ic_action_new_email ic_action_new_event ic_action_new_picture

就像这样, 很简单吧? 这些图标, 基本上都能让人一看便明白他们的含义 (除了倒数第二个… 我可不觉得倒数第二个能够一眼看懂… ).

slides.030

用户既然能够添加项目, 那么自然也要能移除他们.

首先要提到的是位于项目上的项目 Action Overflow. 这三个小点里可以放下各种针对单个项目的操作. 有一点需要注意的是, 这三个小点虽然看起来非常小, 但是他们的触发区域依然要有 48dp x 48dp 大, 甚至可以做得更大, 让整个项目的右下角都成为可触发区域. 当用户点击这三个点之后, 一个 Overflow 菜单就会出现. 在 Play Music 中, 当你点击三个小点的时候, 就会出现删除操作的选项;

另外一种比较传统的方式就是采用 Contextual Action Bar. 举个例子, 在图库应用中, 当你长按选中某张图片的时候,  Contextual Action Bar 便会出现, 提供了全选, 分享和删除等操作. 不过, 还记得我在上一篇文章里是怎么说 Contextual Action Bar 的吗? 可见性不足. Contextual Action Bar 需要通过长按来唤出, 很多时候存在着可见性不足的问题. 所以在你打算采用这种方法之前, 最好再考虑考虑;

第三种移除项目的方式, 就是随着 Android 4.0 一起亮相 (实际上 webOS 啥上早就有了…) 的滑动删除/滑动忽略. 这种方案在纵向/横向列表上的效果最佳. 当用户开始向左/右或上/下 (取决于列表卷动方向) 滑动某个项目时, 项目会变成半透明并且渐隐. 而且, 这个手势还可以和滑入/下滑动画结合使用 —— 当用户滑动消除某一项目之后, 原本在项目前后/左右的项目滑动填补到它原本的位置上, 以消除生硬感, 同时传递出这个项目已经从列表中移除的信息.

在这里我必须再强调一遍, 虽然我们很喜欢滑动消除这个手势, 但是这个手势的可见性太低了. 请务必提供可以通过单击完成的移除操作以提高可见性. 正面例子可以参考 Gmail (单击头像选取信息, 出现 Contextual Action Bar). 另外, 为了让用户意识到滑动删除的存在, 你可以在列表上使用”滑入”的动画.

重排项目

除了增删项目, 用户也许还会希望自己重新排列表单的顺序. 这对于用户的个性化需求而言是十分重要的. 举个最简单的例子, 用户非常需要对一系列的”任务”进行重新排序.

slides.032

最简单直接的方式就是提供一个拖动把手. Android 上标准的拖动把手是三道短横线 (实际上 Roman Nurik 也说这三道短横线就是缩小版的 Drawer 提示… 所以我们也叫它 Slider 滑块),

slides.033

当然, 你也可以使用自己的样式, 比如两列小方块之类的, 让人觉得摩擦力很大的图示. 右边的 DashClock 中采用的图示就是一种被称为”轮辙”的指示, 算是一种前段时间广为流传的指示方式;

在左边两个图示里, Google Keep 和 Play Music 都采用了标准的把手. 当用户按下这个把手的时候, 当前的项目便会略微浮起和/或高亮, 给用户以”这个项目被提起来了”的反馈. 很重要的一点是, 当你的应用中, 列表页左侧是 Drawer 触发区时, 如何才能确定触发 Drawer 和移动项目的操作不冲突? 这个时候, 你应该先想想, 在这个地方, 究竟是重排项目更为重要, 还是导航 Drawer 更为重要? 如果是重排项目更重要, 那么你大可以把拖动把手放在项目的右侧, 或者告诉用户”按住图片可以拖动项目”, 或者采用之后介绍的长按拖动方式. 另外, 这个把手虽然看起来很小, 但是它的实际操作区域必须大于 48dp —— 甚至我建议开发者们应该把操作区域扩展到整个列表项那么高, 只留 8dp 上下间距;

在 Google Keep 中, 我们还是用了另外一种方式来移动项目, 那就是长按拖动. 实际上, 在 Android 系统原本的逻辑中, 重排就是通过长按后拖动来进行的, 比如主屏图标的重排. 当你在 Keep 中拖动一个项目的时候, 你会看到项目变成半透明状跟随你的手指移动, 而在框格中则有一个和项目一样大的方框提示了当你松开手指之后项目会落下的区域. 同时, 其他项目也会随着当前项目位置的变化而改变位置. 但是这种排序方式的坏处依然是可见性不足. 这点很难通过直观的方式提示, 除了在用户第一次使用的时候进行文字提示.

另外, 很重要的一点是, 请务对用户的拖放操作进行恰当的反馈. 就像前面提到的, 让项目”飞离”原先的高度, 高亮项目, 或者让项目变成虚影, 都是很好的提示方式. 还记得 Android Design 的精髓么? 拟真. 在现实中, 我们重排东西的时候, 都会把一个东西拿起, 移动到需要的位置之后, 放下. 请把同样的操作反馈在应用中显示出来.

项目操作

我想我在上一篇文章中似乎已经吐槽过 Android 这混乱的上下文菜单了. 通常情况下, 点击项目本身会带你进入项目详情的界面, 或者执行一级操作. 那么如果这个项目还附有次级操作呢?

slides.035

首先依然是项目 Action Overflow. 这个菜单里能放的东西很多, 不单单是删除, 在 Play Store 里你还可以直接安装一个应用;

其次依然是 Contextual Action Bar. 和 上下文 Action Overflow 一样, 在 Contextual Action Bar 中可以放各种各样的操作. 甚至很多需要进入详情界面才能执行的操作都可以放在 Contextual Action Bar 上. 当然, Contextual Action Bar 还有一个好处就是他能够同时操作多个项目. 换句话说, 如果你想让用户同时操作多个项目, 那就只能选择 Contextual Action Bar 了. 批量操作的效率是绝对高过另外两种方式的;

还有一种很普遍的方式是在项目的右侧放一个 Borderless Button 以提供一个最重要的次级操作. 这种方式的好处就是它是行内/嵌入式的, 关联性最高, 可见性也很强. 不足之处就是只能放一个操作, 而且不能批量操作. 需要注意的是, 如果你需要采用这种形式的按钮, 请务必添加分隔线让用户明白, 这个项目上有两个不同的操作区域. 另外, 这个按钮整列都是可触摸的区域. 另外需要注意的就是触摸反馈. 理论上来说, 触摸项目的话, 应该让整行都发光, 而触摸右侧按钮时应该只让按钮区域发光. 这里有个很好的例子, 就是在联系人应用中的电话号码项目. 每个号码的右侧都有一个短信图标, 这就是电话号码的次级操作了.

 

看到这里, 关于集合的内容就都讲完了. 再次大力感谢 Android Developers Relation Team 的 +Roman Nurik, 和 +Nick Butcher的 Android Design in Action 活动. 另外, 这期的题图依然是又结画的, 再次感谢~ 不久之后的下期节目再见~

EOF

Android Design in Action —— 十大常见 Android UX 错误

slides.001

作为一个长期使用 Android 的用户, 我在使用 Android 应用的时候经常遇到各种各样的交互上的问题, 并且早就想整理它们写一篇文章了. 但是,由于懒惰和拖延, 这篇文章一直处于草稿的状态. 正巧, 这期 ADiA 中, Android 开发团队为我们着重强调了当下 Android 应用中很常见的, 应该避免的错误.

Android 开发者关系团队每天都会试用无数的 App 或者受到无数的开发者发来的, 请求评测的 App. 在评测如此之多的应用之后, 他们总结出了一些最常见的错误, 并且在这期节目中为大家呈现出来.

在正式介绍这些错误之前, 我想稍微提一句. 这些错误是非常具有普遍意义的错误, 也就是说, 你用十个应用可能就会碰见这十个错误, 甚至你会在一个应用中碰见全部十个错误. 这种情况在天朝显得更加严峻. 所以, 希望这篇文章能让大家摆脱摸着石头过河的窘境, 直接的避免一些常见的错误.

slides.004

十大用户体验”反模式”, Android 开发者联系团队为你用心呈现~ 希望大家看 (乖) 得 (乖) 开 (中) 心 (枪)~

第十: 你必须加载完这些东西… 否则!

slides.005

这里的加载, 实际上指的是左图中的那种, 一个圈圈转啊转的对话框. 这种对话框的出现是应该要避免的, 另外, 比起这么一个对话框, 那些不响应 Back 操作的对话框简直是丧心病狂. 超大号哭脸. ヽ(´Д`;)

解决方案其实也很简单, 采用嵌入式的载入指示即可. 当然, 如果你能做到实现在后台加载好数据那就更棒了.

第九: 你摸我不到!

slides.006

首先请无视 Roman Nurik 和 Adam Koch 用来卖萌的 Na-na-na 吧… (Nick Butcher 做无奈状摇头)

首当其冲的问题是过小的触摸区域. Android Design 中专门强调过, 所有可触摸的对象都应该有至少 32dp 高, 理想的大小是 48dp, 除非你的目标用户是婴儿等手特小的人.

另一个很糟糕的错误是没有触摸反馈. 有些开发者不想使用标准的按钮控件, 但是标准按钮的好处就是它有提供触摸反馈的视觉效果. 对于用户而言, 摸到没有反馈的按钮会让他们认为你的应用 (比它本身的速度) 慢. 对于用户而言, 感知速度是他们能体会到的, 而真正的载入速度和运行速度反而没有感知速度那么容易被用户体会到. 另外, 亮起的触摸反馈还能指示出实际的触摸区域. 比如说一个列表, 当用户按下某一列表项的时候, 这一项所处的一整行都会亮起, 但是两边会留有 16dp 的空白, 这样便相当于告诉用户, 这个列表项最靠近屏幕边缘的 16dp 不是触摸区域.

第八: 设计 ≠ Photoshop

slides.007

首先, 同学们不要学习右边小图上的那个变态… 我知道大家都对 PS 能实现的各种各样的效果很在行/感兴趣, 但是不当的/过度的使用这些效果只会让你的应用看起来显得很过时, 或者更糟糕——很业余.

当你设计你的应用的时候, 请务必将注意力优先放在内容而不是那些高光上. 用户装了你的应用并不是为了看闪闪发光的按钮, 所有的这些视觉设计到最后都应该是为了内容服务, 而不是为了装饰而装饰.

另外, 请务必保证应用内视觉风格的一致性. 没用用户会希望看到一个半 Holo 半草泥马的应用 (NovaDNG: wildebeest = 牛羚, 在这句里把它换成草泥马是一个意思的…). 点名批评一下 Feedly 这种外表光鲜亮丽, 设置却像是侏罗纪时代的应用.另外, 一个应用中不应该有太多的按钮/选框/对话框样式, 一个就够了——直接调用 Android 风格的控件是个简单有效的办法.

还有一些开发者, 对于细节的忽视实在是到了令人发指的地步, 比如说不一致的 度  量/错误的间距, 鬼畜的用色 (NovaDNG:我觉得我的微信 Redesign 就这样无端中枪了…), 丧病的字体选择… 这些都是会令用户感到不爽的细节, 作为开发者没有理由忽视他们.

第七: 侏罗纪来客

slides.008

如果你的应用是 2009 年的时候做的, 那么你的用户可就要遭殃了… (Adam Koch: 他们竟然跑得起来…)

这里最先要提到的问题就是 Menu 键… 或者说, 菜单按钮的耻辱. 我们现在已经有了 Action Bar 来取代侏罗纪时代的菜单键了不是吗? 需要向下兼容也不是个借口, 因为如果你设置了适当的参数, 那么 Overflow 按钮就不会在有实体菜单键的机器上出现. 当然, 你也可以让有实体菜单键的机器强行显示 Action Overflow 来增加它的可见性. 但是, 无论怎么样, 都不要让菜单键只能通过实体 Menu 键 (在只有虚拟键的机器上就会变成 Nav Bar 右侧的三个小点) 呼出.

虽然说现在 Android 最新的 API 已经到了 Lv 18, 但是你并不一定要设置 targetSdkVersion 到 18, 只要是 16 以上就行了. 如果你把 API 设置到 Lv 14 甚至更低, 你的应用就会强制在 Nav Bar 上显示三个小点, 这对于某些设备比如 HTC One 的用户而言实在是一件不能更痛苦的事情了…

还有一种情况就是继续沿用 Android 2.3 甚至更古早的视觉风格. 这种 App 有时候看起来还算挺 Holo 的, 但是当你按下按钮或者列表项的时候, Android 2.3 样式的橙色的视觉反馈出现了 (NovaDNG: MIUI 中枪), 或者卷动的时候看到了 2.3 样式的滚动条, 或者载入的时候看到 2.3 样式的圈圈… 这绝对不是用户想要的. 说道载入时的圈圈. Roman Nurik 稍微强调了一下, Holo 样式的载入环其实是两个圈以不同的速度反向同时旋转, 能够制造出比起单圈更为顺滑的动画.

第六: 纯血的杂种 Android

slides.009

啊, 说道我最讨厌的地方了… 这里的原则性问题是, 不要违背”纯血 Android“的规约.

就和标题一样, 这一章的内容是在说, 不要从别的平台上搬运元素到 Android 上. 这个问题我在往期的文章里也提到过很多次, 这里就不展开说了.几个特别要注意也是常见的错误:

右箭头. 次级导航在 Android 上是没有水平方向的映射的. 换句话说, 次级导航横向导航是两码事.

底部标签栏.  对于 Android 而言, 顶部才是属于标签栏的位置.

从其他平台”借鉴”视觉样式. Android 用户想要的是 Android 应用 (NovaDNG: 嗯, 某些特殊的天朝用户除外).

第五: 导航就是我的品牌

slides.010

不要试着重新发明轮子. 应用中导航在 Android 中已经有了成熟的定义. 把应用名称放在 Action Bar 中间, 或者用 iOS 样式的 Top Bar 都是很愚蠢的行为. 请直接用 ActionBarCompat. 如果有需要在更早的版本上实现 Action Bar, 那么 Action Bar Sherlock 也不失为一个好的选择.

另外, Drawer 是用来放主要的导航元素的, 像搜索和设置之类的东西放进 Overflow 就行了. 另外, 屏幕内容滑动露出 Drawer 这种方式也是不建议的 (NovaDNG: 其实我不太理解为什么不建议… 照理来说这种滑出方式也有其适用的地方, 不应该禁止的).  实际上我也有专门的介绍过新式的 Drawer, 详情请移步早先的文章.

slides.011

既然这篇文章讲的是误区, 那么这里就尤其要强调一下不应该放进 Drawer 的东西. 首先最上面的主页探索购物和个人资料是完全没问题的. 中间的搜索应该放进 Action Bar, 因为这是一个很常见的”动作“, 而且不是一个”导航元素” (NovaDNG: 在节目中 Roman Nurik 给出的理由居然是按照平台惯例… _(:3」∠)_). 设置, 帮助, 关于和反馈都是应该放进 Action Overflow 的东西. 另外, 广告什么的绝对不要有. 也没有必要在 Drawer 中推广自己的 App. 这些东西放进”关于”里倒是可以的. 至于”我姐妹的朋友有个网站我保证它很有意思请务必去看看”这种东西, 趁早删了为妙…

第四: 自制的非 Android 风格的分享

slides.012

首先注意一下, 这里提供的三个截图都是正面的例子. (NovaDNG: 心地善良的 Adam Koch… 想看反例的, 自己打开微信看去)

实际上, 强大的应用间分享一直是 Android 的强项. Android 系统也提供了很方便的分享功能 (ACTION_SEND). 开发者完全没必要也不应该人为的把分享的目标限定在某几个应用上. 另外, 自制的, 符合 Android Design 的分享功能也是不错的选择, 比如右图的 Timely, 还有没出现在图片中的 Pocket. 它们针对分享的内容 (文章和应用) 默认列出了几个比较推荐的分享方式, 同时也允许用户点击 More 来选择其它的应用, 免得用户面对一长条的列表不知所措.

第三: 利用 WebView 来模仿原生应用

slides.013

如果你上过 YouTube 的话应该不难看出, 左边的应用整个就是源自 YouTube 网页版的 ADiA 播放列表, 只不过加了个 Action Bar 罢了. 而右边则是一个很不错的例子, 一个第三方的 ADiA 应用. 它采用了响应式设计和原生界面, 集成了 Google+ 的评论和话题功能, 提供每期 ADiA 幻灯片的查看功能, 还有节目提醒, 是一个非常棒的应用.

利用 WebView 来模拟原生应用并不是个聪明的选择, 因为实际上他的性质是欺骗用户. 如果你试图用 WebView 来呈现 Android 的核心 UI 控件, 效果不会很好. 而且, 这么做也会造成运行效率的降低, 于用户而言就是不顺滑, 反应慢.

不要仅仅是为了”登陆 Android 平台”而把一个 web app 打包成 APK 发布. Web App 就让它以 web App 的形态存在吧. Android 欢迎 web Apps. 用户可以把 web Apps 以书签的形式固定在桌面, 完全没必要专门发布一个伪装成本地应用的 web App. 实际上, 用户使用浏览器的时间越来越多了, 浏览器的平均性能也在不断提升, 你并不会因为没有发布本地应用就流失用户. 所以完全不必要为此担心.

当然, 并不是说完全的禁止使用 WebView. 举个例子, GMail 就采用了 HTML 来渲染邮件内容并且效果很棒, 四次元之前也一直是采用 WebView 来进行图片浏览.

第二: 贫弱的首屏交互

slides.015

无论对于什么样的应用, 首屏的重要性都是不言而喻的. 开门见山的要用户注册, 使用启动画面都是很糟糕的. 用户更希望应用能直接给它带来内容, 而登录和注册都最好留到万不得已的时候再做 (微博这样的东西除外). 另外, 先让用户明白你的应用到底是干嘛的, 然后再要求注册, 是比较合理的.

而正确的做法则是应该整合流行的社交网络登录选项 (NovaDNG: 国外是 Fb 鸟博和 G+, 国内的话… 微博是个不错的选择…), 并且检测用户是否已经安装了它们的客户端, 如果有, 就可以直接通过客户端验证登录, 能够大大减少输入用户名和密码的麻烦. 实际上, 你可以做尽可能多的事情帮助用户快速通过注册和登录, 而不是让他们感到烦躁. 在这方面, 整合 G+ 登录的应用的体验就是极好的, 我只需要按下登录按钮, 选择账户, 许可权限就行了, 比起国内各种应用的输入用户名/邮箱/密码要便捷太多.

另外, 你也可以采用展示动画/图片幻灯来告诉用户你的应用是干什么的. 这方面做得很好的是 Next Browser.

第一: Android ≠ 竖屏手机

slides.016

Android 设备千千万, 并不是只有竖屏的手机. 糟糕的平板支持或者横屏支持只会给你的品牌带来负面的影响.

有很多人确实是会横着用手机的, 比如说那些用车载底座/充电底座的用户. (NovaDNG: MIUI 如果我没记错的话, 自带应用都不支持横屏…) 横屏支持的方式有很多, 请挑选最合适的方案. 而且这里的重点其实是, 不要强迫用户只使用某个方向的设备.

另外, Android 平板的占有率也在不断变多, 虽然手机和平板间的界限越来越模糊, 但这可不是不提供平板支持/优化的接口. Android 设备几乎囊括了从 3″ 到 10″ 间的所有尺寸, 所以合理的利用响应式设计吧, 它能提供更为合理的多屏支持. 仔细考虑留白, 布局和其他设计, 不要忽视那些平板用户. 只要一两个小时的 XML 工作就能让你做到很多东西.

 

slides.018

到这里, 十大常见错误就都说完了. 如果你觉得还有什么常见的错误, 请在评论或者微博评论或者 G+ 评论中告诉我~

最后, 一如既往的感谢 +Roman Nurik+Nick Butcher 和 +Adam Koch 的 Android Design in Action 活动.

Android Design 趋势——Navigation Drawer

titlecard_empty

关注 Android Design 的同学可能都会知道, 自从 Google I/O 2013 的 Android Design Section 上专门讲解了 Drawer 和 Google 自家应用纷纷涌上 Drawer 之后, 这个刚刚正式加入 Android Design 中没多久的新导航方式一下子就火了起来, Google 应用之外的第三方应用们纷纷尝试使用新的 Drawer, 有的也获得了不错的成效, 但是有些应用却比较失败.

Drawer 作为新一代 Android Design 的代表之一, 具有非常高的泛用性. 很多旧的导航方式都可以无违和的被 Drawer 替代. 这次的 Android Design 研究会, 我们就来总结一下现在可以透露的关于 Navigation Drawer 的情报.

Drawer 的历史

要了解现在的 Drawer, 就不得不提提他的历史. 在最早的时候, Drawer 还不是现在这个样子的. 第一个应用了 Drawer 交互的 Google 应用是天朝人民不甚熟稔的 YouTube.

AndroidDesignInAction_NavigationDrawer.01-01

可以看出, YouTube 中使用的 Drawer 和现在我们熟悉的 Drawer 还是有很大的不同的. 它使用了 Up 箭头作为指示, 展开的方式是内容向右侧滑动使 Drawer 露出. 而在 YouTube 之外, Google 方面也对 Drawer 进行了一番研究.

AndroidDesignInAction_NavigationDrawer.01-02

稍微解释一下这张图. 图中出现了几种对于 Drawer 的 Up 和 Back 的探讨. Hidden View Changer 的特性是, 只有通过 Up 才能唤出 Drawer, 在抽屉按下 Back 则会返回应用主界面; 而 Hidden Home 则是在应用的主界面和 Drawer 打开的状况下按 Back 都可以退回上一界面; Hidden Shortcuts 的情况下, Back 不会返回到”上一画面”, 而是和 Up 一样返回到(Drawer 未展开的)上级界面; 至于 True Home 则是把 Drawer 作为真正的主界面, 在列表下按下 Back 或者 Up 都会打开 Drawer, 而只有在 Drawer 中才能通过 Back 返回上一画面. 这些交互方案各有特点, 基本上包含了当前见到的绝大多数 Drawer 的操作逻辑.

AndroidDesignInAction_NavigationDrawer.01-03

这张图则是说明了 Android 团队尝试的各种 Drawer 标识. 从最早的 Up 箭头到反 Up 箭头(右箭头), 甚至还有诡异的 Contextual Action Bar 样式, 结果最后被采用的还是三条横杠的指示. 顺便说个顺便说个有趣的事儿, 这三条横杠被 Android 团队内部人员戏称为 “Hamberger(汉堡)”. 实际上 Google 并没有强制开发者使用这三条横杠. 反正我是觉得这三条横杠不好看…

AndroidDesignInAction_NavigationDrawer.01-04

除了单击应用图标区域之外, Google 团队认为 Drawer 应该也能通过更方便的方式触发. 毕竟现在手机的屏幕越做越大, 大屏手机上想要触到左上角的区域还真不是一般的蛋疼. Android Design 团队选择了使用了左侧滑入这一手势.

Drawer 的优势

在 Drawer 之前, 开发者们大多数使用的是下面几种导航方式: 腹肌式(Six-pack), 下拉栏式, 还有 Tab 式.

AndroidDesignInAction_NavigationDrawer.01-06

这三种交互方式也算是各有各的好处. 对于腹肌式的导航而言, 直观的排列展示所有的分类. 下拉栏式的好处在于直接展示内容的同时占用的空间小, 可以把 Action Bar 的空间留给 Action Overflow 和其他常用操作. 而 Tabs 的优点则是在直接展示内容的同时可以快速的切换分类.

AndroidDesignInAction_NavigationDrawer.01-07

而不同的导航方式则提供了在顶级视图(如上段举例中的”分类”)间切换的途径. 但是在能够切换顶级视图的情况下, 想要在非顶级视图间导航就略显麻烦了——用户必须退回顶级视图, 在顶级视图切换分类之后再进入别的内容. 这个时候, 就应当是 Drawer 登场的时候了.

AndroidDesignInAction_NavigationDrawer.01-08

Drawer 的好处就是能够提供在非顶级视图间导航的能力. 以上图为例, 假设一个应用最常被用到的界面是顶级视图的 1, 2, 3, 4, 和非顶级视图的 3.3, 4.2, 如果使用其他的导航方式, 想要从 3.3 到 4.2 就会使一个万分痛苦的过程. 而如果引入了 Drawer 这种导航方式, 想要从 3.3 到 4.2 就只需要把 Drawer 拉出, 点击 4.2, 完成~

说了这么多, 什么情况下该使用 Drawer 呢? 这里总结一下: 当你有三个以上的顶级视图, 有很深的导航层级, 需要在很深的层级中添加导航中枢, 需要用到十字导航, 或者需要更好的内容结构的时候, 就应该考虑使用 Drawer 了.

Drawer 的一般结构

Drawer 作为一个方便的导航方式, 比起几种老式的导航方式而言会更经常被用户接触到, 而且结构也可以做得更加复杂(基本上 Spinner 和 Tabs 就只能做成标准的形式, 顶多加个分类或者开关什么的). 而如何做一个结构优美的 Drawer 呢?

AndroidDesignInAction_NavigationDrawer.01-10

由于 Drawer 的可定制性很高, 你可以轻松的在其中加入可以展开/折叠的导航, 图片, 未读计数来使它变得更加美观和易用. 当然, 你也可以向Drawer 里面加入单选按钮(比如 Gmail 的账户选择)或者 Spinners(比如新的 Drive 的账户选择). 合理的对 Drawer 进行布局会使得 Drawer 起到事半功倍的效果.

提升易用性

当用户第一次使用带有 Drawer 的应用的时候, 他们不一定会意识到 Drawer 的存在. 这时候就需要对他们进行合理的引导.

AndroidDesignInAction_NavigationDrawer.01-11

如上图所示, 在第一次进入应用的时候, 可以自动展开 Drawer 让用户知晓 Drawer 的存在. 而通过 Back 则返回到应用的主界面.

AndroidDesignInAction_NavigationDrawer.01-12

同样的, 在用户触摸到屏幕左侧边缘的时候, 让列表内容的亮度稍微降低, 左侧的 Drawer 则稍稍露出一条, 让用户意识到”这里有个东西, 我可以把它拉出来”.

Drawer 的标识

前面提到, Google 应用自己的 Drawer 标识是三条横杠.

AndroidDesignInAction_NavigationDrawer.01-13

但是并不是意味着所有的能召出 Drawer 的地方都要用三条杠. 而在导航枢纽的非顶级页面上也可以放上三道杠.

另外, 自制标识也是一个很好的选择, 不过需要注意的就是要能够标识 Drawer 打开和关闭的状态, 而在两个状态间能够渐变切换(官方的汉堡是伸长/缩短).

一些例子

AndroidDesignInAction_NavigationDrawer.01-16

作为新一代 Drawer 的代表性应用, Gmail 使用的 Drawer 承担了两个任务: 切换用户和切换分类/标签. 在这里, Drawer 只能在顶级页面中被召出. 而且实际上, 在 Gmail 应用中, 左上角唤出 Drawer 的触发区域不单单是 Gmail 图标, 整个标签名/邮箱地址都是触发区域(和以前的 Spinner 的触发区域是一致的). 而列表标题和列表项的使用制造出了层级结构和分层, 并使其显得井井有条.

另外你也可以注意到, 在 Drawer 打开之后, 搜索和新邮件按钮消失了. 来自 Android 团队的解释是, 移出这两个按钮是为了让用户更好的把注意力集中在复杂的 Drawer 内容中.

AndroidDesignInAction_NavigationDrawer.01-17

而在 Play Music 和 Play Books 中, Drawer 则是和 Spinner 一起使用. 而且在 Music 中, 在除了设置和正在播放界面之外的任何界面都可以从左侧滑出 Drawer. 另外还有一个小细节, 这张图上的 Play Music 是一个早期版本的 Play Music, Radio 依然还是 Instant Mixes.

AndroidDesignInAction_NavigationDrawer.01-18

Earth 应用中的 Drawer 则有些特别, 他是作为图层/功能开关和层级切换的用处. 实际上, 对于 Earth 而言, 切换顶级界面并不是常用功能(对于 Earth 而言顶级界面就只有这个主视图), 而且它也没有传统意义上的 Action Bar——取而代之的是一个搜索栏, 因为这对于 Earth 而言是个更重要的功能. 这实际上从侧面证明了某些情况下并不必要完全遵循 Android Design 也可以做出不错的应用.

AndroidDesignInAction_NavigationDrawer.01-19

而 One Today 在这里作为例子出现其实是证明了右侧 Drawer 存在的可能性. 右侧 Drawer 的触发方式也有两种, 单击右上角的未读计数或者从右侧边缘滑入. 在 Google 自家的应用中, 右侧 Drawer 基本上专注于通知. 而在右侧 Drawer 展开的情况下, 点击应用 Logo 区域(包括 Notification 文字这块区域)会看到右侧 Drawer 退回的同时左侧 Drawer 弹出, 煞是有趣. 和 One Today 性质类似的还有 Google+ 的通知, 不过 Google+ 的通知是整个主界面内容区向左滑动露出 Drawer, 而且不能通过右侧边缘滑入来打开.

其他 Drawer 实现(非 Google 应用)

早在 Google 使用 Drawer 之前, 就有很多应用尝试了 Drawer 的使用. Drawer 的呈现形式可以说是五花八门: 保留/不保留 Action Bar, Drawer 位于内容的上方/下方, 内容保持不动/滑开, Drawer 以从底部浮现的方式出现… 等等等等. 有兴趣的开发者可以下载 SlidingMenu Demo 来看看这些五花八门且不乏创意的实践.

而 Android 团队则认为关于自定义 Drawer, 有两点值得注意. 首先是 Action Bar 最好保持不动. 毕竟一般情况下, 应用的 Logo 还是在 Action Bar 上, 而且还有最常用的操作按钮和 Action Overflow. 当然, 如果应用 Logo 不再 Action Bar 上, 也没有常用操作按钮等(比如 Falcon Pro), 那么 Action Bar 就可以随便移动了. 另外, 如果采用的是全局式的 Drawer 触发(就是在主界面上随意区域向右拖动都能触发 Drawer), 那么建议的动画形式是整个内容区域右移——这动画的隐喻和边缘滑入动画的不太一样, 边缘滑入的动画是”拉出 Drawer”, 内容区域滑动则是”露出 Drawer”.

另外, 如果采用了”内容区滑动”型 Drawer 的话, 在内容区域就不建议采用横向滑动的手势了, 毕竟两种操作会产生冲突(悲剧的抚波在一开始的版本中就遇到了这个问题). 在这一点上新版的四次元就做得很好, 大家可以期待一下.

什么地方不适合 Drawer

如果你的应用需要非常经常的在不同视图/分类中切换, 那么需要滑出的 Drawer 显然是个糟糕的方案(这也解释了为什么 Play Store 使用了 Fixed Tabs + Spinner 而不是 Drawer 来进行导航). 还有前面说过的, 如果你只有三个或者更少的顶级视图, 那么 Drawer 存在的必要性其实很低(就这点而言, Play Books 的 Drawer 其实很不必要… 实际上我个人也更喜欢原来的 Play Books).

最后也是最重要的一点: 想要让 Drawer 发挥最大的效果, 合理的设计应用的层级结构是非常重要的. 如果一个应用的层级结构很糟糕, Drawer 也是救不了它的. Drawer 不是万灵药.

感谢 +Roman Nurik+Nick Butcher, +Richard Fulcher 和 +Jens Nagel 的 Android Design in Action 活动. 你可以在他们的 Google+ 上看到很多关于 Android Design 的讨论. Android Design 研究会这个板块的大多数内容也将来自他们. 实际上, 你可以放心的在 Google+ 上和他们搭话, 一般会得到很友好的回复.

本期 ADiA 的 Android Design 相关内容: Patterns – Navigation Drawer.