我第一次遇到这样的进度条是在我之前的项目中。一个web开发者添加了它,这让我觉得很奇怪。一方面,当我无法把这个进度条和想下文相关联的时候,我问我自己这个进度条表明了什么。另一方面,我没有看到复制已存的特性(浏览器中的URL栏中的状态条)有什么好处。最近我看到了一篇文章“新UI模式:网页进度条”,我任然忽视这种行为。
许多!首先,当第一款可用的浏览器应用产生时,就出现了状态栏的雏形。所以人们早已经习惯了这个界面元素。任何时候当一个没有技术背景的用户打开一个网页时,他会去看这个进度条。他们认为在地址栏里输入网址后,进度条能立马展现出加载进度。当进度条到头并且消失的时候,用户就知道页面加载已经完成了,网页可以使用了。至于说技术上这些是怎么处理的,用户不会感兴趣。而且用户也不关心到底数据是作为请求的一部分从服务器上下载下来呢,还是在页面展示之后的某个时刻,再借助于JavaScript来获取部分数据呢。
正如它的名称所暗示的,加载条展示了数据加载的进度,例如当用户点击某个按钮时,网页就会在背后去获取更多的数据,而不用加载整个页面。这个核心的认识(部分数据加载)不论从技术的观点来说还是从用户角度来看,都是很优秀的。 由于网页没有重新加载,所以内容看起来也没有变化。所以,用户没有必要分析展示的页面,也没有必要试图找出发生了什么变化。
不幸的是,这一优点同时也带来了一个缺点:用户无法察觉到此时发生了什么改变。如果用户重新加载了整个页面的话,他可以看出浏览器正在响应。如果当他点击一个按钮时(举个例子,假定没有展示任何提示信息的话)什么也没发生,用户就可能会认为是网站挂了。所以,网页必须表现出它正在处理用户操作。
正如上面提到的,展现进度的一个可选方案是使用那些演进版的加载条。无论怎样,个人认为,这都是完全错误的选择。原因是:
每个用户都会无意识间把他看见的范围划分为活动区域和非活动区域。当活动区域内发生什么事情的时候,他能立即识别出发生了什么。然而,如果非活动区发生了什么事情的时候,他只是看见有什么事情发生了,但却不能识别具体发生了什么。所以为了看清到底发生了什么,他需要把视觉焦点移到动作正在发生的区域。这样一来,他就会把注意力集中到那个区域,而不再关注他之前所看的东西。简言之,他的注意力被分散了。
用户迫于关注不同的页面而失去上下文
让我们在现实生活场景中用一个例子来解释这个副标题。 假设用户正在浏览搜索栏,它在页面的朝下的3/4部位位置(也就是说浏览器窗口顶部和搜索栏之间隔开了)。用户输入了搜索项然后按下搜索按钮。这个时候,他的视线停留在了搜索按钮。现在,一旦进度条显示在页面的顶端,大脑就会产生一个信号,告诉他在活动区域外会有其实动作发生。用户很期待动作的发生,所以他把视线又放在了进度条。这样做之后,他就离开了当前认知的上下文,因为他要开始新的动作,这上下文包括搜索栏,搜索项,按钮和触发按钮的其他期待的将要变化的行为,
所以现在用户意识到了进度条。如果他之前没有见过,他就会问自己这个元素表达了什么意思。但是别忘了:用户失去了搜索栏的上下文,这就是为什么他几乎要从头开始来重新定位。最后,用户得出一个结论,进度条跟搜索栏行为相关,并意识到它显示了搜索进度。所以用户准备等到进度条加载完成。这一刻,用户有些迷惘了,他会一直注意显示进度条所在的区域,然而搜索结果却不在这个区域。所以这时他得出的结论是,他应该继续关注搜索栏周围的区域,反反复复地。他需要切换回先前的认知的情况,他必须使自己再次认知?-?“我搜索了什么吗?“,特别是,“哪里有结果?“。后者实现起来相当复杂,因为他的大脑必须唤起之前的搜索按钮被触发(这是一个古老的背景部分)前的情形并和当前场景做比较。这花费了一个巨大的认知的开销,从用户体验的角度来看是最糟糕的事情。总结一下现实生活的例子:用户被迫进行两次上下文变化,在第一次看到搜索区域和第二次从加载条区域返回时,他要自己找出什么发生了变化。这也正是为什么加载条不是一个UI模式。他们是UI反模式的!
有很多好办法可以做到这一点——只要它们是在用户端活动范围内。例如,搜索按钮的文字可以改变成“加载中……”,与此同时加载条显示在它的正下方,也就是,在搜索字段/按钮和结果区域的中间。这样的话,用户发现搜索结果就没有任何障碍了,因为搜索结果显示的时候,他的视觉活动区域包含了内容的变化。
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。2KB项目(www.2kb.com,源码交易平台),提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务