Android UI 及 API 优化指南|Android 开发者 FAQ Vol.10

624 阅读9分钟

作为应用的设计者,有些开发者在开发过程中容易忽略一些用户体验方面的问题,从而导致了自己的应用用户体验欠佳。本期 Android 开发者 FAQ 我们整理了一些开发者们在后台留言的关于 UI 和 API 在用户体验方面的问题,为大家带来了 UI 及 API 的优化指南。

Q:用户说我的应用在处理信息时提示不明确,老是会误以为程序失去响应了,有什么好的方法改进吗?

A:系统应该在合理时间内给予适当反馈,让用户随时了解系统状态。

在 UI 方面,如果用户进行操作后需要等待一段时间,那么此时,系统就应当告知用户操作完成进度。与加载图标相比,我们更建议开发者采用进度条,并在上面显示上传或者下载百分比。这样用户就可以知道自己在等什么,还要等多久。

△ 告知用户操作完成进度

而在 API 方面,API 应该提供查询当前进度的方法。例如:开发者可以通过 AnimatedVectorDrawable 类来查看动画究竟是否在运行状态: boolean isAnimationRunning = avd.isRunning();

API 可以借助某种回调机制提供反馈:当对象状态发生变更时,通知 API 用户 —— 有点类似于动画开始和结束时的推送通知。AnimatedVectorDrawable 对象就允许通过注册 AnimationCallback 函数,达到上述目的。

Q:“撤回” 的操作在变得越来越流行,这类功能有什么意义呢?如何在我的应用内加入类似的功能?

A:给予用户撤回操作的权利,会让您的应用变得更加友好易用。

在 UI 方面,有时用户进行的操作可能会产生歧义,例如删除和归档邮件,此时系统应当弹出信息确认操作,并提供撤回选项。

△ 允许用户撤回某些操作

而 API 应允许用户 “放弃” 和 “重置” 操作,方便 API 返回正常状态。比如,Retrofit 中的 Call#cancel 可以取消已经发送的网络调用请求或者确保该调用永远不会被执行(前提是在使用 Call#cancel 前,执行尚未发生)。而通过 NotificationManager API,开发者既可以创建又能够取消消息通知。

Q:有用户反馈说我的应用和其他的产品 “不一样”,进行某些按钮和手势操作后没有进行他们预想的功能,我该去哪里了解其他开发者都是怎么设置这些内容的呢?

A:好的应用,不应该让用户对不同的措辞、情况和操作究竟指的是不是一件事而感到烦恼。

在使用您的 App 之前,用户已经接触过许多别的 App,因此他们会期望常见的交互元素在各个 App 之间保持一致性。一旦脱离常规,就容易产生错误。

因此开发者须要和平台保持一致性,并且采用用户熟知的 UI 控件,确保用户能够快速识别并使用它们。此外,开发者自己的 App 也须要保持一致性:多屏操作 App 时,采用相同的用词和图标表示同种操作。例如,保持编辑图标统一,让用户可以在 App 内编辑多种元素。

△ 对话框应和平台统一

至于 API,所有设计应当保持统一,如方法命名应一致;方法内容相同,名字也务必相同;方法中参数排序也要保持一致,等等。

Q:我觉得进行很多操作都额外弹出提示可能会让部分用户感到厌烦,那么究竟怎样的设计才能在不打扰用户和可靠之间找到平衡?

A:从一开始就预防用户在使用中 “犯错” 的发生,是开发者应当遵循的一个原则。

很多情况下,用户无法一直专注于手头的任务,因此开发者应该正确引导,以防用户无意识犯下无法补救的错误。譬如,在进行破坏性行为(比如删除)前先获取用户同意,或者设定良好的默认值。

比如说,Google Photos 添加了确认对话框,避免用户不小心删除相册。而收件箱的闹钟功能(让邮件打个盹儿),则可以一键设定在某段时间后让邮件重新出现在眼前。

△ 在破坏性行为前,Google Photo 会要求用户先进行确认。收件箱一键设定时间,让邮件打个盹儿。

API 应该正确引导用户使用 API,在需要的地方使用默认值。API 应该操作简单容易上手。开发者可以通过提供默认值,帮助用户使用 API。比如说,当创建 Room 数据库时,其中一个默认值可以保证在数据库版本升级过程中,数据量保持不变。这意味着基于 Room 开发的 App 可用性大大增强,因为数据没丢而且数据库版本也是透明的。

