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.

  <p>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.</p>
  <p>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 <a href="http://en.wikipedia.org/wiki/Representational_State_Transfer" title="Representational State Transfer">REST</a>. 
    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.</p>
  <p>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 <a href="http://naeblis.cx/rtomayko/2004/12/12/rest-to-my-wife" title="The best blog post ever?">How I explained REST to my wife</a>.</p>
  <p>And with AJAX, these misunderstandings can bubble up to the higher level, 
    where they affect the actual interface users interact with. In <a href="http://www.lastcraft.com/blog/index.php?p=19" title="Lastcraft salience">Listen 
    kids, AJAX is not cool</a>, Marcus Baker cuts through some of the recent 
    slack and hyperbole:</p>

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.

  <p>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.</p>
  <p>Anyone interested in building AJAX applications should first learn how 
    to use the <a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm" title="Fielding Dissertation">REST architecture</a> 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.</p>
  <p>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 <a href="http://en.wikipedia.org/wiki/CRUD" title="Create - Retrieve - Update - Delete">CRUD</a> 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 <span class="code">assertMetaphorIsCoherent()</span> 
    or <span class="code">assertNoUnwantedShortTermMemory()</span> except 
    to throw a prototype in front of an audience and watch and listen to their 
    reactions.</p>
  <p>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.</p>
  <p>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.</p>