如今这个时代，设计一个网站不用点 AJAX 的东西，那就绝对是落伍了。而用 AJAX 的话，要想得到良好的用户体验，必须要做到及时响应用户的请求。对于读取服务器数据这种比较慢的请求，进度条就是不可或缺的了。

作为整个网站设计元素的一部分，一个漂亮的进度条可以有效提高用户体验。Preloaders.net 就是这样一个 Web 2.0 服务，它可以交互式的，快速生成各种各样的动态进度条。而用户仅需要点点鼠标，设置一下样式、颜色、大小之类的参数就可以了，免去了我们用 Flash，Photoshop 之类画的麻烦。

事实上，类似 Preloaders.net 的这种服务有不少，之前我就曾经介绍过一个名为 Ajaxload 的站点。在免费的这类服务中，这两个我个人感觉用起来都是比较方便，而且样式也比较多。特别是今天介绍的这款 Preloaders.net，还提供了很多 3D 风格的动画样式，这些样式其中我很多都是第一次见，非常的别致，相信如果能够合理用到一个 Web 2.0 应用中，一定可以为它增色不少。

btw，Preloader.net 整个站点的设计也是超赞，我喜欢这种简约不简单的风格。

别被我的标题蒙了，其实今天介绍的主角是一个在线版本的元素周期表。虽然类似服务很多，但真正如现在介绍这个那么强大的还真没见过。

这张元素周期表上包含的内容很是丰富。不仅有元素名称，分子量等等这些常规数据，此外还包括了单质相转变点、外层电子排布等这些很专业的数据，非常不错。

而我说它 2.0，是因为这张周期表结合了众多 Web 特有的先进技术，例如 Ajax 等。最酷的是，当你点击每个元素时，它还会自动效用你所使用语言的 Wikipedia 中的相关数据并显示出来。这使得它在我们化学研究的实际应用中，也有了那么一点点用处了。

btw: 我毕竟还是个“准化学工作者”，所以遇上这类服务，难免要介绍一下，虽然我知道大多数看这里的朋友都用不到吧，见谅见谅。

看图，演示在这里。作者貌似在线，激活后不妨和他聊一聊。

区别于 Flash 版本的 Google Talk Gadget，这个网页版的 GTalk 是由纯 Javascript 写成的，而且也不是由 Google 官方开发的，作者 Zhou Renjian 貌似是个中国人吧。

作者貌似是用 Java 写成了这个兼容 Google Talk Jabber 协议的客户端，然后通过 java2script 转换为 Javascript，然后在进行大量的优化而成。同时作者推荐使用 Firefox 或 Opera 来浏览测试页面，因为 IE 的 Javascript 执行效率实在太低了。

目前这个项目还在 beta 阶段，不过基本 GTalk 的功能都有了，截图中就是我和作者聊天的界面，真是非常像 Google Talk。比较出乎我意料的是，这个程序发送和接收消息的速度都非常快，感觉不像是 AJAX 可以实现的，莫非是利用了 Gmail with Talk 中类似的 comet 技术？

有兴趣的朋友可以试试。当然，如果这个项目是个开源项目的话，大家可以一起来研究就更好玩了。

写 Blog 的人都会遇到一件很头痛的事情，就是在文章中为关键词加上链接。行文的时候最忌讳的就是思路被打断，但通常添加关键字链接时，我们不得不停笔去 Google 并获得链接。在这里我要隆重地为大家推荐 Linkify 这个小工具，有了它你可以把这个烦恼抛得无影无踪！via

Linkify 是一个浏览器 Bookmarklet，因此安装异常的简单。你只需要将这个链接 [linkify] 拖放到浏览器的收藏工具栏中就安装好了。

使用方面，Linkify 会让你感觉到无比的方便。当你在写 Blog 需要为一个关键词插入链接的时候，例如我要为 Google 插入链接，只需要选中 Google 这个词，然后点击收藏工具栏中的 [linkify]，Linkify 会自动调用 Google AJAX Search 返回 Google 搜索到的最佳结果。如果找到了满意的结果，你只需要点击 Create Link，你选中的词就会被自动加上超链接，当然，如果没有你满意的结果的话，你也可以点击“更多结果”或“全部结果”来进一步查找。

