浮夸的“加载”菊花
前段时间，偶尔从一个同学的交互稿中看到了一个会转动的菊花，于是后来自己也把“它”拿过来用了。然后其他几个同学看到我的交互稿中，会转动的菊花时，质问我：你凭什么做那么浮夸？然后大家哄堂大笑。
后来，在做设计的过程中，逐渐关注了“加载”这件小事，就在思考“加载菊花”到底有多少种设计模式，到底该怎么用，什么时间用什么模式？在逐渐思考的过程中，心中也渐渐有了些许答案。
先来看看什么叫“加载”，百度百科给出了两个主要的含义：字面意思是增加装载量，现多用于计算机相关领域，表示启动程序时文件或信息的载入。由此可以看出，内容的变化是加载的本质。而在互联网产品里，则体现在方方面面，比如内容出现、增多、减少、刷新，状态变化，消失，结束等。就像我们看到的，随便的一个app，就像一个浮夸的加载机器。
而首要面临的问题就是，内容来自哪里？针对一款app，肯定是本地内容，缓存的内容，服务器获取的内容。而针对这三者内容的变化，加载在其中扮演的角色是什么呢？笔者准备先在这里卖个关子，最后再来解答，因为各种浮夸的加载菊花已经迫不及待了。
屏幕中心的菊花加载
它是app中最常见的加载方式，经常出现在用户登录、退出app，native app内的整页面的加载。它最直接的界面表现是屏幕中间显示一个类似于系统控件的黑色菊花。而此时，用户在等待的过程中所能做只有选择等待或直接返回退出（有些情况或bug甚至导致不能点击返回）。而内容的变化往往是整页面的加载或整个app的加载。
该加载的适用范围往往是整个app的加载或整个页面的加载，而往往是需要一次性加载很多内容时，可能是从本地一次性获取很多内容，也可能是从服务器一次性获取很多内容。
使用该种加载方式时，需要尽量不使用，如要使用，需尽量使加载的时间变短。而使时间变短的方式，可以通过趣味化情感化的小动画或漂亮的整个页面使感受层面的时间变短；也可以真正从交互或性能上去优化，让真正的时间变短；或者两者结合。但往往一个刚起步的app可能并不会投入太多时间在这些点上，可能更多的为了开发成本而省去了，但当产品步入正轨后，就需要适当考虑这方面的优化了。
按钮上的菊花（进度条）加载
它往往与按钮的状态变化联系在一起。当用户点击某一个按钮时，按钮因用户的点击其状态发生变化，而状态发生变化往往需要和服务器产生交互。所以可能需要一个短暂的加载过程。它最直接的界面表现为“按钮”“菊花或进度条（加载）”“变了状态的按钮（不可点）”。而往往很短时间的加载使用菊花，长时间的则使用进度条，而针对进度条，甚至可进行暂停操作。
按钮上加载往往出现在列表中多个按钮可连续点击，比如“订阅”按钮、“添加好友”“同意添加”按钮、“表情下载”按钮等；而支付宝的这一次改版中的付款按钮的变化也使用了按钮上加载的方式。这种方式最明显的好处是，无需等待，同时，可以多线程操作，可连续，也可不连续，例如，我点击下载一个表情的时候，我无需一直看着那个进度条下载完成，我可以只需操作后，即可离开；若没有网络，则会及时给予反馈，若有网络，则会直接下载；若下载中途无网络，则会暂停。而针对大多数的非进度条的加载都会时间非常短，仅需客户端给服务器发送一条命令的时间即可，因此，成功和失败可能都在一瞬间能显示出来。
按钮上加载需要的最直接的条件是该加载过程不会影响产品中其他功能的使用，若会影响其他使用，则最好能够采用其他方式。比如，按钮加载完成后不仅使状态变化，还包含跳转页面，若按钮在加载中时，用户进入了其他页面或选择了返回，会导致后面的反馈和页面都没法出现，可能此时使用屏幕中心加载或其他加载方式更合适。
整屏无菊花加载
它是一种看起来好像没有加载的方式，但是其实却在用户可能看不到的地方默默的加载。它最直接的界面表现是页面中的内容逐渐显示出来或直接显示出来，这样可以使用户似乎感受不到加载的过程。用户也可以在已经加载出来的界面上随意操作，加载的过程并不会影响其行为。
整屏看起来无加载往往使用在两种情况，第一，内容早已存在本地，可直接显示；第二，已经加载过的内容缓存到本地，只需加载最新的内容；第三，整个页面的加载时间很短，并整个屏幕逐渐出现的体验不差，也会使用在一些native app中的简单web页面。当只需加载新的内容，则只需在新内容处显示正在加载，并不会使用户感受到整个页面的加载过程，且会节省用户的流量，就像微信的表情商店页面，仅会对可能发生变化的内容进行加载，比如表情付费的钱数，新增的表情等；而表情的详情页面（native）和易信的星币广场页面（web），因为内容较少，则采用了整屏逐渐显示出现的加载方式，使用户不用等待，当然，在没有网络的情况下，详情页面肯定是加载不出的，这是对详情页面中的内容做默认显示（比如图标、图片的默认图）也是必要的。
整屏弱菊花加载（刷新）
整屏弱菊花加载，给用户的感受是，不但可以浏览已经有的内容，也可进行加载。而这种方式最常用的界面体现即是下拉刷新，每次进入页面时的自动刷新，底部上拉（或点击按钮）加载和顶部下拉加载。在加载过程中，用户还可进行浏览和其他操作；而在加载结束后，一般都会有新的内容产生，进而用户可以选择浏览新的内容。
这种方式的加载，往往是用户主动通过客户端向服务器获取新的内容时产生的等待时间所引起，因此，往往会以一个图标的形式展现，有些可能会配有“加载中...”的文案，但毕竟是等待时间，用户可能会感觉厌烦，所以很多app都尝试一些好玩且符合产品和品牌定位的加载动效，使用户的等待的时间变的不那么枯燥，比如说大众点评app的“吃包子加载”；百度贴吧的“百度熊喝茶加载”。
整屏弱菊花加载经常使用在需要浏览内容的页面，而对于一些不需要浏览内容的页面，也可以做一些下拉“假加载”来宣传品牌，比如易信消息列表页面所做的事情就是下拉时出现易信的ICON。而当已经没有内容时（特别是上拉加载）或“假上拉刷新”，也可以尝试做一些好玩的方式，告知用户已经没有内容了，比如网易火车票的“被拉长脖子的小人”和same的“惨叫鸡”。
web进度条的加载
web进度条，主要是native app中去打开一些web页面时最主要的加载方式。这种方式枯燥，无趣，可能需要用户等待的时间很长，而用户所能做的也就只有等待。而目前各种产品中的界面表现仅仅是进度条不断变长，随着越来越多的H5的社会化运营页面的产生，在进度条之后甚至还会出现进度加载的显示。
web进度条的加载其实是整屏菊花加载的变种，只是更多的使用在web加载中。而目前我们所能做的也就是尽量使用户的等待时间感觉变短，就像整屏无菊花加载中的易信星币广场的例子一样，直接抛弃进度条；或采用进度条和内容直接显示进行结合，使得用户不用等待太久。
先成功再加载
先成功再加载，是发布内容时最常用的加载方法，给用户的感觉则是发布那一刻是无需等待的。如果发布成功了，那用户可能就真感受不到等待；如果发布失败了，则需要用户能够非常简单的再次发布，就像聊天中的发布消息或朋友圈中发布内容。它其实是整屏菊花加载或按钮菊花加载的另一种表现形式，只是把加载的时间缩短到看起来似乎不用时间。它的界面表现形式，可以是以菊花、进度条等。先成功再加载，可能会使整个的开发成本变的稍微高一点，但却能够使用户在发布内容的整个过程中更高效和简洁。
边浏览边加载（预加载）
边浏览边加载也是减少用户等待时间的一种有效的方法，主要使用在用户浏览内容的过程中，让用户几乎感受不到加载过程；即用户浏览当前内容的时候，下面即将要浏览的内容已经开始在加载了。这种情况下，因网速等不可抗力因素，可能会存在衔接不上的时候，当衔接不上的情况下，用户可能还是需要等待加载，而加载的内容也就可能需有默认状态（比如默认图片）。
边浏览边加载还是需要一次加载过程的，即第一次的加载，就像我们在一条微博中浏览多张图片时，当查看第一张图片时，会看到一个加载过程；而查看后面几张的时候，如果图片不是很大，则不需要加载过程，其实是在查看第一张的时候，已经开始第二张的加载了；而在浏览一些列表内容时，往往在浏览中加载分为两种情况，一种是浏览快到底部时，自动加载，这种加载往往取的内容是本地缓存，因此速度也会非常快；而另一种则是像服务器或后台取数据，则在浏览过程中逐渐加载，加载时间和效果取决于网速。
以上为笔者总结的六种app中的加载模式，可能还不够全，希望在以后的工作中，再去发现和总结，并逐渐更新。
而本地内容、缓存的内容、服务器获取的内容，加载在其中扮演的角色到底是什么样子呢？其实万变不离其宗，让用户少等待，甚至不让用户等待；那本地内容就可直接出现，缓存内容可直接出现并可持续很快加载，服务器获取的内容尽量减少用户的等待；而采用的模式可能就是上面介绍的模式。而我们在设计的过程中，可能要去思考和评判一个重要的问题，就是到底哪些内容可以让其缓存下来，而不用每次都要去获取，就像微信的表情商店和易信的表情商店，是一个缓存加载和一个每次加载的区别；因为内容和方式可能也就导致了设计模式的不同。
没人喜欢等待，等待拉长了时间，就像每次我在等公交，早上八点半等车，等到9点10分车才来，往往结果是令人气愤的，如果这个时候我的眼前还有一堆浮夸的菊花在转，可能我早已昏了过去，或者直接走出公交站，选择骑自行车来到公司。
愿这个世界不再有浮夸的菊花，也愿你我人生的等待时间也变短。
（PS: 配图请等待）