小议时间轴的“w”与“l”加载机制

人们经常把浏览微博的行为冠以一个专用名词即“刷微博”,这里理解所谓的“刷”就是需要你在内容时间轴中频繁的刷新加载出新微博内容的这一过程;最近在微博中看到了有朋友抱怨说在使用新浪微博客户端过程中总是得一会正向一会逆向来回反复划动时间线,而且很容易遗漏或忽略一些重要的内容,很是烦恼;借此问题就引出下面要涉及到的时间轴刷新的交互机制问题。

这里讨论的有两种机制,分别是“w”与“l”加载机制;

“w”刷新机制:
由于某些原因(真的不太清楚),我们在Web端浏览器机制中,通常页面刷新之后会跳回到页面顶部并显示最新内容(如W-2)。用户自上而下浏览内容,浏览内容的顺序是由新到旧(或由“最新”到“较新”更为恰当?),如图示一,在Web版微博中,当浏览到内容B底部之后(如W-3),用户要重新划过很大块内容B区域才可以回到顶部(如W-4,这里特指是划动返回顶部的情况,点击刷新按钮的情况另说)然后点击加载更多新的内容C(如W-5);不断的浏览就会不停的重置这个过程;

图示一:W-1至W-6的过程;

图示一:W-1至W-6的过程;
图示一:W-1至W-6的过程;

以上这种交互过程就是典型的“w”刷新机制,因为用户操作以及浏览的内容都是类似于“w”轨迹在运行;

这种Web端的加载机制被搬到了移动端,相比Web端,移动端列表内容流刷新采用了顶端下拉刷新的操作方式,结果都是一样的,只是把滚轮上下滚动变成了手指的“w”划动,微博客户端也就出现了之前网友抱怨的问题,具体会有一下几点:
1. 这个过程中相同的内容区域(B)会在屏幕上出现两次,一次是向下浏览的时候,另一次是返回最顶部的时候;而第二次显然不是用户主动想看到的,而是机制限制产生的不良结果;
2. 在交互操作方面,用户也就会出现之前网友的困惑,一会正向划动一会又逆向划动,增加了一倍的非必要操作成本;
3. 这样阅读内容的顺序是由新到旧,和通常的阅读顺序相反;

既然“w”加载机制有这样的弊端,那为何还会被大量使用呢,大致揣测下此种设计的初衷:
1. 为了保持移动端与Web端的一样的操作方式;
2. 长久以来用户已经“习惯”了这样逆向的操作方式;
3. 利用了类似于阅读心理,读一本小说过程中,总有人是迫不及待的直接先看最终的结局,然后回头再看过程;刷微博也是类似,总想直接看到最新(最终)的内容,然后稍后慢慢消化中间的内容;
4. 其他理由(欢迎补充)。

“l”刷新机制:
在非Web端应用中,类微博这种新内容的加载显示完全可以控制的,区别与“w”加载机制,另种“l”刷新机制有更加直观自然的交互过程,会更加适合在非Web端应用中被采用;
图示二:L-1至L-4的过程;

图示二:L-1至L-4的过程;
图示二:L-1至L-4的过程;

具体时间轴的内容普遍会采用时间顺序来排列,自上而下是从新到旧的顺序;还是从顶部进行新内容的刷新加载,如果加载完成之后内容位置保持在刷新点的位置(如L-2),而不是跳转到内容的顶部;此时再向下滑动浏览新加载的内容,浏览内容顺序就始终保持为由较新到更新的过程,当浏览到最新内容的时候内容流也就到达顶部后(L-3),继续再次刷新来重复以上的过程就是典型的“l”加载机制;

再来看这个过程,如果只是想浏览最新的内容而不是回顾已有内容的话,就不会有“w”机制当中的反复划动的过程;内容是从旧到新再到最新的显示顺序。
个人感觉“l”加载机制更加符合逻辑也更加自然直观;对现有习惯了“w”机制用户的使用上也并没有增加新的学习成本,操作交互也减少了不必要的重复滚动;

目前采用“l”载入机制的应用国外典型是“Twitter”移动应用,国内部分注重交互的应用也已经采用了这种方式,如“墨客”移动应用;

以上所说的两种机制只是类似微博时间轴刷新加载新内容(向上加载内容)中的不同,但涉及到向下动态加载已有内容的时候,并没有争议,全部采用了“l”加载机制;向下加载刷新后都是停留在加载点的位置,而没有任何一个应用刷新后是跑到内容的最底端,要看已有更多的内容就向上滑动来顺序浏览。

最后想想,若在微博类应用这种场景下,采用“w”加载机制的主要初衷是要保持与Web端一致规则的这种假定为真的话;不禁又会有这样一个情景浮现:很多年前人们尝试把报纸杂志的体验努力移植到电脑端,但是最终发现并不合适;而今天我们又想把电脑端的体验移植到移动端。
历史总是惊人的相似,不是吗。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据