Ajax

French | Spanish | Portuguese | Italian | German | Japanese | Chinese | Korean | Russian | Arabic

Given the recent interest in Ajax, you’d be forgiven for thinking it was a new technology. In fact, the XMLHttpRequest object has been around for years. In technical terms, asynchronous JavaScript interaction with the server is nothing new. All of the other elements of the Ajax model have also been around for quite some time: CSS, (X)HTML, and DOM Scripting. Yet in 2005, interest in this methodology soared. Could it really be that simply giving this approach a snappy name like Ajax was responsible for the sudden interest? In truth, interest in the new approach to building websites was on the rise even before Jesse James Garrett coined the term “Ajax.” This increase in interest was fueled by the appearance of new web applications from Google.

When Google launched Gmail, a web-based email service, the initial focus was on its large storage capacity (http://mail.google.com/). Once people began to interact with the service, other features came to the fore. Gmail employs spellchecking, auto-completion of addresses, and other processes that are carried out transparently in the background. The front end of the web application is asynchronously transferring data to, and receiving data from, the server.

Interest in the XMLHttpRequest object was piqued further when beta testing began on Google Suggest, http://www.google.com/webhp?complete=1. When the user begins typing a phrase into the search field, suggestions for completed phrases appear in a list below. Every time the user types a letter, a call is made to the server for a new list of suggestions. This kind of feature is effective because the client/server interaction is happening asynchronously. If the page were reloaded every time the user typed a letter, Google Suggest would be far less usable.

Google supplied the working examples, and Jesse James Garrett provided a snappy marketing term. Ajax is primed and ready for take-off.

Ajax challenges

Ajax is here to stay, of that I am certain. On the whole, I think that the Ajax methodology will bring a lot of benefits. It can improve the usability of websites by providing very fast responses to user actions without refreshing the whole page. At the same time, this new approach also presents a number of challenges.

One of the features of Ajax applications is a reduced number of individual page loads. The downside to this state-saving technology is that it interferes with browsing conventions such as using the back button or being able to bookmark individual pages. The ability to update just part of a page also alters user expectations. Ideally, every action taken by the user should have a clear and obvious result. Web designers must rise to the challenge of providing meaningful feedback when the user initiates a request to the server and when the server provides a response.

There’s no doubt that Ajax is a powerful tool but, as with any powerful tool, it could be misused. There is a danger that, right now, at the very moment that JavaScript is becoming an accepted technology, Ajax could return us right back to square one if it garners a reputation for being awkward and inaccessible. This is something that we as web designers need to avoid. The key to building a successful Ajax application is to treat it like adding any other JavaScript enhancement. Apply progressive enhancement in order to provide graceful degradation.

Progressive enhancement with Ajax

Because Ajax applications can provide fast, transparent responses to user actions, they are often likened more to desktop applications than traditional websites. There is a certain amount of truth to this comparison, but it can be taken too far. There is a danger that the use of Ajax could be seen as carte blanche to ignore usability and accessibility considerations associated with traditional websites.

Already, sites are emerging that use Ajax and specify JavaScript as a requirement for accessing content. The argument offered as justification for this approach is that the features that are provided are so rich in nature that they couldn’t possibly degrade gracefully. I don’t buy it. In fact, I believe that Ajax applications, by their very nature, can always offer a non-Ajax alternative. It all depends on how the Ajax functionality is applied. If Ajax is included as part of the functionality from the start, then it will be very hard to decouple it at a later stage to provide a non-Ajax version. If, on the other hand, the application is first built using old-fashioned page refreshes, Ajax can be applied on top of the existing framework to intercept requests to the server and route them through XMLHttpRequest. The Ajax functionality then sits like a layer over the regular site. Does this sound familiar? This is no different from the technique of progressive enhancement that you’ve seen employed throughout this book.

Building Ajax functionality into the core of an application from the start is equivalent to using the javascript: pseudo-protocol every time you want a link to trigger an action. It’s far better to just use a normal link and intercept the default action. The best way to build an Ajax website is to simply build a normal website. Then Hijax it.

Hijax

If the success of Ajax has shown one thing, it’s that having a short, snappy name for something helps sell an idea. Just as it’s easier to say Ajax instead of “XMLHttpRequest with DOM Scripting, CSS, and (X)HTML,” it’s simpler for me to say Hijax instead of “progressive enhancement using Ajax.”

Ajax relies on the server for its power. A server-side programming language carries out most of the real work. The XMLHttpRequest object acts as a gateway between the browser and the server, transferring requests and responses. If that gateway is removed, it should still be possible to send requests and receive responses. It will just take longer.

Think back to the example of a login form. The simplest way to build this is to use the time-honored approach of having a form submit the entire page to the server, which then transmits a new page containing feedback. All the processing is done on the server, where the values that have been entered in the form are compared to values stored in a database in an attempt to find a match.

In order to apply the Ajax methodology to the login process, the submission of the form needs to be intercepted (hijacked) and passed to the XMLHttpRequest object instead. The submission of a form triggers a submit event. If this event is captured using the onsubmit event handler, the default action—submitting the whole page—can be cancelled and replaced with a new action: sending the data to the server via XMLHttpRequest. Once the login form has been Hijaxed, the login process becomes more convenient for the user. Response times are decreased, and lengthy page refreshes are eliminated. Crucially, however, if JavaScript is unavailable to the user, the application will still work. It will take longer and the experience won’t be as seamless, but because the login processing is done on the server, there is no reason to turn the user away.

The fact that Ajax applications rely so heavily on server-side, rather than client-side processing means that they can degrade gracefully. Admittedly, some applications will seem painfully slow when they rely on page refreshes, rather than Ajax, every time the user initiates an action. But a slower degraded experience is still better than no experience at all.

The future of Ajax

I’m certain that we will see an increase in the use of Ajax. Personally, I would like to see Ajax used in the same way that any other kind of DOM Scripting should be used: as an enhancement to, rather than a requirement of, the user experience. I would like to see the idea of Hijaxing applied to page elements like feedback forms and shopping carts. To me, the Hijax technique seems like the simplest way to apply Ajax. Unfortunately, the majority of high-profile Ajax applications haven’t been built that way. Gmail and Google Maps were both built with Ajax tightly integrated from the start. This makes it a lot harder to provide a non-Ajax version.

If Google Maps had been built like any other mapping website, the Ajax enhancements could have been applied on top. As it is, it will involve a lot of work to provide a “separate but equal” non-Ajax version.

Google Suggest, on the other hand, is a good example of progressive enhancement in action. The core functionality is the ability to search the Web for a term. With JavaScript enabled, that process is enhanced by suggesting possible search terms using Ajax. If JavaScript is disabled, the core functionality remains.

There is no doubt that Ajax is a wonderful technology, but I hope it won’t be abused in such a way as to shut out browsers that don’t meet the minimum entry requirements. Instead, I hope that it will be used like CSS, as a way of enhancing the user experience without sacrificing access to content.

Applications on the Web

Gmail is an example of a web application. More and more tasks that have traditionally been performed by desktop software are migrating to the Web: reading and writing emails, managing projects, and storing photos, to name just a few. Web design is beginning to resemble software development.

As more and more applications move to the Web, the role of the operating system may become increasingly irrelevant. It could be that in the near future, all you’ll need to accomplish your daily tasks is an Internet connection and a standards-compliant web browser.

Your home computer could be a dumb terminal connected to a network of smart servers. Building applications on the Web appears to be fraught with difficulties. Software developers bemoan the lack of control over forms and other interface elements. It’s true that, compared with the richness of desktop user interfaces, the browser can seem primitive. But importantly, the browser is just good enough to warrant using it as an interface. There are benefits to having a centralized application on a web server rather than many copies of an application sitting on desktops. Changes and improvements can be carried out instantaneously with immediate effect. If using a browser, rather than a richer Graphical User Interface, is the price to pay, it seems worth it. Alternatively, the browser may become just one of many possible tools for interacting with web applications. Apple’s Tiger operating system includes an application called Dashboard. Dashboard contains a collection of widgets, many of which interact with web applications.

These widgets use all the familiar web technologies: CSS, XHTML, and DOM Scripting, with a few desktop enhancements thrown in. Dashboard is effectively offering an alternative to using a browser. Other alternatives may be forthcoming. Mozilla’s XUL and Microsoft’s XAML technologies both promise the means to build rich user interfaces that can interact with web applications. Nobody seems quite sure whether this means we will see lots of desktop applications on the Web or lots of web applications on the desktop.

Personally, I love the idea of the Web as an application platform. However, there is a danger in comparing web applications to desktop applications. Whereas the Web is open to any and all user agents, desktop applications are tied to a specific operating system. When creating web applications with technologies like DOM Scripting and Ajax, it’s very tempting to demand a similar lock-in.

The simplest solution often seems to be to demand a minimum technology requirement, such as a DOM-compliant browser, or worse yet, to limit applications to specific browsers. While this may seem like the easiest way to build web applications, I believe that this approach should be resisted at all costs.