在应用程序中使用 Ajax 的时机
邂逅 Ajax
当使用 Asynchronous JavaScript + XML (Ajax) 开发技术增强的应用程序第一次出现在网上时，Web 开发人员肃然起敬。一夜之间，Web 站点和 Web 应用程序的潜在价值似乎变得无穷无尽了。过去，许多开发人员和用户认为，Web 站点和 Web 应用程序只是其桌面应用程序的一个粗燥、丑陋、复杂的版本而已。但见识了 Ajax 增强的应用程序和 Web 站点之后，开发人员和用户不约而同地意识到，在浏览器中可以做的事情超乎想象。随着如今的 Web 浏览器拥有了处理高级文档对象模型（Document Object Model，DOM）脚本和复杂层叠样式表（Cascading Style Sheets，CSS）的能力，需要创建一种能够更改、更新，以及通过与后台服务器对话立即响应的接口，而 Ajax 给这一任务划上了圆满的句号。但是，有时候由于太过兴奋导致了用户体验不太理想。
Web 开发的游戏规则已经改变了，许多开发人员一有机会就使用 Ajax 完成工作。许多站点甚至放弃了超文本标记语言（HTML），而转为完全使用 JavaScript™ 构建站点。
 |
|
如果问一般的 Web 用户觉得 Ajax 技术怎么样，他（她）可能只会茫然的看着你。许多用户都不关心他们使用的网站的构建技术。他们对好的用户体验更感兴趣，即能够尽可能轻松地完成所需的工作，至于应用程序的具体结构，就让它安全地呆在后台吧。
本文分析 Ajax 的能力，同时探讨什么情况下使用 Ajax 将会弊大于利。希望您能从中获得灵感，能以从未想过的方式使用 Ajax，也希望您不至于因为构建一个流行站点而疯狂。
 |