Linkify 的原理实际上是利用了 Google AJAX Search API，首先通过 Javascript 来查找页面中的 Textarea，然后获得 SelectRange，这样就获得了选中的词，然后再通过 Google Search 来处理。原理虽然简单，但是能够结合的如此只好，作者还是下了一番心思的。我认为这是我目前见过的，将 Google AJAX Search API 利用的最好的应用。

我自己测试了一下，在 WordPress 中 Linkify 是可以使用的，如果你也有博客的话，你应该试试这个小东西。

作为 Blog 这一 Web2.0 的先锋应用，似乎还没有和 Ajax 这项 Web2.0 的特色技术结合。虽然目前有这样的尝试，例如 Bloxpress 以及在很多 Blog 上出现的 Live Search，但给我的感觉是这些 Ajax 应用非但没有给用户带来什么便利，反而打乱了用户的浏览习惯。作为 Web 设计者，如何合理的使用 Ajax 技术成为一个很关键的问题。Alex Bosworth 的这篇文章讲述了几种必须要用 Ajax 的情况以及几种不应该应用 Ajax 的方面，写的很不错，有兴趣的可以看看。不过对于这个问题的理解，每个人应该都不会太一样，Google 的 Gmail 同样会用 Javascript 更换大量的页面内容，由此还获得了非常好的浏览器兼容性。所以有的时候还是要看具体应用来决定。

原文：

It’s been well over a year now since GMail changed the way everyone thought about web apps.

It’s now officially annoying to use web apps that haven’t replaced clunky html functionality with peppy Ajax goodness.

Here are places Ajax should now be required in a web application:

* Form driven interaction.

Forms are slow. Very slow. Editing a tag on a del.icio.us bookmark? Click on the edit link to load the edit bookmark form page, then edit the field and hit submit to wait for the submission to go through, then return to the previous page and scroll down to find the bookmark to see if the tags look right. Ajax? Click on the edit link to instantly start changing tags, click on the submit button to asynchronously send off changes to the tags and quickly see in place what changed, no reloading the entire page.

* Deep hierarchical tree navigation.

First of all, applications with deep hierarchical tree navigation are generally a nightmare. Simple flat topologies and search/tagging works very well in most circumstances. But if an application really calls for it, use Javascript to manage the topology ui, and Ajax to lessen the burden on the server by lazy loading deep hierarchy data. For example: it’s way too time consuming to read discussion threads by clicking through and loading completely new pages to see a one line response.

* Rapid user-to-user communication.

In a message posting application that creates immediate discussions between people, what really sucks is forcing the user to refresh the page over and over to see a reply. Replies should be instant, users shouldn’t have to obsessively refresh. Even Gmail, which improves on the old hotmail/yahoo mail ‘refresh inbox, refresh inbox’ symptom, doesn’t really push Ajax far enough yet in terms of notifying new mail instantly.

* Voting, Yes/No boxes, Ratings submissions.

It’s really too bad there are no consistent UI cues for Ajax submission, because submitting a vote or a yes/no response is so much less painful when the submission is handled through Ajax. By reducing the time and impact of clicking on things, Ajax applications become a lot more interactive – if it takes a 40 seconds to register a vote, most people would probably pass unless they really care. If it takes 1 second to vote, a much larger percentage of people are likely to vote. (I have 2008 movie ratings on Netflix versus 210 ratings on IMDb.com).

* Filtering and involved data manipulation.

Applying a filter, sorting by date, sorting by date and name, toggling on and off filters, etc. Any highly interactive data manipulation should really be done in Javascript instead of through a series of server requests. Finding and manipulating a lot of data is hard enough without waiting 30 seconds between each change in views, Ajax can really speed this up.

* Commonly entered text hints/autocompletion.

Entering the same text phrases or predictable text phrases is something software/javascript can be good at helping out with. It’s very useful in del.icio.us and GMail, for quickly adding tags/email addresses.

For heavy use applications such as a webmail client or a blogreader, users have the luxury of time to learn new UI concepts, and the frustration of interacting with a slow interface. This kind of application is a perfect opportunity to leverage Ajax everywhere. The more frequently users use an application, the more Ajax should be powering that use.

