UI 交互设计之

让等待变的“理所当然”

引言

设计在不断改变我们的生活体验，当然，直接的结果就是用户更开心用了，然后你也赚到了钱，和那些可能会用于加班来调整性能和用户体验的时间。不得不说的是，生活中充满了等待，等公车地铁飞机航班，等约会，等考试结果，等发薪水。。。 都说习惯成自然，这些生命中的“等待”也逐渐变成了理所当然，就像你拿了这个月薪水下次必须等一个月，就像你错过了这班地铁就得等下一班，就像你打开一个页面就需要等待。。。

 

 

 

人，总是耐不住寂寞，等待会让人心里浮躁，开始抱怨。

就像错过地铁的人只会抱怨自己跑的不够快，不会抱怨地铁行程时间安排不合理一样，如果让你的用户等待过程有可能产生的抱怨消除掉或者转向他自己，这就是今天的文章所涉及的主题。

 

信息传播和计算机硬件性能的飞速提升，人们对软件的交互性要求也不断提升。信息数据更新的实时准确已然是基本要求了。随着对性能要求的不断升级，各种解决和提升性能的解决方案也大师们手中孕育而生了。 但是对于一个简单的用户浏览页面的请求，请求=>传输=>处理请求=>返回处理结果=>显示，整个过程中，等待，不可避免。（当然你会想到很多可以优化性能的解决方案，比如你只需要更新那些新的数据，而减少或者避免页面重新加载的次数，想很多网站上显示新消息的模式一样，告诉你你有多少个新的消息，然后点一下，就会把新的消息显示在你的页面上，看上去你推消息的模式，实际上都是在你的浏览器注册安排了一个定时器，隔多久去服务器走一趟，看看有什么新消息没有，然后显示更新）

 

任何的交互都可以看成是一个请求/响应模式。当然，不同的请求有不同的响应结果，自然响应速度也有快慢。而不同的应用程序对同样请求的处理流程肯定也是不一样的，有问1答1，有问1答10的，甚至问1答100的都有，可能还会有问1答0.5的等。具体点的，比如说，一个邮件系统，发一个查收邮件的请求，问1答1的就可能是就返回有新邮件，问1答10的就会告诉你谁给你发的什么主题什么附件什么内容CC了谁等等邮件的详细信息，问1答100的可能会告诉你除了前面的还有你有以前安排的会议明天8点提醒，你上次发送给xx的邮件发送失败了，你邮件密码快过期了，你的账号在异地登陆过等等，当然答0.5的就没有举例的必要了。

这个场景告诉我们，在大多数情况下，我们是可以把请求的响应按照粒度和优先级别来进行划分。就拿问1答10这种比较模式来说，作为一个返回的请求，你里面包含一个被你封装成邮件的对象，里面有标题，收件人，内容，签名，附件，以及其他。当然，这是已经是一个很好的设计，用户需要看到这些。可是当内容和附件都很大的时候（内容中有图片或者视频等内嵌）

你查看邮件会很慢，甚至有时候你根本不关系内嵌的多媒体或者附件的内容，而你为了看邮件的其他文本内容的时候不得不等这些大数据的内容加载完，想想，多么痛苦的一件事情。

 

这个时候我们就有一个按需加载的一个概念了，事实上大多数网站和应用上都是这么做的。在我给你返回的这个邮件体中，我会告诉你有那些东西，至于你想看附件还是内嵌的图片或者视频，甚至语音的时候，我提供你一个图形化的接口，对不起，您需要再点击一下，然后对不起，你需要再等待一下。如果整个过程是3秒的话，你可以只需要0.5秒加载那些纯文本的东西，

然后剩下的0.5秒是用户查看图片的下载时间，另外1秒的缓冲等待时间是当点击播放按钮后听你插入的歌曲，另外1秒是查看下载您的附件。当然，事情没有这么绝对，这里的分类和数据只是一个概念。

当然你完全可以采取其他的方式，就算时间长，你也不想让用户再有多的操作，什么都一次性搞定，然后请求应该是一个异步的，显示结果应该在一个回调函数里面，然后中间请求之后，您会有一个比较漂亮的loading页面或者一些小游戏，或者一些其他的可以分散等待注意力的行为，让用户等待的不那么明显，并时刻告诉他您正在为他服务。

 

 

总结

不要让用户等那些可能对他来说不是很重要的数据（请求响应的粒度，优先级，整体性的划分）；

如果非要等，就得让他等的不那么明显（分散注意力，并实时报告进度）

 

 

作者的话：

文章的目的在于自我的总结，记录想在的一些想法，等以后的自己来回望。

如果对您能起到一些思考作用或者得到一些回馈的话那也是一件很美好的事情。

写在网路上的文章就是给人看给人用的，然后顺便自己能获得一些反馈。