Tuesday, December 6th, 2005

Alertbox Spoof: “Why Ajax Sucks (Most of the Time)”

Category: Editorial, Usability

Update: Argh! I was baited big-time. This all refers to a spoof article on the aptly-named Confusability. (I had these ideas on my mind after reading a similar comments recently on confusability, which I assume is the real thing.)

Web usability pioneer Jakob Nielsen gives Ajax a big fat thumbs-down in his latest Alertbox, though is a little more optimistic than his previous “Just Say No” stance (in the sense of improving from an “F-” to an “F”). An article like this deserves an extended response …

The fundamental problem, according to Jakob, is that Ajax breaks the concept of a unique URL per page.

Ajax breaks the unified model of the Web and introduce a new way of looking at data that has not been well integrated into the other aspects of the Web. With ajax, the user’s view of information on the screen is now determined by a sequence of navigation actions rather than a single navigation action … If users create a bookmark in their browser they may not get the same view back when they follow the bookmark at a later date

Further on, he resumes the finger-pointing at Ajax’s handling of URLs:

A combination which has one of the worst usability problems to be seen on the Web so far: the BACK button in the browser simply didn’t work with ajax sites. The BACK feature is an absolutely essential safety net that gives users the confidence to navigate freely in the knowledge that they can always get back to firm ground.

If this is *the* fundamental problem, then the future is bright for Ajax.

For starters, an Ajax app *can* make full page refreshes. There’s no law that says “Ajax apps must only change page content with DOM manipulation, and all server communication must be via XMLHttpRequest”. Between page refreshes, states usually aren’t important enough to warrant a unique URL anyway.

To take the argument to the absurd extreme, have you ever lamented the fact that bookmarks don’t capture the position of the mouse cursor? No. But isn’t the mouse cursor part of the application state? What if you go back to the previous page? Shouldn’t the mouse cursor be at the same place you left it? No, because the state isn’t significant enough to save. How about the state of a partially filled-in form? The URL doesn’t capture that either. So even without Ajax – or any dynamic behaviour – there’s information loss with just the URL. Users *do* expect insignificant state to be lost when they go back or re-visit a site via its bookmark.

When a unique URL is *required*, that’s when an Ajax app can indeed perform a full page refresh. In the few seconds or minutes between full refreshes, the work that’s done is usually not significant enough to save anyway. A9 uses lots of Ajax, for instance, but still has a unique URL for each search result, which is the thing you want to bookmark.

But what about sites that go the “pure Ajax” route: 100% XMLHttpRequest and no stinkin’ page refresh. Even then, there are indeed techniques – and even reusable libraries for Unique URLs. Some things aren’t (yet) pretty from a programmer’s perspective, but there’s no great loss to usability here.

Jakob goes on to look at implementation problems.

Ajax-Challenged Browsers
According to a study Jakob mentions, 78% of people are using Ajax-compatible browsers.

Thus, 13% of users (I think Jakob mean 22% here? –MM) would not even be able to use a site with ajax. Sure, it is possible in principle to use graceful degradation to serve alternate content to these users, but most designers don’t bother designing two versions of their pages and reserve the no script option for a “helpful” link to the download site for an ajax-supporting browser version.

This is a good point which all Ajax developers should be taking into account, but not a showstopper. “Graceful degradation” does not have to involve two versions of a site. It can also mean a little Ajaxifying here and there, with the appropriate browser feature checks. Ajax also applies to the many web apps running on intranets, where 100% compatibility is often the case.

Print Problems

Many browsers cannot print ajax pages appropriately. Of course, most browsers don’t print anything really well, but at least regular pages normally print in full. With ajax, it is common to have the print command result in the printing of a single column. Printing the full page is difficult with ajax layout: should only the visible part of the content be printed or should the content be allowed to expand and take up more room than it does on the screen?

Jakob perhaps has a very specific Ajax site in mind when he speaks of “ajax layout”. Is he referring again to the fact that sites might use XMLHttpRequest to avoid loading all content at once? Again, that’s something for designers to bear in mind, but no intrinsic Ajax problem.

Authoring Problems