However for most web applications, it doesn’t make any sense to use Javascript for everything or even anything. Ajax only really clearly helps in a limited set of circumstances; the web already worked pretty well before Ajax and there are a lot of pitfalls and drawbacks to using Ajax in web development. A straight html weblog works just fine without being generated dynamically on the client with a stream of asynchronous messages from the server. Plain old HTML also works great for documents, or navigating between documents. Simple or rarely used applications can get along fine without putting in a bunch of Javascript.

Here are some places Ajax shouldn’t be used:

* Simple forms.

Even though forms are the single biggest beneficiary of Ajaxification, a simple comment form, or submit order form, or other one-off rarely used form does not benefit from Ajax driven submission. Generally, if a form is not used much, or it’s critical to work properly, Ajax is not that helpful.

* Search.

LiveSearch on blogs is more annoying than useful. There’s a reason that Google Suggest is staying in beta and not going on the front page of Google. Searching on Start.com Live.com doesn’t allow use of the back button to see a previous search, or previous pages. Maybe it’s possible that no one has gotten this right yet, but getting this right is hard enough that it’s generally not a good idea, or more trouble that it’s worth.

* Basic navigation.

In general, driving basic site/application navigation using Ajax is an awful idea. Why would anyone want to spend time writing code to emulate the browser behavior when they could spend time making their application better? For basic navigating between documents, Javascript doesn’t help.

* Replacing a large amount of text

Ajax saves a complete refresh of the page, so small pieces of the page can be more dynamically updated. But if nearly everything on a page is changing, why not just request a new page from the server?

* Display manipulation.

Even though it seems that Ajax is purely a UI technology, it’s not. It’s actually a data synchronization, manipulation and transfer technology. For maintainable and clean web applications, it’s a good idea not to have Ajax/Javascript manipulate the interface directly at all. Javascript can stay separate and simply manipulate the XHTML/HTML DOM, with CSS rules dictating how the UI displays that data. See this post for a simple example of using CSS instead of Javascript to control display.

* Useless widgets.

Sliders, drag and drops, bouncies, mouse gestures, whatever. Mostly these widgets can be replaced with more intuitive controls, or eliminated altogether in favor of simplicity. In picking colors, maybe a slider widget is useful to pick the exact shade. But in picking a price point in a store, a slider to pick the price to the cent is just overkill.

OK I fibbed in the title, I only posted 6 places Ajax should be used and 6 places it probably shouldn’t. But look at this post more four-dimensionally; I have set up a wiki page on SWiK for places to use Ajax, and I or anyone else can fill in more places Ajax is useful as time goes by.

BTW, I’m now trying to use Feedburner to track my RSS feed, if you aren’t subscribed to the feedburner feed, please subscribe to http://feeds.feedburner.com/AlexBosworth.

Live.com 从使用上和 Start.com 没什么区别，除了聚合 Feeds 外，通过 Gadgets 扩展 Live.com 的功能才是她最精彩的地方。目前可以使用的 Gadgets 还不是很多，微软为了完善自己的产品服务在前不久开通了 MicrosoftGadgets.com。现在如果提交一个优秀的 Gadgets 到 Live.com，一旦被采用，有可能获得一台 XBox 360，看似还是有一定吸引力的。

伴随 Live.com 开张，微软新的一个品牌 Windows Live 正式诞生了。微软现阶段 Windows Live 产品主要为 Live.com，Windows Live Mail Beta 和 Windows Live Messenger Beta。Windows Live Mail Beta 是基于 Hotmail 的产品，利用了 Ajax 技术使用户通过浏览器就可以达到几乎和 Microsoft Outlook 同样的效果，目前已经可以申请参与测试；Windows Live Messenger 则是 MSN Messenger 的接班人，Messenger Blog 中已经声明 7.5 将是最后一个版本的 MSN Messenger，后作将全面使用 Windows Live Messenger 这个名称。据称新版本的 Messenger 会加入 VOIP ，并且应该会完成与 Yahoo! Messenger 用户互通，非常值得期待。

