思缘教程网欢迎你! 思缘旧版思缘图库思缘论坛软件下载网站登陆加入思缘

设计师解读移动APP中Loading设计

文章来源于 优设,感谢作者 Qinsman 给我们带来经精彩的文章!
思缘教程/前端设计/前端设计2017-12-17
设计移动端应用产品时,我们绝大多数的精力和时间都会花在各个页面的设计上。但与此同时,网络环境的复杂性,会造成在网速偏慢、弱网、无网的条件下,用户相当一部分停留时长会用在Loading上。

设计移动端应用产品时,我们绝大多数的精力和时间都会花在各个页面的设计上。但与此同时,网络环境的复杂性,会造成在网速偏慢、弱网、无网的条件下,用户相当一部分停留时长会用在Loading上——无论页面最终呈现出来的状态我们设计得多么精美,它的加载总是需要一个过程。

设计师解读移动APP中Loading设计,PS教程,思缘教程网

而页面打开和跳转时的加载过程,很多时候会在设计中被严重忽视,最后在项目上线前仓促、随意地进行设计,甚至任由开发找一个「菊花」放上去转一转就完事了。

Loading过程的设计缺失对用户体验的伤害无法量化,但长此以往,犹如一剂慢性毒药,总有突破用户忍耐极限,导致用户流失的一天。

本文将简单梳理移动端应用设计中常见的加载模式,并结合一些国内外应用的实例,探讨如何针对场景特点选用合适的加载方式。

一. 模态加载

提到加载方式的分类,最明确的一个界限应该就是模态加载和非模态加载。而说起模态加载,可能有人会根据一些经典书籍中的观点认为模态一定是不好的,非模态才是正义。

但事实上,选用模态加载还是非模态加载,首先要做的是问自己一个问题,这个加载是否出现在不可逆流程?

1. 模态加载与「不可逆流程」

这里说的「不可逆」并非表达平日语境下「无法挽回」的含义,只是指一些单向通行的线性流程。典型如注册类(注册、登录、找回密码)、交易类(下单、支付、转账)流程,比如下图易信的注册流程和微信发红包的流程。

设计师解读移动APP中Loading设计,PS教程,思缘教程网

在不可逆流程中,一个步骤加载时如果允许用户随意触发其他行为,极易导致各种分支和异常。为了防止用户犯错,也为了设计和开发时减少异常流数量,在这类流程中使用模态加载是很正常的选择。

2. 其他场景下,避免模态阻断

而在无关不可逆路径的情况下,确实如经典论述所说的,应该减少模态阻断的使用。

采用模态加载则会让用户在等待期间无所事事,等待时间较长时会加剧焦躁情绪的产生。尤其是一些APP直接在启动页采用模态加载,这会导致用户感觉与产品每次见面都有一道无法逾越的鸿沟。

在国内,这种情况已经比较少了。不过少数金融类的APP仍然会直接在启动页进行阻断式的模态加载,考虑到金融类APP需要保障资金安全,这样的处理方式可能有一些行业特殊性。

设计师解读移动APP中Loading设计,PS教程,思缘教程网

一贯传统的日本,时至如今,很多APP仍然保留了在登录页就模态加载的习惯。即使是毫无阻断必要的。

电商类APP和交通查询类APP也是如此,以服饰电商ZOZOTOWN和东京メトロ为例。

设计师解读移动APP中Loading设计,PS教程,思缘教程网

当然,这两个APP实际上内部的设计质量已经非常不错了,有许多细节是值得借鉴的,这里只是就事论事讨论它们的启动加载问题。

它们在启动加载中使用了蒙层式的模态加载,即使东京メトロ设计了极富特色的加载指示符(9个代表不同线路的小圆圈),仍然改变不了一种将用户拒之门外的隔阂感。

如果说电商APP的启动多是在用户较为闲暇、安静的场景,模态登录带来的伤害相对较小。那么交通查询类APP就不一样了,启动场景多是在户外移动,急于知道结果以确定下一步往哪走的情形之下,更不适合使用模态加载。地铁查询APP更为特殊,很大比例的场景是用户正在地铁中查询换乘信息,在信号不佳的情况下直接模态阻断,这样的体验是致命的。

综上,我的判断是,除了不可逆流程外,基本上没太大必要去使用模态加载。

百度地图在搜索地点中使用了模态,相比之下,而iOS自带的地图,搜索地点就没有采取模态加载,用户可以在不耐烦时随时尝试其他操作,体验上的差别显而易见。

设计师解读移动APP中Loading设计,PS教程,思缘教程网

3. 模态阻断要有「取消」选项

即使确信模态加载是正确的,最好也给用户一个「取消」的选项,避免用户只有杀掉进程以结束漫长的等待。

上面例子中,百度地图的搜索采用模态或许必要性不大,但至少设计师意识到了「取消」选项的重要性,用户在加载过程过慢时可以随时点击「×」终止行为。

反例是EBAY的登录页,上面有一个「×」,会让用户误以为是「取消」,但实际上是关闭登录页的按钮,在登录加载过程中是无法点击的。弱网环境下的用户唯有漫长的等待,唯一能做的就是杀掉进程。用户被卡住后不停地点击「×」却毫无反应,带来的焦躁和挫败感可想而知。

