乐者为王

Do one thing, and do it well.

Ajax:Web应用的一种新方法

英文原文:http://adaptivepath.org/ideas/ajax-new-approach-web-applications/

如果有任何关于当前的交互设计可以被称为“迷人”的话,那就是创建Web应用。毕竟,你最后一次听到有人吹嘘不在Web上的产品的交互设计是什么时候?(好吧,除了iPod。)一切都很酷,富有创意的新设计都是在线的。

尽管如此,Web交互设计人员仍不能不对创建桌面软件的同事们感到一丝羡慕。桌面应用有着在Web上似乎遥不可及的丰富和响应能力。让Web迅速扩散的同样简单也造成了在我们可以提供的体验和用户能够从桌面应用得到的体验之间差距。

这一差距正在缩小。看一看Google Suggest。观察随着你输入建议项更新的方式,几乎立即。现在看看Google Maps。放大。使用鼠标抓取地图并稍稍滚动。再次滚动,一切几乎立即发生,无需等待页面重新加载。

Google Suggest和Google Maps是Web应用的一种新方法的两个例子,该方法在Adaptive Path被我们称为Ajax。这个名字是异步JavaScript + XML的简写,它代表了Web上可能的根本性转变。

定义Ajax

Ajax不是一种技术。它事实上是几种技术,每种技术都在它自身正确的地方蓬勃发展,以强大的新方式聚合在一起。Ajax包括:

经典的Web应用模型是这么工作的:在界面上的大多数用户操作触发一个HTTP请求回Web服务器。服务器做一些处理——检索数据,精密计算,与各种遗留系统对话——然后返回一个HTML页面到客户端。它是改编自Web作为超文本媒介的原定用途的一个模型,但是如同用户体验的要素的爱好者所知,该模型让Web很好地适合超文本不一定能让它很好地适合软件应用。

图1:Web应用的传统模型(左)与Ajax模型(右)的比较。

这种方法很有技术上的感觉,但它无助于很好的用户体验。当服务器在做它的事情的时候,用户在做什么?没错,等待。在任务中的每一步,用户都在等待。

显然,如果我们从头开始为应用设计Web,我们不会让用户呆呆地等待。一旦界面被加载后,为什么每次应用需要从服务器获得什么时用户交互就将陷入停顿?事实上,为什么用户应该看到所有进入服务器的应用?

Ajax有何不同

Ajax应用消除了在Web上交互的开始-停止-开始-停止的本质,通过引入中介——Ajax引擎——在用户和服务器之间。它看起来像是给应用添加一个层而让应用更少地作出响应,但事实恰好相反。

在会话开始而不是加载页面的时候,浏览器加载Ajax引擎——用JavaScript编写并且通常藏在一个隐藏的Frame中。在用户方面引擎同时负责渲染用户看到的界面和与服务器通讯。Ajax引擎允许用户和应用的交互异步发生——独立于与服务器的通讯。因此用户永远不会开始于一个空白浏览器窗口和一个沙漏图标,呆呆地等待服务器做某些事情。

图2:传统Web应用的同步交互模式(上)与Ajax应用的异步模式(下)的比较

通常会生成一个HTTP请求的每个用户操作采取JavaScript调用Ajax引擎的形式替代。任何对用户操作的响应不需要回到服务器——例如简单的数据验证,编辑内存中的数据,甚至一些导航——引擎自己处理。如果为了响应引擎需要从服务器获得什么——如果这是提交数据以进行处理,加载额外的界面代码,或者检索新的数据——引擎异步发出这些请求,通常使用XML,没有拖延用户和应用的交互。

谁在使用Ajax

Google在开发Ajax方法上做了巨大的投资。在过去一年里Google推出的所有主要产品——OrkutGmailGoogle Groups的最新beta版本、Google Suggest,以及Google Maps——都是Ajax应用。(想了解更多这些Ajax实现的技术细节,可以查看GmailGoogle Suggest,和Google Maps的这些优秀分析)别人也在模仿:Flickr中人们喜欢的许多特性依靠Ajax,而Amazon的A9.com搜索引擎已经运用了类似的技术。

这些项目表明Ajax并不只是技术层面的论调,而且对实际应用也是实用的。这不是另一种只在实验室工作的技术。Ajax应用可以是任意大小,从非常简单、功能单一的Google Suggest到非常复杂和精密的Google Maps。

在Adaptive Path,在过去的几个月中我们已经使用Ajax完成了我们自己的工作,并且我们认识到我们仅仅触及到Ajax应用可以提供的丰富交互和响应能力的一点皮毛。Ajax是Web应用的一个重要的发展,并且它的重要性只会继续增长。因为外面有那么多的开发人员已经知道如何使用这些技术,我们期望看到更多的组织继Google之后率先获得Ajax提供的竞争优势。

