Perils of Ajax

Ajax has provided developers the ability to transform the way mortals use the Web from simply reading contents to interacting with websites. There is an explosion of applications on the web that, before, were available only for desktop environments. While many factors contributed to it like increasing bandwidth, faster chips, mature tools, and better understanding on how people use the web, Ajax made websites more alive and pleasant to use. But, Ajax can also do the reverse. And since Ajax is a new thing to many developers (though the underlying technology has been around for years), it can be used in ways that break the conventions that made the Web easy to use in the first place.

Imagine your looking for videos of Paris Hilton and Nicole Richie. As always, you use Google. You click on the 1st item in the search results. The link takes you to a page with tons of links that are trying to get your attention. Every link in the page is transmitting a telepathic signal that says “Click me and I will be yours”. Your undecided for a while but eventually, you choose one and 2048 milliseconds later you see another page with a bunch of links that says “Click me”. Hoping you’ll find the videos of Paris and Nicole, you click another link, another page, another link, and so on until you the page now asks for your credit card. Damn! Anyway, you simply click the Back button again and again until you’re back to where you started.

Going back is possible because the browser remembers the location of the pages you recently visited. Every time you click a link, the browser loads the page and the history gets updated. That’s the convention since the Web’s inception. But Ajax loves breaking conventions. When you click a link and the page is loaded using Ajax, the history is untouched. So when it’s time to go back, clicking the ‘Back Button’ will not show the previous page. Instead, with our example, what you will see are the search results from Google.

To get around the back button dilemma, one proposal is to just remove the back button. Hmmn. For an experiment, hide the navigation buttons in your browser and then track how long you can browse the web without the back button. I know that’s a silly proposal. Trash it.

Dojo, an Ajax framework, provides a way to preserve the back button behavior. But thinking beyond the technical solution, what if breaking the behavior can be avoided in the first place. If the updates result in a page that looks so much different from the previous, then users would believe they are on a different page already. In that case, you need to rethink your Ajax solution. If you use Ajax to update small and discrete areas of the page, there is a less chance of problem arising from the back button. Of course, when in doubt, you can always do user testing to find out what works better. Actually, you should always do user testing.

The back button is a symbol of freedom. It assures us that wherever our desire takes us, we can always count on it to take us back to where we’ve been before. It’s like going deep in a forest without the need to leave breadcrumbs because retracing our steps is as simple as clicking the back button.

Did I say Ajax loves breaking conventions?

Not too long ago, you can always bookmark a page and return to it the next day. Well, you can still do that today for sites that have not yet been ajaxified (is that a word?). For ajaxified sites, bookmarking is a problem. The problem happens because when you bookmark a page, what is saved is the URL at the address bar. When you click a link and the page is loaded using Ajax, the address doesn’t change — a similar problem with the back button where the history is never updated.

To be fair, the bookmarking woes is not exclusive to Ajax. Frames suffer the same problem. Whatever link you follow and no matter how deep you are inside a frame, the address does not change. Come to think of it, you can update the contents of frame without affecting other frames. So it does have some Ajax-like behavior and problem.

There are cases where leaving the address as is makes sense. You should be able to bookmark your search results in Amazon but you shouldn’t bookmark a page halfway through a checkout process. The challenge then for developers is not how to bookmark every thing but when to treat an operation as bookmarkable and when it is not.

Feedback has always been a usability challenge even before Ajax arrived. Pre-Ajax, at least we have the status bar and the spinning logo to remind us that an action is under way (assuming you noticed it). In some ways, when you click a link and it shows a blank page, you got a feedback because the browser has changed and you can no longer do anything until the browser is done. This is the synchronous world of pre-Ajax web. But the ‘A’ in Ajax means asynchronous and it causes your browser to behave differently. With an Ajax request, the browser does not give automatic feedback. You need to write code that tells the user an action is underway or it is done. The asynchronous way also means the user can continue interacting with the page while the Ajax request is being processed. Unlike before where the user has to wait for the current request to finish before he can proceed to the next, now your user may have clicked a dozen links or pressed several buttons already by the time the 1st request is finished. If you’re lucky, the results of these actions are mutually exclusive but if these change some state in your application (e.g. a delete operation), then you may run into problems.

Just because you can sprinkle every Ajax-technique imaginable in your website does it mean that you should. I have a friend who got so excited with inline editing he implemented it in almost every piece of information in his project. For a while it was fun but as the development goes on, the code has become unmanageable and he eventually dropped inline editing. Good thing he realized it before his end users use it.

Every time you’re thinking of using Ajax, ask yourself:

  • Will this improve my application or just lengthen my resume?
  • Will it help the users accomplish their tasks faster or help me get more bragging rights?
  • Is this for the greater good?

OK, #3 is optional but it does not mean you shouldn’t strive for it.


2 thoughts on “Perils of Ajax

  1. Rails makes adding Ajax very easy. When I started learning Rails, I immediately added Ajax to my pages. This made maintaining my code harder as I was just learning Rails. You have to be careful when you use Ajax. It should serve a purpose and do not use it just because it’s cool.

    Btw, have you heard of jrails? It replaces prototype with jquery. I haven’t used jquery but it seems a lot of people like it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s