摆脱刷新
没有比不停地刷新 Web 页面更加烦人的事情了。对于那些等着看自己是否赢得拍卖、关注比赛得分、密切关注天气预报的用户来说，Ajax 对这些类型 Web 页面的增强可以极大地提高用户体验。
在 Ajax 技术出现以前，已经可以使用简单的 JavaScript 代码实现 Web 页面的自动更新。但是，更新 JavaScript Web 页面需要刷新整个页面。这就是为什么 Ajax 技术在 Web 应用程序中的出现会对 Web 产生如此重大的影响。
用原来的方法刷新页面时，用户无法与之交互。Ajax 页面可以异步地（Ajax 中的 A） 向 Web 服务器请求数据，用户完全无法察觉后台正在处理事务。返回数据之后，只会更新部分页面。
|
Web 不需要实时
自动更新部分页面使用户摆脱了刷新之苦，但对 Web 服务器架构却是一场灾难。如果 Web 站点一天只有 1,000 个访问者，Web 服务器也许还能够应付。但是如果该站点的每个 Web 页面每秒钟使用 Ajax 刷新一次，平均每个用户打开该页面 10 分钟，那么该站点每天的页面请求将暴增到 600,000 次。
为了避免 Web 服务器出现这种情况，开发人员一定要注意最小化更新频率。如果知道信息每隔几分钟才更新一次，可以尝试将 Ajax 请求调整为相同的频率。如果信息每秒更新一次，则可以考虑在不损害用户体验的情况下尽可能延长刷新间隔时间（比如，每 5 秒或 10 秒刷新一次）。
还可以提供一个简单的刷新链接，只有在用户需要时才触发 Ajax 调用。这类似于浏览器的 “刷新” 按钮，但是，如果只需获取一小部分数据，这种方法更加快捷，对 Web 服务器的要求更低。
|
小变化，大影响
Ajax 的优势体现在对页面进行较小的修改和更新时。曾几何时，即使是微小更新也需要刷新整个 Web 页面。借助 Ajax 和 JavaScript 代码，页面能够几乎实时地进行更新。例如，可以让页面在添加新注释时更新注释列表、显示一个关于最新条目的纸条，或者实时显示进度条。
开发人员的关键目标应该是增加可用性，也就是方便用户。用户在等待页面做出反应时可能会觉得他们在浪费时间，在 Web 应用程序引入 Ajax 之前，许多用户更倾向于使用桌面应用程序，因为桌面应用程序更加快捷，反应更加迅速。Ajax 增强消除了等待和滚动时间，它使 Web 应用程序的响应能力达到了许多传统桌面应用程序的水平。
|
大变化，大灾难
如果说对页面进行小的更改可以增强用户体验，那么大的改动（比如几乎或完全替换整个页面的内容）则可能让用户不知所措并导致不好的结果。
如果站点使用 Ajax 更新的速率过快，用户可能会以为后退和前进按钮以及书签出现了问题。（Flash 站点与纯 Ajax 站点一样，也容易使人产生这种感觉。）用户希望可以单击后退按钮返回上一页或上一个视图。更加不利于用户体验的是，当用户再次单击前进按钮时，他们没有回到刚才查看的那个视图，而是回到了初始页面，就像刷新了 Ajax 站点一样。
如果用户临时加载了一个页面，然后返回到刚才查看的站点，结果发现页面已经变了，那么他们可能会很失望。不幸的是，浏览器很可能将页面加载为初始状态，经常丢失所有的更改。与此类似，如果用户希望与他人分享某个站点的特定视图或页面，或者将一个页面加入书签，他们认为并相信只需要从浏览器复制 URL 并使用即可（目前确实如此）。
如果页面的内容更改过多，使用户感觉像是一个新的页面，那么还不如直接向他们发送一个新页面。但是，如果开发人员确实需要使用 Ajax 更改页面内容，最好使用 Ajax History 工具存储后退和前进按钮以及书签功能。这些工具使用哈希值（例如，“#tab3”）改变 URL，而无需加载一个新页面。当用户单击后退或前进按钮，或者加载一个加入书签的 URL 时，JavaScript 代码查看哈希表并重新生成用户希望的视图。当然，这只对支持 JavaScript 语言的浏览器有用。
|
释放 Web 页面的信息
您可能已经注意到了，Internet 还有另一个重要特征：似乎可以访问无限量的信息，而无需在本地机器上进行复制。有了 Ajax，您可以构建一个与某个巨大数据库（无论它位于全球的哪个服务器）连接的互动界面，实现前所未有的功能。
Google Maps 就是这种 Ajax 应用程序之一，它集中体现了开发人员和用户的想象力。在这个 Web 站点上，您可以浏览整个地球的地图和卫星照片，而无需刷新页面。以这种方式释放数据可能是 Ajax 最具价值的潜在用途。
在 Google Maps 出现之前，地图网站已经出现了很多年，但是 Google Maps 是与众不同的，因为 Ajax 所允许的界面是前所未有的。在传统的地图网站上，将视图向西移动需要单击一个链接。然后出现一个新页面，它包含生成的调整后的地图。所以必须等待页面清除，再次加载，然后滚动到该地图。
这种糟糕的界面是由 Web 的根本局限性导致的。获取 Web 服务器数据的惟一方式是访问一个新的 URL，然后下载包含新内容的新 Web 页面。如果希望查看当前视图任何微小更改（比如向西移动一点），必须加载整个新地图。由于 Ajax 允许在后台异步获取数据，因此无需清除和加载整个页面。只需要加载地图的数据和图片碎片。也可以为特定的地图视图生成 URL，但这不再是加载更多信息的惟一途径。
您可以使用 Web 页面作为许多其他场景数据的界面。考虑一个分页场景，比如查看分为很多页的搜索结果时。用户界面控件（比如上一页和下一页）不需要每次都加载整个新 Web 页面。使用 Ajax，您可以异步加载下一页的结果，并相应地更新页面。甚至可以预加载下一页，以便在用户希望查看时立即显示。
通过文档与信息的分离，还可以加快速度并节省带宽。大多数情况下，可扩展标记语言（XML）或者 JavaScript Serialized Object Notion (JSON) 形式的原始数据比 Web 页面的 HTML 表示形式要小，特别是页面的剩余部分（比如标题、导航、脚注尤其明显）。
|
将信息留在 Web 页面上
Ajax 打开了从 Web 服务器获取原始数据的方便之门，但这并不意味着您不再需要老式的 Web 页面。用户能够通过 URL 访问数据片断很重要，因为这样才能与他人分享。
Ajax 还能让搜索引擎抓取您的站点。针对搜索引擎对站点内容进行优化不仅仅是为了将用户吸引到站点中，它同时也是一个可用性问题。您也许通过搜索引擎找到了大多数要用的站点，也可能只使用大多数站点的一两个页面。如果站点提供的内容被隐藏在 Ajax 技术背后，那么搜索引擎将无法搜索到，从而世界上大多数人都无法找到您的站点。因此让站点的信息可以通过传统的 HTML 页面浏览非常重要，即使还可以通过 JSON 或 XML 浏览。
|
Ajax 可以拯救站点
Web 用户界面通常能够让用户在 Web 服务器上保存数据，或者轻松创建、更新、删除条目。 当然，这些任务总是能够通过 HTML 形式实现，但是 Ajax 能更加便捷地在后台异步发送数据。试想使用 Ajax 和 JavaScript 代码简化添加、编辑和删除内容，它们使条目列表的管理变得更加简单。还可以增强单个条目的添加，比如在消息板上编写，只需要使用 Ajax 向服务器发送消息，然后使用 DOM 脚本将消息立即添加到页面。
|
Ajax 可以毁灭站点
大多数用户不希望 Web 站点使用 Ajax；很多用户甚至从未听说过 Ajax。因此，在使用 Ajax 设计页面时，一定要确保程序与目标用户能够交流。例如，如果使用 Ajax 向服务器提交一个表单或发送数据，则在发生以下动作时，应用程序必须与用户进行交流：
- 正在发送或获取数据时。此动作常常通过动态图片指示，比如一个旋转指针，或者通过短语 “Loading…” 或 “Saving…” 指示。
- 成功发送或获取数据时。可以显示 “Success” 消息，也可以使用 JavaScript 动画将用户的注意力吸引到页面的特定部分。
- 与 Web 服务器对话过程中出现错误或超时。通常给出一条解释消息，提示用户再试一次。
如果应用程序无法交流，则用户将不知道到底发生了什么事情。如果单击 Form Submit 按钮时什么也没有发生，则用户会认为 Web 站点出了问题。如果应用程序无法提示发生了错误，则用户一般会认为他们的操作成功。如果实际情况是没有成功，那么用户的这种假设可能导致极度的失望，尤其是花了很长时间完成表单内容时。如果应用程序在出现问题或超时通知用户，至少用户还有机会进行复制粘贴，在本地保存数据，从而避免了最糟的用户体验。
|
寻找 Ajax 力量的平衡点
|
|
Ajax 使 Web 创新成为可能，但同时增加了违背用户意愿的可能性。请记住，在向站点添加 Ajax 的同时，您也必须为用户修复它导致的任何问题。
渐进式增强 是一个 Web 开发战略，它能确保所有的内容和功能可用于所有的浏览器，但是也支持更加先进的 Web 浏览器利用 JavaScript 编程和 Ajax 创造更好的用户体验。为了帮助确保应用程序的设计能提供最好的体验，最好遵守渐进式增强的黄金法则：首先不用任何 JavaScript 代码开发，然后在站点开始运行后添加 JavaScript 代码。从根本上说，您构建一个基本的 Web 站点，让实际链接和表单都指向真实的 URL。然后，使用 JavaScript 编程和 Ajax 更改这些链接和表单的功能。
例如，假设您希望有一个评论表单能够使用 Ajax 提交评论，并能更新页面以在合适的位置显示评论，所有过程都不需要刷新页面。首先，像往常一样构建评论表单，不使用任何 JavaScript 代码，保证它能正常运行。接下来，向表单添加一个 JavaScript onsubmit 事件。表单提交时，使用 Ajax 将评论保存到服务器，使用 DOM 脚本更新页面。这样一来，对于不支持 JavaScript 语言的 Web 浏览器表单也能运行良好，对于更先进的 Web 浏览器将会运行的更好。
有些 Web 站点完全使用 JavaScript 代码和 Ajax 构建，我建议在任何情况下都应该避免这样做。构建这样的站点意味着将一部分潜在的网络人群排除在外，而且不仅仅是选择禁用 JavaScript 语言支持的用户。同时被排除在外的还有搜索引擎，以及在 Web 上进行搜索的人。此外，使用未经测试的设备和浏览器访问站点内容的潜在用户也被排除在外。请记住，对于纯 JavaScript 站点，最微小的 JavaScript 错误也会导致整个站点的损坏。如果有非 JavaScript 站点的支持，就可以确保不会阻挡任何潜在用户（和潜在客户！）访问您的内容。
|
结束语
Ajax 彻底颠覆了开发人员构建 Web 应用程序的方式，其结果可好可坏。重点在于要确保选择在应用程序中包含的 Ajax 增强能提高用户体验。尽可能避免出现令人混淆的、不可预计的，以及让人失望的情形。对于许多开发人员，这些决策可能关系着公司的成败。