11月14, 2013

[译]给菜B准备的新手指南:四种感知优化技巧,让你的手机站点高端起来

原文:http://www.mobify.com/blog/beginners-guide-to-perceived-performance/

编者语:本文约有4500字。内容涵盖于面向手机的网站在感知性能方面的几个点,以及加快访问速度的可执行方案。不想读太长文章的小朋友们注意了,本文可不是说如何给糟糕网站插上翅膀飞起来噢,它是琢磨如何让用户的感知体验趋于自然的。

技术已日渐成熟,无论你采用响应式还是适应式什么的,只要你有明确的生产理念,在移动设备上制作个美观的WEB站点并不困难。但你的客户从不会满足,他们那被权利与欲望所腐蚀的脑子里已经容纳不下一点美感,以至于会无止尽的要求你,他想要获得更好更流畅的app式体验。而以现在人类范畴内的技术水平来说,嘛,都能这样想了还做什么产品,去写科幻小说啊。(笑)

不过细想起来,其实,当用户觉得一个站点“像app”或是“原生代码开发的”的时候,大多感受到的不仅是外观而已,更多的是操作界面的响应处理和执行方式。相比之下,native app毕竟是亲爹养的,它运行速度快,动画播放流畅,按键反应及时,不受加载影响等,光从执行性能上就够甩webview几条街的了。

“native app式体验”的意思就是,丧心病狂的提高你站点的运行速度。

近来,一坨又一坨臭烘烘硬梆梆的web app井喷而出,这不能不令我等深思“WEB世界的大和谐之计划”的可行性,也要深思自身认知的狭隘与菜B。故而,“提升性能”理当并已经受到了人们的密切关注。Facebook那些高富帅们也说,以现有的web app环境,他们很难获得预期的速度与互动效果。为此,他们日后将转向着手发展手机端的native app。无论Facebook搞什么飞机,但在这里我想告诉大家的是,想架设个高性能网站并非天方夜谭。虽然的确存在一些硬性阻碍,但是只要多付出一点努力,还是可以实现的。

感知性能VS 实际性能

尽管提高实际性能很重要,但除非用户能确实体验到了性能的提升,否则这对于他们而言并没有什么意义。今年在西雅图的某个设计者大会,LukeWroblewski讲到他的手机应用Polar时,说到他的团队努力的改进了新版投票的加载速度,然后还人性化的加了等待效果展示(翻滚吧Loading),结果却得到了速度变慢的用户反馈。高程们很不理解,用户咋那么难伺候呢,然后又发了一个把等待效果给下掉的补丁,好吧,终于有人说so quickly!

这说明啥,这说明了感知性能的重要性。明目张胆的用Loading展示告知客户“你在等待”的事实,简直就是作死。这转移不了什么注意力,也不是什么优化设计,它只在传达一个信息“我很慢,菊花给你看”,啥时候真把用户旋出翔来你的应用就算成功了吧。总之,如果用户感受不到,你站点再快也都无济于事。

作为设计者与开发者,我们的目标不仅仅是提升数学意义上的速度,也应创造对于体验和感知上的冲击力。

出于用户的角度,我认为感知性能比实际性能要重要的多,当然这并不意味着没必要改进实际性能了,两者是相辅相成的。到此,我想大家已经对两种性能有所知晓。那么,如何才能提升感知性能呢?下述有4种技术可以拯救你:

1. 为按键添加touch状态

最简单的一种方法就是增加触摸行为状态展示。嘛,通过测试你可以得出,每当用户点击网站上的按钮时,总要等个300ms后才会有所响应。这是浏览器所预设的时间空隙,以确保用户没有点错(怕用户是双击事件吧)。所以需要等待三分之一秒来确认用户是否有其他操作。之后浏览器将对最初的点击做出响应。响应方式是高亮并灰化,然后再跳转。

这个体验其实相当糟糕。Nielsen组织研究显示,超过100ms以上的响应,用户就会察觉到自己在等待,而他此刻想做的就是赶紧离开这个鬼地方。然而,包括我的一些网站在内,大部分手机网站都不会在意感知性能的问题。而设计者通常会觉得链接或按钮就是这样的(也可能是他们从不使用自己设计的页面的原因)。

