Ajax and UX

Amongst those of the user experience and information architecture persuasion, there seems to be a growing trend that involves taking interesting new technological and interactive concepts, and coming up with inaccessable and weird terms to describe them.

  <p><a href="http://atomiq.org/archives/2004/08/folksonomy_social_classification.html">Folksonomies</a> is probably the most outstanding example - this semi-ridiculous 
    and overcooked name emerges for what is just the relatively straightforward 
    concept of users tagging content with their own categories.</p> 
  <p>And now <a href="http://www.adaptivepath.com/publications/essays/archives/000385.php">Ajax 
    is here</a> - the latest moniker to describe asynchronous request scripting. 
    On the one hand, it's great that respected and widely read authors are 
    emphasising that this technology is stable and showing how useful it is 
    (it has been for 2 years, but thats beside the point) - but calling it 
    Ajax? Why? Why?</p>
  <p>JJG's initial summary of how these client side technologies come together 
    is spot on. But a closer look at the <a href="http://www.adaptivepath.com/images/publications/essays/ajax-fig1.png">diagram 
    of Ajax interaction</a> reveals several technical misconceptions regarding 
    the nature of the client interface and its interaction with data passed 
    over the network. The diagram illustrates an "all or nothing" 
    approach, where the entire infrastructure of the user interface delegates 
    to an abstract "Ajax Engine". In reality, web applications would 
    utilize a hybrid approach, combining standard HTTP requests for loading 
    structural layouts and large content pages, and using <a href="http://developer.apple.com/internet/webcontent/xmlhttpreq.html">XMLHTTPRequest</a> 
    or <a href="http://www.ashleyit.com/rs/main.htm">JSRS</a> to run smaller asynchronous interactions. In this context, the "Ajax 
    Engine" is a mismatched metaphor, since it confuses higher level 
    abstraction of the flow control process with direct technical assertions 
    ("Javascript call", "HTML/CSS data"). A side effect 
    is the implication that the major architectural patterns and techniques 
    in this context have been resolved - that a standard approach exists. 
    I think most web developers would agree, we're a long way from this being 
    a reality, even in terms of the basics such as the format of data passed 
    between server and client. The Ajax acronym fundamentally bases this approach 
    to data transfer on XML, yet some of the most interesting recent developments 
    in this area are based on passing packets of Javascript itself (see: <a href="http://www.crockford.com/JSON/index.html">JSON</a>
    and <a href="http://jpspan.sourceforge.net/wiki/doku.php">JPSpan</a>).</p>
  <p>I would suggest a more useful way to think about the client interface 
    component of web applications is in terms of a layered separation between 
    structure (X(HT)ML), presentation (CSS), and behaviour (Javascript). Asynchronous 
    requests can be thought of as a binding between the behavior and the content/structure 
    - this behaviour layer should be considered a part of all non-trivial 
    web applications, and could extend as far as a full asynchronous request/response 
    and animated GUI architecture, or as simple as predetermined client side 
    validation rules. I don't think we need to invent a new abstraction like 
    "Ajax Engine" to describe a process that is implicit in the 
    design of <em>any</em> interface that responds to user events.</p>
  <p>Nonetheless, whatever the approach is called, there's no doubt of the major improvements that are possible from promoting a smooth user experience.</p>