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.

Folksonomies 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.

And now Ajax is here - 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?

JJG's initial summary of how these client side technologies come together is spot on. But a closer look at the diagram of Ajax interaction 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 XMLHTTPRequest or JSRS 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: JSON and JPSpan).

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 any interface that responds to user events.

Nonetheless, whatever the approach is called, there's no doubt of the major improvements that are possible from promoting a smooth user experience.