Tuesday, December 6th, 2005
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.
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.
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.
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 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.
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