Newsgroups like ajax.web.technology are filled with questions from Web authors who desperately need to know why their ajax doesn’t work as intended. Ajax is currently so hard to learn that many page authors write buggy code.

Well, we *are* talking about rocket science after all. (Do questions on comp.lang.java prove that Java is hard to learn?)

Search Problems

Search engines have trouble with ajax since they don’t know what page states to include as navigation units in their index.

Again, a manifestation of the URL issue. A critical concern for many developers, and certainly an issue with Ajax. But still manageable with page refreshes and other techniques.

User Preferences

Many websites that offer users a choice between regular and ajax versions have found that most users prefer ajax-free designs.

Good, some objective research will help settle the debate. Got a link?

So when is Ajax a-okay according to Jakob?

If you are working in a Web2.0 company that needs to provide evidence of their technical expertise in order to gain new clients. However, you must remember to keep your offering in beta and make sure that it in the same family as these examples:

  • geotag-based apps via flash
  • tag-based instant messaging via Ruby on Rails
  • community podcasts via api mashups

Jakob, of course, leaves out the most obvious usages of Ajax: “social long tail feeds via REST” and “structured wiki platforms via RSS”.

Design is all about trade-offs. It’s easy to pick holes in any architectural style, be it Ajax or SOAP or OO. But amid all the negativity, we also need to look at the benefits in order to make a professional, balanced, judgement. Really, the main point of Ajax is to improve usability. These *potential* downsides -at least, those that are truly valid concerns – must be balanced against the many ways in which Ajax, applied carefully (but not necessarily sparingly), can dramatically *improve* usability.

Posted by Michael Mahemoff at 5:15 am

3.2 rating from 9 votes


Comments feed

In my opinion the debate of whether AJAX is good or evil is completely going in the wrong direction. Most of the issues discussed makes no sense. AJAX, remote scripting, or whatever, is just a technology that you use to solve specific problems. As such it is a great tool to have.

AJAX is especially suited for situations when you create more application like web thingies. It mostly does not make sense to use AJAX in regular document centric web sites. Jacob Nielsen and most other sceptics does not seem to be aware that the web is used for more than document centric information nowadays…

Comment by dotvoid — December 6, 2005

Michael. Thanks for sharing your comments. Did you post a link to the Jakob Nielsen article. I searched useit.com for “AJAX” and nothing showed up.

Comment by Jesper Rønn-Jensen — December 6, 2005

The url is http://www.usabilityviews.com/ajaxsucks.html – it’s not on the main useit site yet.

Comment by Richie Hindle — December 6, 2005

Can any of you read? It’s s poof. It says so at the bottom of the page.

Comment by Lon — December 6, 2005

Lon: Gah! Some of us were having fun with that. Stay away from me on April 1st.

Comment by Richie Hindle — December 6, 2005

Damn I was already wondering what took Jakob Nielsen so long before he came with the inevitable ‘AJAX sucks’ statement…

Just like with any technologies there are examples that suck and examples that don’t. Unfortunately mr. Nielsen still lives in a world where there’s only black and white.

Comment by Marco — December 6, 2005

Hey, you’re right. It’s all a big spoof. Crow eaten, article updated.

Comment by Michael Mahemoff — December 6, 2005

I’m terribly sorry for being a spoiler.

To my defense, I must say it’s hard telling spoofs from non-spoofs on this site… They all initially look like spoofs to me… Nothing is really usable or working. Beta is far too good a qualification for the trash people are eagerly putting outside under the Ajax-label.

Let’s not forget it was a cleaning product first! Let’s do some cleaning up!!!

Comment by Lon — December 6, 2005

Thanks for being such good sports.

I’m sure Jakob will write the real version soon.

Comment by Chris McEvoy — December 6, 2005

Chrisy, you’ve made yourself more famous than you were before.

Congrats. :)

Comment by tsal — December 7, 2005

I just found this. It’s hilarious! Not only that a big response to a spoof was written, but that the Ajax is so point-by-point analagous to frames that an intelligent person was taken in. This is not to tease. This is to point out how spot-on Michael actually is. I know this article is old now, but I wonder what Jakob’s position on Ajax actually is.

Comment by Mike Levin — July 11, 2006

Leave a comment

You must be logged in to post a comment.