Almost every movie has a scene in which a character pull the protagonist aside and says, “There’s something you should know about [insert another character's name here].” Most of the time, we find out some dark secret about a supposed friend of the protagonist or that the main ally is actually an evil overlord. This is that moment, and I am here to tell you a few things about our friend in the Web 2.0 world: AJAX.

We seem to have AJAX licked. The Web technology is ubiquitous, and libraries and frameworks make it dead easy for us to create highly interactive Web applications and to spice up our static pages and blogs.

In a browser, if we clicked on the link labelled “Let there be AJAX magic,” the content of the HTML documentajaxcontent.html would be loaded and written into the element with the ID target. You can try this very simple AJAX example here. It’s simple and easy to use, but what’s really happening there? What is AJAX?

What Is AJAX?

After the main HTML document has loaded, AJAX loads content from the server and replaces parts of the document with that content rather than reload the main document. It’s as simple as that. AJAX stands for “Asynchronous JavaScript and XML” and was meant to load only XML documents, but we soon used it to load everything under the sun, and so the XML part was quickly forgotten. The asynchronous part is the killer feature; but what is it?

Let’s start by analysing how a normal Web interaction works:

• The user enters a URI (like http://wait-till-i.com/index.php) into a user agent (usually a browser).
• The browser turns this URI into an IP and requests the file located at the URI specified endpoint.
• The browser loads the file and, if it recognizes the document type, tries to display it.
• If the document is in HTML, we get an interface that we can interact with; for example, by clicking a link or entering data into a form and submitting it.
• In both cases, the whole document is replaced and the sequence restarts.

This has worked since the beginning of the Web and has become expected behaviour for Web surfers. With AJAX, we disrupt this sequence of events. Instead of reloading the document or loading a new one, we replace only a part of the interface, either when the user requests it or automatically every few seconds to display new information.

The benefits of AJAX are pretty clear:

• We maintain a consistent interface, rather than discard it only to bring it up again with a few slight changes after a long and annoying loading process.
• We request only the data that we need, when we need it, saving us a lot of server traffic.
• We are able to offer data without wrapping HTML around it to make it an interface.
• We allow for simultaneous interaction; a user would be able, for example, to fill out a form while an attachment uploads in the background.

However, with great power comes great responsibility, and with AJAX we have taken it upon ourselves to simulate browser behaviour for end users.

AJAX Design Challenges

In dealing with AJAX as designers, we have to reconsider the ways in which we define interfaces. Rather than concentrate on the look and feel of the page and subsequent pages, we need to drill down to an atomic level. Each part of an AJAX interaction needs to be defined. Also, think about non-JavaScript versions of widgets.

With AJAX interfaces, we move into a world of applications that have states and views and out of a world in which our document or page model was based on ideas carried over from print. This for me is a good thing. The Web is a rich medium, not a sequence of linked designs.

AJAX And Usability

As mentioned, we use AJAX to disrupt the normal browsing behaviour of our users. This can be a good thing: no one claims that browsers do everything right, but understanding just how many things we should take care of when taking over the browser is important.

What Browsers Do That You Need to Simulate

We sometimes forget just how many things the browser does for us:

• When we click a link, an indicator alerts us to a loading process (whether an animated icon, progress bar, etc.).
• For large files, the progress bar gives us an idea of how far we’ve reached in the loading process.
• If we get tired of waiting, we can hit the “Stop” button or try again by reloading the page.
• If a page cannot be found, we are shown an error page.
• If a page takes too long to load, we are shown an error page.
• Other errors we encounter (for example, a page that needs authentication, or a document that has been moved) are also displayed on a special page.
• We can right-click a link to open it in a new tab or window, instead of replacing the current document.
• We can bookmark a page and come back to it at any time in the future.
• When we need to undo something that’s gone wrong, a “Back” button takes us back one step in our journey.

All of this needs to be accounted for in a full-fledged AJAX application, because AJAX should improve the end user’s experience rather than make it harder. Let’s now enhance our AJAX script until we can say that we’ve covered the basics.

Bookmarking and the Back Button

One thing I won’t go into in detail is the “Back” button and bookmarking functionality. To make this work, you need to update the URI of the current page with a fragment and reload a hidden frame in the page. There are all kinds of annoying differences between browsers, too, and you can use something like the history plug-in for jQuery to get this to work.

Alerting the User That Something Is Loading

Probably the first thing to fix is to tell the user that something is loading when they click a link or push a button. If the page shows no apparent change, the user will think something is wrong and keep clicking. This is an unfortunate human reflex, because the more you tell a computer to do something, the slower and more confused it gets.

A simple way to provide the user with feedback is to show a loading message. To do this in jQuery, we need to get away from the load() method and instead use ajax(), which gives us information about what happens to the request, such as:

• The beforeSend event that is fired before the AJAX request is initiated, and
• The success event that is fired when the AJAX request is successful.

Error Handling

As you may have guessed, the next logical step is to handle error cases. This is something far too many AJAX solutions haven’t gotten right, and seeing a great application become useless just because one call has timed out is very frustrating.

We have to prepare for three different errors:

• The user tries to load an external file that is not available because of AJAX security settings;
• There is some server error (for example, “Page not found”)
• The resource takes too long to load.

The changes are:

• We test whether the link URI starts with http and then report an error that loading it with AJAX is not possible.
• If the link doesn’t begin with http, we start a new AJAX request. This one has a few new features:
• We define a timeout of 5 seconds (i.e. 5000 milliseconds);
• We add an error handler.
• The error handler either sends us what happened on the server as req.statustext or gives us the error message timeout when the 5 seconds are up. So, we need to check what we got before we write out the error message.

Highlighting Changes

We’re almost done enhancing the usability of our AJAX solution. One last touch is to make it very obvious that something on the page has changed. The standard way of doing this is called the yellow fade and was introduced in 2004 by 37signals in its Basecamp application.

With this technique, you change the background colour of the element to yellow and then fade it smoothly back to white. This grabs the user’s attention without overloading them (unlike zooming in on the content in or popping it up, PowerPoint style, which would overwhelm), and it is pretty easy to implement.

AJAX And Accessibility

Accessibility does not mean much more than hard-core usability. If the “average” user is confused by an interface that doesn’t work as they expect, imagine the predicament of users who cannot see the interface at all. Or think someone who has trouble noticing changes from one page to the next and all of a sudden has to deal with small changes on individual pages—changes they are not notified about. Imagine a keyboard user tabbing through a document to activate a link and out of the blue being confronted by 10 more links. There are a lot more cases such as these, and your interface should be able to handle them at least at a very basic level.

Much Ado About Screen Readers

If you research the topic of AJAX and accessibility, you will come across a lot of tutorials that deal with the problem of screen readers. I won’t go into details—this could be its own article—but here are the main points:

• Screen readers are tools that read out to visually impaired users what is on the screen (or in the HTML and hidden by CSS).
• Screen readers work on top of the normal browser and enhance its functionality. Specifically, they allow for quicker keyboard navigation (for example, jumping from headline to headline with a shortcut).
• They take a copy of a document after it has loaded and apply changes to it.
• This means that screen readers understand JavaScript, but they only execute a request when the page has loaded. If you change a document with JavaScript and AJAX after it has loaded, you need to notify the screen reader somehow that something has changed and refresh the copy of the page. This can be done by refreshing a form field as a hack.

The real problem with screen readers, and any assistive technology, is that they add yet another level of complexity to our Web interaction.

We have HTML interfaces such as links and forms that need to work with all kinds of input devices: keyboard, mouse, voice recognition software, to name a few. Then the browser needs to somehow tell the assistive software (whether a screen reader or software that zooms the screen or a voice recognition tool) that something has changed, and that other tool has to translate it into an understandable format. All of this can, and frequently does, fail.

Much like how HTML 5 is being pushed to replace HTML 4 because the latter is not rich enough to support the interfaces we want to build, WAI-ARIA is a standard that works around the problem of assistive technology and browsers not talking to each other.

With WAI-ARIA, you can tell a screen reader, for example, that a particular element on the page changes frequently and will be refreshed with AJAX. Again, this topic is too big to cover here, but some good articles are out there in case you are interested.

Important Feature #1: Keyboard Access

One very important requirement of accessibility and AJAX is providing keyboard access, and doing this in a very basic way is not hard. The element that triggers the AJAX call has to be something that users can access with the keyboard (i.e. either a link or a button). You can test this yourself: simply use the Tab key to jump from one keyboard-accessible element to the next in your document. Can you access all of the functionality, and is it obvious where you are at any given moment?

This is where you as a designer can do a lot to make your AJAX interface more accessible.

Important Feature #2: De-Clutter Your Interface

With a library such as jQuery, you can make anything on the page interactive and make it initiate AJAX requests. You could use roll-overs or drag-and-drop interfaces, and these are great to look at, but ask yourself: are they really intuitive? Browsers do not yet have any drag-and-drop functionality or even roll-overs. Roll over your menu bar; you have to click to initiate any action.

But by using JavaScript tricks, you can make any element keyboard accessible. And if you build widgets, go even further by following the rules of keyboard navigation. You could even create a screen reader-compatible drag-and-drop interface. But again, ask yourself a few questions:

• Is it worth the hassle?
• Does it really make the interface easier to understand?
• Does it make it more natural to use?
• Does it help all users reach their goal faster, or have you implemented the feature just because it looks cool?

Making the interface as simple as possible does not mean neutering your creativity. On the contrary, the easiest and simplest interfaces are the ones that have gone through a lot of research and design iterations. Great usability means not recognizing that something has been done to make the interface easy.

What Not To Use AJAX For

Never rely on AJAX to handle sensitive information, because modern debugging tools allow anyone to see what is happening on the page. By analysing these requests, I could glean information that you wouldn’t want to show the world; for example, the endpoints of the services on your system (such as mail scripts), which I could exploit for my own purposes.

Nothing in your JavaScript or HTML is secure. I can change it on the fly and work around your protection mechanisms. If you are not building a Web application but are merely offering articles for people to read or a catalogue to flip through, you probably shouldn’t go the AJAX route anyway.

The other thing to consider is a search engine. If you load all of your content with AJAX, you aren’t offering much in your documents for search engines to index. Static HTML content is still best for search engine indexing, as well as performance, because pages can be packed and cached nicely on your server, if you do it right. Loading via AJAX brings up the content much faster for users and saves on bandwidth, but you will see less traffic from search engines. Something to consider.

The External Content Problem

One built-in security setting of AJAX is that you cannot load content on another server. This is critical, otherwise people would be able to call and inject whatever script they please from the Web. Definitely a bad idea.

You may sometimes need, though, to retrieve third-party content; i.e. load external content in your document as data (because you can always use iFrames to embed other documents). This is where we have to get clever with the technologies at our disposal.

The most common workaround for AJAX not being able to load something like http://icant.co.uk/index.php is to write a server-side script that loads the page and then prints it out. This is called a proxy.

Of utmost importance when using a proxy is to white list the URLs that you want to load. Do not simply load any URL off the Web, or else attackers would be able to read files from your server and use your server to send out spam and attack other servers, making it look as though you were the perpetrator.

Other ways to retrieve external content is by getting data in a special format called JSON-P or by using a hosted proxy service such as YQL. I’ll keep this brief because there are several solutions to this problem. If you are interested in learning more, check out this blog post on the subject.

What To Use AJAX For

When used wisely, AJAX makes our life on the Web easier. If you’re wondering when and how to use it, check out these use cases:

• Adding a large attachment to a message - Nothing is more annoying than waiting for your browser to upload something without having a clue how fast and how far along it is. Browser progress bars give us a hint but no real numbers. The Yahoo User Interface uploader, as well as jQuery implementations such as Uploadify, show how that would look like in the browser.
• Handling a lot of small data sets - A great example of this is the comments section in WordPress. Rather than having to click a lot of checkboxes or reload the page every time I want to delete or approve comments, all I do is click a few links.
• Rating content - No need to reload the entire page if you just want a simple Yay or Nay from the user in response to a question.
• Displaying constantly changing content - For example, financial tickers or instant updates from Twitter and Facebook.

I hope you’ve gained a few more insights into what AJAX is and how you can use it to improve the user experience in a way that is safe and doesn’t leave certain segments of users out in the cold. AJAX makes stuff smoother, but nothing is more annoying than a supposed enhancement spoiling the whole experience.

---

Thank you to the guys at Smashing Magazine for providing this information