Android 应用中十大导航设计错误

标签: android 应用 十大导 | 发表时间:2014-02-26 12:02 | 作者:NovaDNG
出处:http://www.geekpark.net/

作者头像
作者: NovaDNG / 产品观察家
曾经热爱 Metro UI, 对 Android Design 了解深入. 现在在美国读大学. 经营团队博客"锋客网".
[核心提示]这一次,我们就设计错误的话题展开,指出一些大家在安卓开发领域设计应用导航时经常被犯下的错误以便更好的避免他们。

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

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

1. 将导航项放在 Action Overflow 里

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

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

2. 错误的导航层级

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

 

上图呢才是一般情况下的正确做法。通常情况下,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。

 

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

 

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

4. 深层/顽固的 Tabs

 

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

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

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

 

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

5. 溯回 (反向遍历) Tabs

 

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

6. 溯回 (反向遍历) Drawer

 

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

7. 深层的 Navigation Drawer

 

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

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

 

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

 

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

8. 错误的 Drawer 转场

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

 

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

 

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

9. 不显示 Up 箭头

 

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

 

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

10. 右侧导航

 

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

 

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

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

最后,一如既往的感谢 +Roman Nurik+Nick ButcherAndroid Design in Action 活动。

极客观察均为极客公园原创报道,转载请注明原文链接。

原文地址: http://www.geekpark.net/read/view/199244

关注极客公园,即时获得最新内容: Twitter | 微信:极客公园 | 新浪微博 | 花瓣网 | 人人小站 | Google+ | 点点

相关 [android 应用 十大导] 推荐:

Android 应用中十大导航设计错误

- - 极客公园-GeekPark
曾经热爱 Metro UI, 对 Android Design 了解深入. [核心提示]这一次,我们就设计错误的话题展开,指出一些大家在安卓开发领域设计应用导航时经常被犯下的错误以便更好的避免他们. 大家好,这里是 2014 年第一期正式的 ADiA 教程. 在上一次的 设计错误文章里,我们已经简略的提过了一下导航设计上的错误,这一次,我们就这个话题展开,指出一些大家在设计应用导航时经常被犯下的错误以便更好的避免他们.

GetEd2k (Android应用)

- 某牢 - eMule Fans 电骡爱好者
GetEd2k是一个Android应用程序,作者是anacletus. 此应用可以帮助你把网页中的电驴(eDonkey) 链接添加到你个人电脑的电驴客户端里,不过前提是你的客户端开启了用于远程控制的Web interface(Web服务器,网页接口,Web界面),当然,eMule(电骡), MLDonkey 和 aMule 都支持该功能,所以这三种主流电驴客户端的用户都可以使用GetEd2k.

Android 应用程序

- - CSDN博客推荐文章
Android 应用程序由四个模块构造而成:Activity、Intent 、Content Provider 、Service. 下面简单介绍一下如下模块的含义:. 1、Activity  "活动". 一个Activity就是单独的屏幕,每一个活动都被实现为一个独立的类,并且从活动基类中继承而来,活动类将会显示由视图控件组成的用户接口并对事件作出响应.

android应用框架

- - CSDN博客移动开发推荐文章
原文地址:http://developer.android.com/guide/components/fundamentals.html. android应用程序一旦装进设备,每个程序会在它自己安全的沙盒里运行. 1.android操作系统是一个多用户linux系统,每一个应用程序是一个用户. 2.默认情况下,系统会为每个app分配唯一的linux用户id(这个id只会被系统使用,并且只会被这个app知道),系统为每个app的所有文件都设置了权限,只有被分配了这个app用户ID的程序可以访问它.

Android 应用界面设计

- - 互联网的那点事...
与 iOS 相比,Android 系统界面存在各种不协调,应用界面本身缺乏统一的规范. 虽然 Android 的开放性为应用的自主发挥带来了最大的可能性,但如果系统本身能够提供标准的范例,也未必是一件坏事,毕竟许多应用并不一定需要独创的界面. 从 Android 4.0 开始,系统界面在一致性上有了许多改善,那么 Android 应用的界面应该如何设计.

Android应用性能 分析

- - CSDN博客推荐文章
  其实主要是内存方面,内存管理是个永恒的话题. 1.从工具DDMS中,在Sysinfo的tab栏里面有一个Memory usage的选项,通过USB连接Android设备以后很容易抓到图. 在图中可以看到系统随时可以用的内存是Free和Buffers两项,因为我抓图的系统只有128M的内存,所以看上去这部分可用内存已经很少了.

Android应用开发资源

- - InfoQ cn
Android应用设计和开发人员现在可以参考由Android用户体验(UX)团队官方发布的 Android设计指南. 该指南提供了开发者应该遵循的基本原则,并列出了很多细节指导,涉及 设备与显示、 主题、 触控交互、 度量与栅格、 排版、 色彩、 图标设计,以及如何 编写用户交互界面的提示语.

Android应用性能测试

- - CSDN博客推荐文章
java虚拟机有内存使用上限的限制. adb shell进入手机,这此参数被纪录在/system/build.prop中,如果想直接查看可以使用adb shell getprop. 单个应用程序最大内存限制,超过这个值会产生OOM. 单个java虚拟机最大的内存限制,超过这个值会产生OOM. android程序内存一般限制在16M,当然也有24M的,而android程序内存被分为2部分:.

ANDROID应用安全防御

- - 移动开发 - ITeye博客
Android应用的安全隐患包括三个方面:代码安全、数据安全和组件安全.   代码安全主要是指Android apk有被篡改、盗版等风险,产生代码安全的主要原因是apk很容易被反编译、重打包. 我们可以采用以下方法对apk进行保护:.   代码混淆可以在一定程度上增加apk逆向分析的难度. Android SDK从2.3开始就加入了ProGuard代码混淆功能,开发者只需进行简单的配置就可以实现对代码的混淆.