想提高你站点的精神层次,就要先让按钮对用户的点击直接做出回应!

:active这个高端洋气的CSS伪类状态在WEB页面开发中已经很常用了。但可惜的是,iOS和Android都没有在手机端实现这个状态。不过我们总是有曲线救国的办法的不是么,找到替代的解决方案并不难,只要在JavaScript中增加下述事件就可以监听到:active状态啦。

document.addEventListener("touchstart",function(){}, true)

而后,您可能会想用CSS来添加个按钮被按下的效果,且把该死的触摸高亮给去掉。

-webkit-tap-highlight-color:rgba(0,0,0,0);

以上尽管没有改变实际的运行速度,但它给用户操作以直接反馈,而非300ms的空虚等待,感知性能get√。

无点触状态和有点触状态

我们还可以再进一步,达到实际意义上的速度提升。

调用fasttap或者fastclick,可以彻底清除300ms的延迟,这会让感知性能更好提升,达到丧心病狂的地步。欲知fasttap详情,请Google之。也可以直接去checkout Github资源。

2. 使用冲量滚动

你是否有过在手机站点上下拉滚动条的时候,感觉有很卡或很慢的情况啊。Android3+和iOS5+支持CSS的新属性为overflow-scrolling,可实现冲量滚动,然后一切都变得美好起来……

无冲量滚动和有冲量滚动

这样的动态效果一出来,马上就有too native的感觉啦。只要在滚动条上增加下述属性即可实现。

-webkit-overflow-scrolling:touch;

不过这个属性在iPhone下有个问题。在iPhone下点其顶端的状态条是可以返回到页面顶端的,但冲量滚动会造成这一功能的失效。这个BUG已存在一段时间了,但直到iOS7 的Mobile Safari最新版才修复。针对它也有个不太靠谱的解决办法,就创建一个overflow-scrolling:touch的class,当点出容器时用JavaScript去加class到容器上。

Android4中对滚动条都有冲量滚动效果,所以完全不需要考虑这个属性。

对于低版本的Android系统,会有一些备选方法。我倾向于使用Modernizer来检测系统对冲量滚动的支持,然后修改布局使容器溢出可见(我也不知道这是要说啥)。如果不想选上个方法,有一些JavaScript库也可供选择。FilamentGroup的Overthrow和iScroll什么的。

3. 创建高性能动画

web站点与app最显著的区别之一就是对动画的运用。最近几年,app利用设备自身的硬件加速功能能做出很流畅的动画。但在web上只能通过JavaScript去通过计算去做动画,这样的动画效果若在CPU性能较差的手机上就会运行很慢啊。别慌,时代在发展,科技在进步,不过随着手机浏览器的不断支持,我们可以使用支持硬件加速的CSS3动画去完成很多炫酷屌渣天的效果。

这种强化视觉效果的方法超洋气。许多广受欢迎的app都以此为傲。

这还不够,想与native匹敌,必须要确保动画的流畅和稳定,而这一点往往很难做到。SteamlockSoftware的Allen Pike在2011年写了一篇非常好的文章。主要讲的是他们在开发nativeapp时的一些注意事项。想提供给用户一些喜闻乐见的动画效果,但性能不好的动画是会严重影响app体验的哦。这些注意事项同样适用于native-feeling的web动画效果,都是金科玉律呀,要好好膜拜下。文章中,他提出了“感知时间轴(timeline of perception)”这个概念。

  1. 动画帧率应为60fps。这意味着每帧~16ms走完。这是达到native流畅的最小值。iOS的内置动画都是60fps,所以iPhone的滚动效果比Androidu要好很多(尽管近来Google针对这个问题已有很大改进)。努力让所有与用户相关的动画都追上这个帧率吧。
  2. 100ms内进行响应。100ms是人对慢的感知阈限,在这时间段内所发生的事,用户都会觉得是即时的。
  3. 若一定要超过100ms才能做出响应,那也必须控制在1000ms内。Allen建议用时超过这一时间的,可以先给进度条什么的,以告知用户等待过程中并非什么都没发生。但是上面Polar的案例告诉我们,将用户的注意力集中在等待上,反而会弄巧成拙。之后我将再讲怎么处理这种情况。
  4. 超过1s就会有不好的事发生了……

