Asynchronous Representational State Transfer

AJAX is not new(s). Previously, I've been critical of the nomenclature, perhaps more for aesthetic reasons than anything else, but I have to agree with Simon Willison, who pointed out the most important thing is that AJAX is a way to promote intelligent conversation. From what I've noticed, this conversation has actually been happening, and that's a good thing.

The original appearance of Gmail in 2004 made many web designers think long and hard over what they were doing with user interfaces. Of course, this is what Flash developers have been doing all along (and not without major criticism), but it took several years for HTML developers to finally discover the XmlHttpRequest object hidden inside those browsers. The AJAX conversation distills this knowledge and praxis in a simple to grasp meme, not just assigning a handle, but actually giving shape to what was previously a fuzzy set of ideas. While I still dislike the term, I've grown so used to it, and learned so much from it that I see no point in grumbling.

So it's interesting to notice the growing Ajaxian disquiet for what we might term "naive" usaage of XmlHttpRequest, mostly to do with the widespread lack of appreciation for the fact that requests are being made over an often unstable and patchy network. To me, this suggests that the missing link for AJAX designers to understand is REST. This subtle and slightly subversive architectural approach is what HTTP has been about all along, and it continues to quietly achieve the goals that committee after committee forever try to standardize with XML.

The recent problems with Google's web accelerator and content modification have been alarming to many people, and I wonder if more than anything, this highlights a major industry-wide misunderstanding of the basic principles of HTTP. It's a real shame, best summed up by Ryan Tomayko in How I explained REST to my wife.

And with AJAX, these misunderstandings can bubble up to the higher level, where they affect the actual interface users interact with. In Listen kids, AJAX is not cool, Marcus Baker cuts through some of the recent slack and hyperbole:

Even when the process is improved, there is no guarantee that we have enhanced the user experience. Entering a form is a familiar operation. We can do it whilst answering the phone or explaining something to the kids. The extra time fetching a separate error page may be time that I am putting to other uses anyway. Perhaps I just needed a rest. An interface that jars me out of my familiar path is probably not helping me at all. I don't know this of course, because I haven't measured it. But if you design such an interface, you don't know either. You need to measure it, and this kind of usability is a lot more work than watching people click on pages.

Server-roundtrips shouldn't really need to be integrated into "live" form validation because in modern DOM browsers, this approach to editing content doesn't need the concept of a form itself. Click on an H1 heading, edit the text, save it, the page updates immediately. This leads to a new kind of "sticky" interface. The major challenge for designers is thus to figure out how to visually communicate this potential to users who are used to the less-than 1/10 second response of software like Word or Outlook.

That definitely doesn't mean that AJAX based interfaces should encourage users to fire off tens of micro-requests by clicking round about a document, to thus end up getting slammed by a slow connection that throws the whole UI out of sync. This is an area where more collaboration between developers and designers is desparately needed. It's one thing to understand techniques for dealing with network latency problems, quite another to communicate to users what effect their typing and clicking actions are having on a persistant data store. My point is just that neither of these aspects can be understood in isolation.

Anyone interested in building AJAX applications should first learn how to use the REST architecture to it's fullest potential. In most cases it's worth considering whether asynchronous updating is actually necessary at all. Sometimes, a form is just a form - and no user is going to appreciate an overcomplication of that, no matter how "rich" the experience is.

But not every web application has the same goals, and these goals can not always be solved by forms. That means finding user friendly metaphors for editing persistant content that are simple and direct, use HTTP requests sensibly, yet don't necessarily require a CRUD based form model. I'm sure there is a middle ground somewhere. Which brings me to my next point. Usability testing is hard, but surely must be the most important aspect of AJAX application development? Theres no way you can rationally assertMetaphorIsCoherent() or assertNoUnwantedShortTermMemory() except to throw a prototype in front of an audience and watch and listen to their reactions.

The page based model has been successful, but only because there was never an alternative. Now the technology has stabilized, to make many such alternatives possible, the only way forward is exploration and experimentation that is validated by testing. In simpler terms, the way forward is just testing, full-stop. There will be no le Corbusier like-figure who revolutionizes the design of the modern WWW - this growth is far better understood as evolution, driven by the demands and intuitive responses of the audience using these emerging products and tools.

So maybe the concept of ARREST will never catch on like AJAX has - but I do find thinking about the problems in basic HTTP terms leads to greater clarity than anything to do with XML.