主题是文档重绘、测试、发布和订阅问题、性能、可访问性、对老版本浏览器的支持以及宣称自己的目标。我还将提到 ajax 带来的一种有趣的可能性：在网站中开发网站。

　　chris laffra 的这篇文章继续讨论 ajax 开发人员在开发应用程序时需要记住什么。除了具体的建议和忠告外，还展望了 ajax 的未来，它推动了个人网页上内容的用户导向型混合。

　　本系列的第一期文章中(审视ajax - 透过华而不实的广告看本质)，我讨论了目前环绕着 ajax 的不实之词。您还了解到，可靠的框架仍然未完成，应该考虑导航历史、书签功能、反馈、持久性、并发安全问题。

　　接下来的这篇文章中，主题是文档重绘、测试、发布和订阅问题、性能、可访问性、对老版本浏览器的支持以及宣称自己的目标。我还将提到 ajax 带来的一种有趣的可能性：在网站中开发网站。

　　迷路了

　　移动鼠标光标对应用程序而不是用户来说是一个糟糕的主意。这是一条众所周知的用户界面(ui)设计法则，无论代价多大都应避免这种移动。ajax 应用程序也有类似的规则：不要替我滚动窗口。如果异步的 ajax 响应从服务器上返回，文本被粘贴到当前文档视图上方的 dom 元素中，浏览器就会向下滚动内容。结果是让人摸不着东西南北。

　　ajax 的问题是把文档看成它并不是的东西。google maps 没有这个问题 ―― 基本上不需要滚动条。这是因为它实际上就象一个应用程序。但是，如果很长的 gmail 贴子，迷路的危险就很现实，因为有滚动条，点击任何一栏都会重新排列窗口的内容及其滚动条。

　　如果最终结果在当前视点之前，将文档看作应用程序的 ajax 应用程序应该避免更新文档。视点管理和有条件的 dom 操作不是可有可无的，因此 ajax 应用程序本身应该准备好忽略 返回时间太长的响应。为了保持连贯性，最好增加重试或刷新按钮。

　　建议：明确避免移动滚动条这类智能化操作。

　　测试

　　“不停地测试，产品就会不断地改进。”―― david ogilvy

　　ajax 开发是一种多平台的开发，需要进行多平台测试。细微的差别、不兼容的事件模型、难以协调的 dom 不兼容性等等迫使 ajax 开发人员编写防卫代码来处理种种差别。

　　大多数自动化的屏幕测试工具都明确宣称不支持 dhtml。由于动态 html 移动页面对象和动态改变 dom 结构，自动测试工具无法知道 ui 到底是什么样子，更重要的是，不知道如何驱动它。想想 start.com 的网站，怎么来测试它。我想不出您有什么办法，除非低价雇佣大批志愿测试者。

　　虽然 javascript 使得自动化测试更加困难，但 ajax 有一个优点：服务器上服务的组件化(原子化)允许对业务逻辑进行更小粒度的测试。从而能够进行高覆盖和可变性的函数测试。

　　推在哪儿?

　　图 1 显示了过去的一个神话：基于 pointcast 的推技术。

　　图 1. 推技术的应用

　　pointcast 大约在 1996 年引起了一个神话般的风潮，它提供了一个免费阅读器可以在网络上推免费的内容(和广告)。pointcast 2.6 需要一台 486/33 处理器、8 mb 内存、10 mb 磁盘空间的 pc 机，照今天的标准来看简直太低了。

　　如果比较 pointcast ui 和 start.com 就会发现惊人的相似。当然人们要问 ajax 比 pointcast 强在哪儿。除了高分辨率图像、阴影和平滑拖动所体现的高保真性以外，基本上 ajax 对用户关注什么仍然只能提供有限的信息。

　　ajax 缺少对发布-订阅体系结构的支持，因为除了 http 流之外，没有打开到 ip 地址的稳定套接字连接的标准方式。比方说，通过 flash 的 xmlsocket 对象和 flash/javascript integration kit，ajax 应用程序可以打开到 mqseries 服务器的稳定的全双工 tcp/ip 套接字流。但是，这种应用程序需要在客户机浏览器上安装 flash 播放器。目前，ajax 应用程序只能轮询加载它们的服务器，本质上是把服务器作为到数据服务器的代理/网关使用。这可能会给网络增加额外的负担，服务器也不大可能经受住数千甚至几百万(成功的代价)用户不断地轮询。需要一种新的体系结构。

　　cpu 和泄漏

　　现代桌面计算机变得越来越快，但是把代码从服务器环境转移到桌面上意味着把要求放在不那么容易升级的环境中。内存越来越便宜，512 mb 只要 25 美元，但是考虑到要安装的基数，成本也是惊人的。慢的机器将来不及处理那些 dhtml 动画和 dom 操作生成的命令。在 html 内容以外发送的代码越多，网站加载的速度越慢。

　　大多数人不知道，javascript 就有泄漏的倾向。如果不小心，浏览器的内存需求将在整个浏览会话周期中不断增加。过去 cpu 的效率限制了 javascript 的采用。随着浏览器变得越来越快，部分原因要归功于激烈的竞争，记住，很多用户的桌面机并没有一般开发人员机器装备的那么好。

　　可访问性

　　残疾人士的可访问性很少受到一般开发人员的关注。但即便没有法律上的要求，开发人员还面临着道德问题，必须考虑让残疾人士能够访问网站的技术准备。由于声明性特性，html 利用本身非常简单解决了这个问题：比方说，屏幕阅读器可以处理它，视觉偏弱的用户可使用大字体。

　　动态 html 给网站带来的是不断改变其结构。盲文计算机、屏幕阅读器和基于语音指令的导航工具很难应付这种不断的变化。

　　javascript：还没有普及

　　thecounter.com 2005 年 10 月对浏览器的统计结果表明，全部 web 浏览器中有 10% 关闭了 javascript 或者不支持。这要好于 2001 年的 16%，但是网站还是要面对那些不想运行 javascript 的用户。

　　不支持 javascript 的最知名的一类浏览器是搜索机器人。依赖于 ajax 技术的网站必须特别注意保证自己仍然出现在搜索查询中。meta 中的关键字可以帮助定向搜索引擎。另一方面，对于向包打听似的搜索机器人隐藏 某些内容 ajax 可能很有用。

　　目的

　　传统上，web 上的链接把您带到另一个地方，所有用户都知道并期望这一点。此外，底层的 get 请求被认为是无状态的。虽然据我所知还没有标准，但是浏览器和搜索引擎都认为 get 请求服务的链接是无状态的。如果 ajax 应用程序使用链接来改变状态，那么相关各方就会被搞糊涂的，包括可怜的用户。

　　不要期望用户非常灵活，知道如何通过在屏幕上拖拉来个性化自己的体验。他们可能根本不想这么做。此外，还需要用清楚、明确的话告诉用户要做什么，这可能是美国有这么多路标中包含文字的原因吧。一个领域的比喻，比方说 linux/php 脚本黑客，不一定适用于其他领域，比如 50 岁的保险推销员。有些直观的比喻可能在一种文化中很酷，而在其他文化中可能是无礼的行为。

　　简言之，您需要明确说明自己的目的，尽可能减少交互的次数，并假设您的用户中有新手和没有经验的用户。个性化很重要，但是不要将其添加到应用程序中而损失可用性，也不要让它妨碍国际化支持之类的实现。

……

查看原文