对以上有所了解后,你可能会觉得有些受不鸟,搞个动画居然也要关心这么多事,从而出现了“不干了回家种地去吧!”这样的想法。

少年且慢!其实你完全不用为此担心,有很多资源可以帮助我们解决这个问题的。

首当其冲就是 Effeckt.css。他们的目标就是建立一个以60fps为基准的过渡动画库,尽管还没有全部完成,但成果已经非常明显了。我强烈推荐这个玩意,你可以根据自己的项目对其进行微调后使用。另一个强大的家伙是Topcoat。它是Adobe的web团队建立的一个追求性能的CSS组件库,里面提供了许多超顺畅的组件呦,且每个都做了评效,可以在这里查到它们具体的性能情况。这俩最近好像已经有合作的样子,感兴趣的朋友都试用下吧。

现在,进一步谈之前提到的问题:如何干掉香气四溢的小菊花。

当等待时间介于100ms与250ms之间,显示菊花是弊大于利的,我倾向于在超过250ms后再显示它。再比方说用Ajax获取数据时,把外层容器收缩然后再展开显示新内容,这一小段动画总比让用户傻乎乎的盯着菊花看要好的多啊,他们甚至不会意识到新内容是在动画后才载入的。当然,长时间地重复动画也会令人厌烦。所以请慎重使用。对于大部分动画的运用,也同样需要慎重。

4. 利用自然手势

与web相比,app有一个优势,即能在点触设备上利用人们的自然手势去响应。Mailbox或Clear等一些优秀的app都会尽量支持手势行为,可以直接触摸到屏幕上的对象进行二阶操作是件很爽的体验。然而,大部分网站仅支持点击对象,而不再利用其他手势,很低端的感觉啊有木有?这种用户体验是很枯燥和乏味的。

所以别傻看着了,快把你的网站也改进成支持手势操作吧!

唔,还有一个小问题:手机操作系统总是会恶劣地绑架浏览器上的手势。比方说Facebook这样的app,使用边缘滑动会显示导航栏。但是在Web里Chrome就切换标签页了,而iOS7的Mobile Safari里则根据历史记录来前进后退当前页面……好吧,既然手势有诸多限制,那么哪些是可以使用的呢?下文列述了四个:

  1. 左右划动:左右划动仍是非常强大的一个手势,只须注意别太靠近屏幕边缘即可。它最适合用来移动照片浏览啊标签页啊什么的。
  2. 下拉更新:下拉更新是另一个使用频繁的手势,通过许多JavaScript库都能轻松监听到,我之前使用的是Hook.js。
  3. 长按:-webkit-touch-callout: none属性能有效禁止Mobile Safari中的长按效果。但如果换成Android,那就需要多做一点工作了。长按手势可用于提取图标(比如重排图标位置、顺序)与显示更多选项(例如群分享等)。
  4. 缩放:大部分人在网络上看到一张图,都会试着缩放扭动的手势来看图的细节。这里有浏览器绑架手势的另一个例子,但情节并没有那么严重,就不告诉你是啥,就不告诉你是啥。要实现多点触控手势,可以试试精悍的Hammer.js。它包含了很多手势操作,也支持自定义。用手机体验一下imgur.com的缩放或滑动手势吧少年,awesome~。

不过请记得,要用手势的话要先保证它是自然的可理解的,要用户接受的,再行采用。

结论

终有一天,native和web将毫无差别,虽然这是件很理想化的构思。但我们每付出一分努力,让网站看起来更贴近用户,那么,理想实现的那一天就会越快到来,么么哒!

性能问题越来越受关注的趋势非常好,但是请谨记,我们的用户并非机器。

他们不在乎你的网站具体发出了多少请求,不在乎屏幕究竟重画了多少次。他们在乎的是对这些性能的印象、感知。

如果用户无法体验到快,那么速度的提升根本就没意义。

如果你有更多关于发展感知性能的想法,请别留言,直接再写一篇吧~

本文链接:https://75team.com/post/译给菜b准备的新手指南:四种感知优化技巧,让.html

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。