很明显， Windows Live 系列是微软面对 Google 重压下的一次反击。微软从不缺乏技术人员，只是垄断让他们丧失了部分创意的灵感。不过“影印”是微软的长项。更何况 XMLHTTP 的概念就是微软发起的，微软这个全面借鉴 Google 成功产品（Gmail，GTalk）的经验，加上自身的优势和实力，顺应 Web 2.0 和 Ajax 技术发展的大潮，适时推出 Live.com，可以看做是微软对下一代桌面掠夺战的开始。下一代桌面必然是基于互联网的“个性化信息和服务聚合体”，Live.com 基本上符合这个定义，而且支持自定义 Gadget，在现有同类产品中自定义程度最高，最符合 Web 2.0 开放 API 的特点。微软声称在今后的几个月会有更多“Live”的产品，将您全部的工作集成到一起，感觉颇有 Web OS 的意味，不知道 Google ig 是不是也会有针对性的动作呢？拭目以待吧。

新版的 Y!M 界面非常类似我们平常使用的邮件客户端（如 Thunderbird），可以推测肯定使用了时髦的 Ajax 技术。支持拖放，而且从截图上看拖放的效果非常的酷。Ajax 的大量应用，让 Web Application 成为了现实。未来传统的客户端软件将一步步被 B/S 架构的应用程序蚕食。怪不得微软和 Google 都如此看中浏览器市场。

由于目前还没有用到，更多的特性也就无法了解了。但据内测者反应目前还不支持 Tag 功能，这点我觉得应该添加上，毕竟容量上 G 的邮箱如果没有类似于 Tag 的东西来组织的话的确会非常麻烦。另外我比较期待的另一个功能就是类似 Gmail 的 Feed 输出。对于我这样的 Yahoo! Mail 的忠实用户来说，对于新版 Y!M 还是非常期待的。

Ajax 原理就是通过浏览器的 XMLHTTP 对象（各种浏览器有所不同），通过 Javascript 在不刷新页面的情况下向服务器提交页面信息，接收服务器反馈并呈现的一种技术。Ajax 最大优势就在于“无刷新”。这就意味着我们在提交页面信息时不需要刷新浏览器页面。通过这种方式，可以根据用户的浏览行为，实时变更页面上的信息，提供用户最佳的浏览体验。Gmail 就是一个非常出色的 Ajax 程序，Gmail 借助于浏览器，给我们带来接近传统邮件客户端的体验，离开 Ajax 是很难做到的。

实现 Ajax 的方法很多，大家可以自己 Google 一下。如果用 PHP 的话，开源项目 xajax会大大降低开发工作的负担。xajax 有非常好的跨浏览器支持，据我测试对同时发出的多个 XMLHTTP 请求的处理情况也令人满意。

学习一种技术，实践是最好的方法。题图中就是我的第一个 Ajax 作品：iReader。iReader 是一个在线的 RSS 阅读器。借助于 Ajax 技术，使页面在无刷新的情况下便可以实时读取 RSS Feed 并将其格式化好并呈现给用户。仿照 Gmail，我也做了一个类似“应用软件”的界面，没想到做这个界面还是费了一番周折。纯 CSS 很难实现这种效果，最后还是借助了 Javascript 来实现效果。这个程序存储 Feeds 的文件为 OPML 格式，为此我还写了一个小小的 OPML 解析的类。

值得一提的是，写这个程序我只有很少的代码是自己写的，其余均使用开源代码。Ajax 使用 xajax，RSS 读取和解析使用的是 MagpieRSS。此外我还使用了一个开源的 Tree 控件。写程序的整个过程就像搭积木一样，感觉有点从前用 Visual Basic 写程序的感觉。

最后，提供 iReader 代码的下载：iReader 0.1 Alpha，基于 GNU/GPL 协议发布，演示。

ps: 谁能推荐一款国内外的 CPanel 空间？现在用这个太慢了，无语了……

目前 meebo 还在 Alpha 阶段（汗，Alpha 就公测了）。虽然基本功能都有了，但 Alpha 意味着还有相当多的预期目标没有实现。而我比较关注的是什么时候它加个 GTalk 呢？

在这个周期表中，当我们点击一个元素时，就会探出相关的详细信息。此外，我比较喜欢的是在这个详细信息中，我们可以链接到 Wikipedia 中去寻找关于这个元素的更多资料。这样，在一般的元素性质查询中，Wikipedia 提供的资料基本就够了，省却了翻手册的麻烦。

看来计算机和化学相结合的方面还是蛮多的，连 Ajax 都用上了，呵呵。