本节书摘来自异步社区《渐进增强——跨平台用户体验设计》一书中的第1章,第1.3节,作者 【美】Aaron Gustafson,更多章节内容可以访问云栖社区“异步社区”公众号查看
1.3 技术实现和用户体验
早期的Web技术更新得非常快。比方说,HTML的标准还未统一,微软和Netscape两家公司争相往HTML里面添加新的元素和行为,以证明自家技术比对方更厉害。后来又有了Java applets[6]、RealMedia、Shockwave、Flash和其他的私有技术,我们的网页变得很复杂,同时用户需要安装很多插件来支持这些技术。
各家标准和技术的不统一导致了“优雅降级”概念的诞生。所谓优雅降级,指的是在用户的浏览器不能完全支持某项功能的时候,为用户提供一个在可接受范围内的浏览体验,并且告诉用户如果要提升体验的话,应该如何获取所需的技术支持。举例来说,我们在开发的时候使用了某种技术,如果用户的浏览器不支持此技术,我们会判断这些浏览器,然后给他们如下提示。
请使用IE浏览器以获得最佳访问效果。
请使用Netscape浏览器以保证页面浏览正常。
此网站需要Flash支持,请安装Adobe Flash Player。
优雅降级虽然给出了这些必要的提示,但是这种差异化的体验,还是让一些用户感觉自己被忽视了。
还有一种做法更方便,不用测试任何浏览器兼容问题,在用户访问网站时,根据用户代理字符串(User Agent)判断,如果用户使用的是老旧的浏览器,那么就把他们引导到一个专门让他们下载新浏览器的页面(图1-3)[7],这样用户当然就不会发现网站的兼容性问题了。
![20cbc93ba2c26b8b1cac631b4426319f4c78757d](https://i-blog.csdnimg.cn/blog_migrate/fe6a57b21da17a5e7c007975bbd1f997.png)
让用户看到一些内容,然后告诉他需要更新浏览器才能获得更好的体验;亦或直接告诉用户,下载新的浏览器吧,否则你什么都看不到——这两种方法哪种好呢?
我已经有点选择恐惧症了,这种瘸子里面拔将军的问题,在我看来,就是五十步笑百步。
一个教训
我曾经帮WikiHow公司做过一个Chrome浏览器应用[8]。当时Chrome的“网上应用商店”还是一个新鲜事物。我们的客户希望这个Web APP可以做一些酷炫的CSS3动画,用一些高大上的Web字体,搞一个Web SQL本地数据库,要提供离线支持等。总之,客户说要用到很多“HTML5”的新属性,还要做成一个单页面APP。由于只需要兼容Chrome,所以我们觉得技术难度不大,一口答应了下来。当我们设计开发的时候,采用了优雅降级的方法,屏蔽了一切通过非Webkit内核浏览器访问的可能。
谁知,隔了一年之后,这个客户又回来了,告诉我们,让这个APP兼容Firefox和IE9浏览器吧。你们可以猜到,这时我们的心里几乎是崩溃的。
因为这个APP完全是为Webkit内核浏览器量身定制的,所以改造起来有一点麻烦。如果说仅仅是改写一些CSS代码以兼容Firefox和IE,添加一些DOM(文档结构模型)节点,改写一些Javascript的API的话,这些都容易。但是,WebSQL数据库不支持Firefox和IE浏览器,这是硬伤啊。我们表示必须放弃使用WebSQL,另寻数据库的解决方案。
如你所知,WebSQL几乎已经被W3C(万维网联盟,负责制定绝大多数的Web标准)放弃了,现在只有Webkit内核的浏览器在提供支持。Firefox和IE浏览器看样子永远也不会支持这种技术了。而IndexedDB现在的兼容情况也不是很乐观。思来想去,最终,我们选择了使用localStorage来代替数据库存储,好处是,我们可以少重构一些代码。另外我们发现,APP的运行速度可以提升不少。
项目重构下来,花费的预算和时间差不多是去年一开始做这个项目的40%。我后来做了一个估算,虽然我并不能准确地模拟一个项目计划,但是按照以往的经验来说,如果一年前我们采用渐进增强的策略,这次项目重构的预算绝对低于40%。另外,项目的稳定性、代码的健壮性肯定会更好,因为如果按照渐进增强的开发方案,则此次重构是不需要改写JavaScript代码部分的。
在和项目中的其他设计师沟通之后,我发现,40%这个数字可能还是低了。我想起一个有关Google地图的一个传说。那时Google地图项目刚启动,团队的任务是建立一个个的地图模块,他们使用AJAX拉取一个个的地图文件,当发现这些地图中的JavaScript的兼容性有问题时,重新改写这些代码的工作量已经非常大了。Google的工程师为了避免今后发生类似情况,在重构代码时使用了渐进增强的思想去指导整个流程——这个传说我忘记是谁告诉我的了,虽然细节不可尽信,但是事件本身却发人深省。
上面关于Chrome APP的故事是一个反面的例子。还记得一开始我分享的那个例子吗?之前我曾经说,我们的团队曾经兼容了1400个浏览器,只增加了客户15%的预算。而在刚才这个反面的例子里,我们只兼容了两个浏览器,却增加了客户40%的预算。哪种方案更好,我相信任何人都会算这笔账。采用渐进增强的方案可能在项目开始之前需要多花一些时间去思考,但是会给后来的设计开发节省大量的时间。
在处理浏览器兼容方面,尤其是现在,我们要面对如此多的浏览器、移动设备,与其使用优雅降级的方案,使用渐进增强的方案会节省大量的资源,从而在单位时间内产出更多的价值。在效率方面,优雅降级在渐进增强面前就是个毫无战斗力的渣渣,注定要被吊打。
好吧,说了这么多,怎么做才能实现渐进增强呢?
渐进增强,简单说,就是创造连续的用户体验。