继续前行

在创建Ajax应用中最大的挑战不是技术。核心Ajax技术是成熟的、稳定的、并且容易理解的。相反,挑战来自于这些应用的设计人员:忘记我们所认为我们知道的关于Web的限制,并且开始想象一个更广泛、更丰富的可能性的范围。

那一定会很有趣。

Ajax Q&A

2005年3月13日: 自我们第一次发布Jesse的论文以来,我们收到了大量读者关于Ajax问题的信件。在这个Q&A中,Jesse回答了一些最常见的问题。

Q. 是Adaptive Path发明的Ajax吗?还是Google?是不是Adaptive Path帮助构建了Google的Ajax应用?

A. 既不是Adaptive Path也不是Google发明的Ajax。Google近期的产品仅仅是级别最高的Ajax应用例子。Adaptive Path没有参与Google的Ajax应用的开发,但我们一直在为我们其它的一些客户做Ajax的工作。

Q. Adaptive Path正在出售Ajax组件或注册这个名字的商标吗?我从哪里可以下载它?

A. Ajax不是你能下载的东西。它是一种方法——思考使用某种技术的Web应用架构的一种方式。Ajax这个名字和方法均不是Adaptive Path专有的。

Q. Ajax仅仅是XMLHttpRequest的另一个名字吗?

A. 不是。XMLHttpRequest只是Ajax方程式的一部分。XMLHttpRequest是使异步服务器通讯成为可能的技术组件;Ajax是我们给文章中描述的整体方法的名字,它不仅依赖于XMLHttpRequest,还依赖于CSS、DOM和其它技术。

Q. 为什么你觉得有必要给出这个名字?

A. 当和客户讨论这个方法时,我需要使用比“异步JavaScript + CSS + DOM + XMLHttpRequest”更短的东西。

Q. 异步服务器通讯技术已经存在好多年了。是什么让Ajax成为一种“新”方法的?

A. 新情况是这些技术在实际应用中的突出使用改变了Web的基本交互模型。Ajax现在大行其道是因为这些技术和行业对如何更有效地部署它们的理解已经经过了时间的发展。

Q. Ajax是一个技术平台或一种架构风格吗?

A. 都是。Ajax是以某种特殊方式同时使用的一组技术。

Q. Ajax最适合什么类型的应用?

A. 目前我们还不知道。因为它是一种相对较新的方法,我们对Ajax最适用在哪些地方的理解仍处于初级阶段。有时候传统的Web应用模型是某个问题的最合适的解决方案。

Q. 这意味着Adaptive Path是反Flash的吗?

A. 一点也不。Macromedia是Adaptive Path的一个客户,而且我们是Flash技术长期以来的支持者。随着Ajax的成熟,我们希望有时候Ajax是特定问题的最好的解决方案,而有时候Flash 是最好的解决方案。我们也有兴趣探索技术可以混合的方式(正如Flickr的案例,它使用了两者)。

Q. Ajax有显著的可访问性或浏览器兼容性限制吗?Ajax应用会破坏后退按钮吗?Ajax兼容REST吗?Ajax开发时是否有安全考虑?Ajax应用可以为那些已经关闭JavaScript的用户工作吗?

A. 所有这些问题的答案是“可能”。许多开发者已经在致力于解决这些问题。要确定Ajax所有的局限性,我们认为有更多的工作要做,并且我们期望Ajax开发社区一起来发现更多这类问题。

Q. 一些你举出的Google例子根本没有使用XML。我必须在Ajax应用中使用XML和/或XSLT吗?

A. 不。XML是最全面发展的在Ajax客户端内外获取数据的手段,但没有理由使用JavaScript Object Notation之类的技术或任何类似的结构化数据的手段为交换不能达到同样的效果。

Q. Ajax应用比传统Web应用更易于开发吗?

A. 不一定。Ajax应用必然涉及到在客户端运行复杂的JavaScript代码。让复杂的代码高效并且无缺陷不是一个掉以轻心的任务,需要更好的开发工具和框架来帮助我们面对挑战。

Q. Ajax应用经常交付比传统Web应用更好的体验吗?

A. 不一定。Ajax给交互设计人员更多的灵活性。然而,我们拥有的能力越大,在运用它的时候我们必须使用的更谨慎。我们必须小心地使用Ajax来增强我们应用的用户体验,而不是削弱它。

这篇文章被来自Webhostinggeeks.com的Jovana Milutinovich翻译成了Serbo-Croatian语言。

Comments