基本说来,YFT 是指,“取页面中有变化的部分,并置为黄色”。假设你的应用原本没有大量使用黄色,用户就很可能会注意到这种改变。过一段时间后,再让黄色逐渐褪色,直到恢复为原来的背景色。显然,你也可以选用你喜欢的其他颜色;所要做的就是把用户的注意力吸引到有变化的部分。
可能YTF并不适用于你的应用;你也可以选择用一种不那么明显但仍很有用的方式来提醒用户。Gmail在右上角显示了一个闪动的红色“Loading” 加载记号,提醒用户正在获取数据。
究竟要使用YFT还是一种类似的技术,这实际上取决于你的用户。最简单的方法是让一组用户代表来进行测试。可以通过文字问卷,也可以使用基于Web的原型应用,这要看你处在设计过程的哪个阶段,但是不论如何测试,在真正采用Ajax完成复杂设计之前都应该得到一些用户反馈。
而且要从小处做起。刚开始使用Ajax时,不应该马上就去创建一个可以调整列的动态门户网站。而是应该先试着处理客户端验证,逐步转向服务器端。等有所了解后,可以再尝试更动态的使用,如填写一个下拉列表,或者设置某些默认文本。
不管你要如何应用Ajax,要记住,别做稀奇古怪的事情。我们知道,这不算是一个学术性的建议。不过,目前这方面还没有严格的规则。听听你的用户怎么说,部署之前要先做测试,而且要记住,如果太过古怪,用户很快就会点击“skip intro”链接跳过你精心设计的这些部分。
你要知道使用Ajax 时有几个常犯的错误。我们已经讨论过,有变化时如何向用户提供可视化的提示,不仅如此,Ajax还会以其他方式改变标准的Web方法。首先,不同于 IFRAMES和隐藏框架,通过XHR做出请求不会修改浏览器的历史栈。在许多情况下这没有什么问题(你可能会点击后退箭头,只是要看看是不是什么都没有改变,但这么做能有几次呢?),不过,如果你的用户确实想用后退按钮,就有问题了。
与其他基于浏览器的方法不同,Ajax不会修改地址栏中显示的链接,这说明你不能轻松地为一个页面建立书签,或者向朋友发送一个链接。对于许多应用来说,可能没有这个要求,但是如果你的网站提供了驾驶方向之类的东西,就要针对这个问题提供一个解决方案。
有一点很重要,不要过分使用Ajax。记住,JavaScript会在客户的浏览器上运行,如果有数千行JavaScript代码,可能会让用户感觉速度太慢。如果脚本编写不当,就会很快失去控制,特别是当通信量增加时。
Ajax允许你异步地完成操作,这个最大的优点同时也是它最突出的缺点。我们以前总是告诉用户,Web应用是以一种请求/响应模式完成操作的,用户也已经接受了这种思想,但是利用Ajax,就不再有这个限制。我们可以修改页面的一部分,如果用户不希望这样,他们很可能会被搞糊涂。所以,你要注意一定要让用户明白这一点,不要过分自作聪明。记住,只要有问题,就要请用户代表进行测试!
1.5 相关技术
你看到这本书时,可能已经了解了在应用中实现Ajax所需的大多数技术。重申一句,我们想强调的是,Ajax是一个客户端技术,不论你现在使用何种服务器端技术,都能使用Ajax,而不管使用的是Java、.NET、Ruby、PHP还是CGI。实际上,这本书里,我们并不考虑服务器端,而且假设你已经很清楚如何结合你日常工作中使用的服务器端技术。在后面的几百页中,我们强调的重点是客户端技术和方法,创建丰富的基于浏览器的应用时需要用到这些技术。
尽管可以使用你喜欢的任何服务器端技术,使用Ajax时,思想还是需要一点转变。在一个典型的Web应用中,服务器端代码会呈现一个完整的页面,并涉及一个完整的工作单元。利用Ajax,可能只返回一点点文本,而且只涉及一个业务应用的很小的子集。对于大多数有经验的Web开发人员来说,理解起来没有什么问题,但是一定要把这一点记住。
一些新兴的框架有助于使开发人员不用去考虑Ajax的一些细节;不过,你要对JavaScript有所了解。我们知道,JavaScript用起来可能很费劲。很遗憾,对此没有什么办法。我们大多数人都学过这么一招,把“alert”作为一种系统输出来帮助调试,糟糕的是,这种技术使用得还很广。不过,现在我们有了新的利器。
除了JavaScript,你还要熟悉其他一些与表示相关的技术,如HTML、DOM和CSS。你不必是这方面的专家,但是基本了解还是必要的。这本书里我们会谈到需要你知道的大多数内容,这里没有谈到的内容可以参考网上的资源。
关于测试驱动(你肯定写了单元测试,对不对?),我们会介绍JsUnit和Selenium。利用这些工具,可以先开发JavaScript测试,并检查浏览器兼容性测试。通常认为,下一代开发环境会对JavaScript提供更好的支持,另外一些与Ajax相关的技术会进一步减轻开发人员的负担。不断引入的脚本和框架也使开发变得更为简单。
1.6 用法
既然你已经对Ajax产生了兴趣,还要知道重要的一点,什么时候应该使用Ajax技术,而什么时候不该用。首先,不要害怕在你的应用中尝试新的方法。我们相信,几乎每一个Web应用都能从Ajax技术得到好处;只不过不要矫枉过正,过于离谱就行了。从验证开始就很合适,但是不要限制你的主动性。你当然可以使用Ajax提交数据,但可能不能把Ajax作为提交数据的主要方法。
其次,惟一会影响你应用Ajax的就是浏览器问题。如果大量用户(或者特别重要的用户)还在使用比较老的浏览器,如Internet Explorer 5、Safari 1.2或Mozilla 1.0之前的版本,Ajax技术就不能奏效。如果这是一些很重要的用户,就要使用针对目标用户的跨浏览器的方法,而放弃Ajax,或者开发一个可以妥善降级的网站。浏览器支持可能不是一个重要因素,因为Netscape Navigator4在市场上的份额很小;不过,还是应该查看web日志,看看你的应用适用什么技术。
如前所述,验证和表单填写就非常适合采用Ajax实现。还可以使用DOM的“拖”技术建立真正动态的网站,如Google的个性化主页。
可以看到,Ajax为Web应用开发提供了新的机会。你不会再因为以往的专用技术或表现不佳而受到妨碍。利用Ajax,胖客户与瘦客户之间的界限不再分明,真正的蠃家则是你的用户。
1.7 设计考虑
既然对在哪里使用Ajax已经有所认识,下面再来谈谈应用Ajax的一些设计考虑。许多原则与Web应用的原则并无不同,不过还是有必要强调一下。要尽力减少客户和服务器之间的通信量。如果应用得当,Ajax会使你的应用响应更快,但是如果每次用户从一个域移到另一个域时你都会来回传递超量的数据,用户肯定不会满意。如果有问题,按标准约定行事。如果大多数应用都那么做,可能你也应该那么做。如果还有问题,可以看看Web桌面应用的有关标准。为此已经建立了一些模式,而且以后还会有更多的模式 ()。
刚开始使用Ajax时,你的用户可能不清楚应用是怎么工作的。多年来我们一直在告诉用户:Web是以某种(同步)方式工作的,而Ajax则增加了异步组件,可能与之背道而驰。简单地说,不要让用户觉得奇怪。用户用跳格键离开最后一个域时,如果以前的应用(没有使用Ajax的应用)没有保存表单,那么使用 Ajax之后的应用也不要保存表单。
实现Ajax时最重要的问题是要力求简单:完全从用户出发,要尽量“傻瓜”(类似于“傻瓜”相机,用户只需最简单的操作就能得到想要的照片)。要把用户放在心上,不要去做“简历驱动的设计”(译者注:有的开发人员希望完成一个复杂的设计,以便写在简历里,来证明自己的能力)。如果只是想让新老板接受你,并因此在应用中使用Ajax,这是不合适的;如果使用Ajax能让你的用户有更丰富的体验,那就义无反顾地使用Ajax吧。但是,别忘了,只是因为你会做,并不意味着应该做。要理智一些,先考虑你的用户,这样才对。
我们后面还会更多地谈到安全,但是这里需要先说明一点,Ajax有一些安全考虑。记住,可以在浏览器中查看源代码,这说明任何人都能知道你是怎么创建你的小部件的。建立XHR对象时必须包含统一资源定位符(uniform resource locators,URL),所以可能会有恶意用户修改你的网站,运行他们自己的代码。谨慎地使用Ajax可以降低这种风险。
1.8 小结