APP中的加载类型梳理与应用场景分析

2017-08-19 12:41 来源:人人都是产品经理 操作系统 /客户端

原标题：APP中的加载类型梳理与应用场景分析

文章针对APP的几类加载状态展开分析，希望能够对你有所帮助。

我们产品各模块的加载样式全部由开发自己定，结果是百花齐放，各有各的用法，前阶段被领导喷了一顿。关于加载这一块，交互规范恰好缺失，于是交互开始尝试梳理相应规范。本文梳理时，我查看了相关文章，我们部门也组织了讨论，但感觉并没有完全解决我的疑惑，于是在其基础上重新组织，扩展了一些，也咨询了一些前后端同学，本文算是我阶段性的梳理结果，拿出来和大家讨论，期待完善。

加载是什么

加载是一种反馈状态，常见样式有菊花、进度条等。用户与产品的每一次互动都需要反馈，用户依赖反馈信息，才能顺利完成连贯的操作。用户在等待反馈结果时，焦急专注的盯着界面，这时，系统需要告诉用户“hi，我还活着，正在努力干活呢，别走！” 下图摘自 Ant Design ：

什么时候使用

“1s是对话中可以有的最长间隔，又因为交互系统的操作是一个对话的形式，所以交互系统应该避免自己一方的长时间间隔，否则用户会怀疑发生了什么。系统有1s的时间去执行用户要求做的任务或者标志出操作需要多少时间，要不然用户会失去耐心”——摘自《认知与设计》

结合上面这句话，关于何时使用，我这么理解：如果系统1s内就能完成任务，可以不给加载图标，如果系统1s内不能完成任务，则需要在1s内弹出加载中的提示。

加载的逻辑

讨论加载类型前，先梳理一下加载的逻辑，这有利于我们理清楚各种加载的关系。纵轴为时间（请忽略图的配色，尽力了ಥ_ಥ）

客户端接收到用户操作后，向服务端发送请求，服务端响应然后返回数据，客户端把数据翻译成用户看的懂的元素。用户从执行操作后就一直在等待结果。客户端从发送到接收到数据这段时间在等待结果。比较耗时的是发送接收数据以及渲染展示的环节。服务器查找时间取决于服务器性能和存储等；发送耗时受网络影响；渲染展示时间取决于前端和机器性能，知道这些，就可以对症下药了，谁家的孩子，谁拎回去修理，交互能做的就是配和他们的方案，选择合适的方式，做好对用户的宣传。

用户等待时容易焦虑，用户正看着屏幕呢，于是各种加载，各种转移注意力就上场了，稳住用户，别让他离开。

第一件事：告诉用户我在工作，没有偷懒。

第二件事：转移用户注意力，减少用户等待的焦虑感，可以看看漂亮有趣的加载动画，或者浏览历史的加载内容等。

模态加载属独占姿态，会阻断用户的其他操作，加载时，用户只能眼睁睁等待。属强势女魔头，老娘最美，看我；模态加载简单粗暴，也最容易实现，但对用户来说却不友好。就像点餐一样，服务员非要等到所有菜都做好了才给端上来，客人很可能直接走人了。

模态加载一般形式是浮在页面上的旋转菊花，也可以根据自己品牌设计具有特色和情调的加载样式，我们就是因为样式混乱被领导批。

何时使用

模态加载体验不佳，但它有其合理性和不可替代性，我根据收集的页面，粗略归纳了几类，应该没有覆盖完全，关于技术方便的描述也不准确，欢迎留言补充和指正

1 加载的内容必须一起呈现出来，否则会出问题，可能是功能未准备完全，不能够使用，少给开发哥哥找麻烦；也可能因为丑，必须色香味俱全加雕花都做好。具体细节还需要跟开发同学仔细沟通。

2 旧命令正在处理中，当前不允许你再修改请求。如图2的微信发红包，系统正在处理发1元红包的请求，正在准备支付页面。此时不允许你修改金额，否则我当前处理的1元怎么办？我鱼都给你红烧了，你突然要清蒸。如果很多人都频繁的修改、提交，系统的压力应该会很大、也浪费了资源。这时候的模态是综合考量后的合理处理方式。