而 Room 中的另一个方法 fallbackToDestructiveMigration 则可以更改此行为:在未提供数据迁移的情况下,数据库版本变更后,该方法能够破坏并重建数据库。

Q:有越来越多的操作符号已经在用户的心中形成了固有印象,是跟随潮流使用这些东西,还是用一些有新意的元素装点我的应用好呢?

A:识别出熟悉的对象造成的认知负荷最低,也容易被场景触发;“回忆” 则要求主体从记忆中追溯细节,花费更长的时间。因此挑出满意的选项远比从记忆中 “读取” 选项要来的容易。就 UI 设计来说,“识别” 派的交互界面多使用用户熟悉的图标,而 “回忆” 派则以命令行见长。信息和功能应尽量可视化、直观化并且易获取。

△ 比如,用铅笔图标表示编辑功能,就算 App 不同,用户也能容易辨认,这类已经被广泛接受的图标最好不要轻易自行设计。

Q:我的应用功能有点多,但有些用户说我的应用功能很丰富,他们喜欢尝试里面的各种功能,也有一些告诉我我的应用看上去眼花缭乱,让他们不知道怎么用,有什么好的解决方法吗?

A:App 的用户可能是操作熟练的老手,也可能是没有经验的新手。因此在设计 UI 时,您应该把两种情况都考虑到,让他们都可以逐渐熟悉 App 操作。据统计,App 内只有 20% 的功能使用量达到 80%,这要求开发者在 “简洁界面” 和 “强大功能” 达到一种平衡。找到属于您 App 中的 20% 常用功能,让这部分功能尽量简单易上手。在设计过程中应用 “逐渐披露原则”,让其余用户在下拉页面获取高级功能选项。

△ 比如,在 Android 系统中,Wi-Fi 设定主页面上显示基本选项,下拉出现高级选项,可以满足各类用户需求。

Q:对无关信息屏蔽似乎可以提升用户的专注度,有哪些方法可以强化这点呢?

A:UI 的设计应该简约,仅包含和用户有关的信息。无关紧要或者几乎用不到的信息应剔除或者转移到其它屏幕,避免用户分心,或者弱化重要信息。

△ Pocket Casts 的移动端 App 采用极简设计

比如上图播客 App 的节目列表界面就仅仅显示了最精、最有用的信息:如果用户无法下载节目,界面内就会显示下载文件大小和下载键;如果用户已经完成下载,就显示节目长度和播放键。同时所有上述内容和其他信息都会显示在详情页面中,满足好奇心强的用户需求。

API 用户只有一个目的:用 API 更快解决问题。所以让您的 API 快准狠,用最少的时间,最有效的方法,解决用户痛点。所以,请不要暴露 API 内部逻辑,API 做到的,不要劳烦用户自己做。

API:从 22.1.0 版本起,Android 支持库就开始提供 RecyclerView 扩展包,让开发者能够借助大数据集和易变数据更好地设计 UI 界面元素。如果列表发生改变,开发者需要在 RecyclerView.Adapter 内更新相关数据。这意味着开发者需要自己去解决不同列表之间的差异运算问题。从 25.1.0 开始,支持库引入 DiffUtil 帮开发者免去这个枯燥的苦差事。DiffUtil 采用优化算法,减少开发者代码编写量,同时提高性能。

Q:这个年代,帮助文档还有必要存在吗?会不会显得我的应用像个老古董?

A:用户无须借助文档应该就能使用您的 App。不过对于复杂程度或者领域专业性很高的 App,可能有点不切现实。如果不得不撰写文档,请确保文档覆盖所有常见问题而且能轻松找到。

△ 导航侧边栏底部常见 “帮助 ”和 “反馈” 选项

API 应 “自文档化”,方法、类和成员如果命名恰当,就好比于 API 自己给自己写了文档。但是不论一个 API 有多棒,文档都是必不可少的。这也就是为何所有公开内容 —— 方法、类、域、参数 —— 都应该具备相应文档。API 使用者应该和 API 开发者一样觉得 API 简单明了。

以上便是今年最后一期 FAQ 的全部内容,希望阅读了这些解答后,您可以使用这些方法将自己的应用在 UI 和 API 层面调整得更加简单易用。回顾 2017,我们的开发者 FAQ 已经做了 10 期,不知道这些文章是否对您有所帮助呢?
如果您还有其他问题,欢迎在我们的公众平台留言,我们将定期选取关注度高的问题集中解答,帮助您提升自己的开发实力,我们明年再见!