设计师解读移动APP中Loading设计,PS教程,思缘教程网

二. 整屏加载

另一类常见的加载严格来说不属于模态,因为对于产品整体来说,用户可以自由选择执行其他操作,但对当前正在浏览的内容层而言却又是一种阻断性的加载。准确的描述应该称为「局部模态」或者「内容层模态加载」,这里为了叙述方便,简称为「整屏加载」。

1. 整屏加载

原生应用的整屏加载,常见的做法是内容区整体保持空白,中间或内容区顶部有加载提示符(多数是Spinner,就是我们俗称的转菊花)告知用户耐心等待,直至所有数据请求就绪,再整体展示整个页面。

整屏加载是最简单的一种加载处理方法,适用于页面中所有数据,每次查看都需要重新请求、不存在本地数据的情况。在知乎、Behance、Airbnb、网易云音乐、ENJOY、熊猫直播等各类型的APP中都有广泛应用。

设计师解读移动APP中Loading设计,PS教程,思缘教程网

设计师解读移动APP中Loading设计,PS教程,思缘教程网

设计师解读移动APP中Loading设计,PS教程,思缘教程网

整屏加载的本质是内容层的模态加载,因此和模态加载一样,需要一个明确的超时判断,在超过指定时间数据仍未请求成功时,告知用户可能存在的原因和下一步行动点,避免一直卡在加载进程中。

告知加载失败的结果时,融合一些品牌特征和情感化设计,可以有效缓解用户加载失败的挫败情绪,甚至会在心底给产品设计的用心加分。

设计师解读移动APP中Loading设计,PS教程,思缘教程网

2. 浏览器加载

浏览器加载,是浏览器APP中最常见到的加载呈现方式——在地址栏下方以线性进度条的形式告知用户当前加载进度。

同时,许多原生APP中也有加载Web页面的场景。在调用内置浏览器内核的时候,就会自然而然地继承很多浏览器的交互形式。例如微信内置的是QQ浏览器内核,所以在加载公众号、朋友圈文章等Web页面时,会在顶栏下显示迷你进度条。

设计师解读移动APP中Loading设计,PS教程,思缘教程网

3. 为什么整屏加载不像浏览器加载一样展示具体进度?

这里稍微延伸一个问题。

关于Loading的很多论述中都提到,加载提示符如果有进度提示,可以更好地让用户对等待时间有一个预期,有效地减轻等待的未知感和焦躁情绪。

这句话本身毫无疑问是有道理的。但我们回想一下,除了浏览器加载之外,无论是一个普通应用,还是以重视设计、关心用户体验著称的应用中整屏加载时,为什么都很少见到带进度信息的加载提示符,而是广泛地使用Spinner和它各式各样的衍生形式?

我个人的判断是,移动端应用需要让用户忽略等待时间,减少具体进度带来的压迫,所以通常都要求速度极快(在网速正常的情况下),这种情况下进度条连看都看不清,自然没有必要一闪而过。原生页面的加载,通常情况下也比一个Web页面从DOM开始加载的速度要快,所以无论于目标于能力,都不需要也不适合具体进度的展示。反观Web页面的加载,一方面平均耗时较长,另一方面也有继承PC端遗留习惯的因素,所以展示进度条就成了一个不成文的惯例。

其次,告知用户真实加载进度的愿望很美好,而现实很骨感,绝大多数情况下,资源的加载时间都是不固定且无法预知的。预先判断需要请求的数据量并迅速折算出真实进度,对开发来说并不是一件容易的事。即使做到了,真实的加载进度实际上是「一卡一卡」非常不流畅的过程。

所以,在浏览器加载中,我们所看到流畅推进的进度条,多数都是假的,所以会经常出现进度条走到99%,页面实际加载完毕还遥遥无期的情况。

浏览器的进度判断是通过监听加载状态实现的。而在大量结构标签和内容数据的加载中,只有为数不多的节点会有事件产生,最容易想到的自然是开始和结束两个节点。很多情况下,会在DNS解析和资源下载完成时就让进度条跑到90%甚至99%,但后续的加载过程有时远比下载过程更耗时,所以卡节点的情况在所难免。

这里补充一个设计上的小技巧,两个节点之间同样的进度条,相比匀速前进、按真实节点前进,先快后慢地前进能让用户产生加载更快的错觉。虽然是种假象,但用户需要的就是这样的假象。

三. 非模态加载

1. 标题栏加载

IM、邮箱这类应用在内容加载上特点非常鲜明。首先,这类应用的大量数据都是存在本地的;其次,本地数据的浏览在任何情况下都不应该受制于网络速度。试想,没信号的时候连历史聊天记录都看不了是一件多么可怕的事情。

因此,在这类应用中通常会在顶栏(也有在底栏)显示加载提示符(通常是以文字+Spinner的形式),这里简称为标题栏加载。这种方式的优势在于不妨碍用户在内容区点击查看任何已有消息。

设计师解读移动APP中Loading设计,PS教程,思缘教程网

你可能感兴趣的教程
版权所有思缘教程网公安备案:苏公网安备 32058302001023号工信部备案:沪ICP备09005587号
aaa