What's with all this AJaX jazz? I'm not going to deny that a lot of the current surge in articles has much to do with Google-envy and on technologists bent on the beauty of their weapons more than anything demonstrably practical, but what strikes and amuses me most in these erupting discussions is the stark duality. It's tacit and assumed, black vs white, is it or is it not, the Dark Side or the Good.

But is it really? As one of those who explored primative models of these method as far back as Y2K, I'll chime in the frey with a heretical idea:

It depends.

Whither to AJaX or not, it all depends entirely on your intentions.

Right now Ajax hangs in the balance. Reasoning from the articles and blog entries that are available today, Ajax could be either a promise or a hype. That makes me lean to the hypey side, because I feel that if something "could be a hype" it probably is.
[ QuirksBlog: Ajax, promise or hype? ]

Where there's polarity, there's typically a grain of dual-space truth, and that's where I place these dynamic interface applications. In 2000, Paul Kelly and I created a tightly bound fleet of kiosk tradeshow booth display clients, using DHTML and Javascript timer-refresh to simulate the interior workings of the OpenCola products, using iFrame and data transfer to update small elements, all in the name of giving an illusion of the eventual desktop application. Therein a clue: the medium was the message.

We were justified in the tight binding of action and content because the action was the content, or more to the point, there was no useful information beyond that interaction screen.

But sometimes the message is the message

Contrast that idea with GMail. What does AJaX add to GMail? For one thing, it raises the bar on reaching my messages. I can't use my cellphone, I can't use a text-to-voice app, I can't even use a 32MB vintage 1995 Dell with any sense of grace. Google places the beauty of their weapons above the undeniable purpose of GMail, which is supposed to be to connect me with my messages.

Ironic, that. Considering the pristine simplicity we associate with Google.

But there is a redeeming feature to the GMail interface that is also instructive: I'd rather manage my vat of emails through AJaX than through any of the incarnations of HotMail or Yahoo. Sifting spams, finding things, re-arranging things, it's a beaut.

To add another celebrity AJaX posterchild, FlickR also excels when I want to move my photos around, upload, tag, group, annotate and classify them, but all that editorial work is a minority task compared to actually using my photographs, and for me, that's where FlickR falls flat. Isn't the purpose of publishing is to be published? Not to be publishing. In FlickR we're assumed ever the bridesmaid, never the bride -- I have a blog, I want to place a photo in my blog and mail it to a friend. FlickR is silent on both counts, it's fancy flash often actively thwarting my attempts to share my pictures. It's wonderful if all I want to do is fiddle endlessly with the fine details, but it doesn't help in the majority use-case consumate act of the actual sharing.

I still use it, though, because it's such damn slick fun compared to the alternatives. But fess up, don't you occasionally curse all the 'jax'n'flash when it comes time to plunk that photo-stream item into a forum post or fetch it to your phone?

It depends on your intention

In human computer interaction, we often find that one controller works well for one class of tasks, another for another. As my friend Doc Higgins would say, "It's all good." The problem for us as real-world interaction designers undazzled by the gloss, is to derive a useful taxonomy, to identify the problem classifications and how they map to the solution classifications and thereby have some predictive ability in saying whether this or that interface fits that or this problem.

What I think we've discovered so far about AJaX is that it works well for data manipulation tasks but fails terribly as an information delivery strategy

Only here again, I'm going to qualify my answer with a strategic "It depends ..."

The Rise of the Webservices

I'm a little disappointed at how webservices are turning out. For example, there aren't any. Ok, maybe a few, but what I really want from webservices is that Small Tools scenario where there are simple RESTful interfaces that I can hook and chain and sequence together to build really large distributed solutions. I think a large part of the trouble is this absurd monopoly-carrier situation we have where all Internet (and wireless) pipelines are metered by the bit -- nobody wants to be a server out of fear of becoming popular (and thereby broke) and nobody wants to be a client out of fear that the essential piece of your process puzzle is going to vanish (or change the API) unsurrepticiously some Monday boardroom of investors 9am, just when you need it the most.

Returning to AJaX, it strikes me now that a third problem-solution scenario arises where we have one gateway interface bound to multiple distributed webservice-provided processes. The whole fleet must work together as a whole to present the information. A topological map overlay with weather overlay with emergency services reports, that sort of thing. AJaX becomes the first candidate for cutting the UI development costs (ever try UI in C++ or Java? ever try it twice??) but maybe can still suit the Read-Anywhere criterion for the Information Delivery Applications by subsequently printing a static and ubiquitously accessible snapshot.

Snapshot AJaX. Darn. Now we're gonna need another buzzphrase ...

My Evil Plan takes root

Now that I have your attention, let's revisit what I said about my dream computing scenario, the Last Computer You'll Ever Buy because it's just another node in a grid that spills out your door into the next-door and beyond, extending into the invisible in a world of Living With Webservices omni-symbiosis.

You see, here's where I see the hidden silver lining with AJaX, the right-angle precessional progress effect like the snake that weaves side to side to go forward, the glossy star-eyed Devotees of the Interactive really really want a sexier thing than Google or FlickR or whoever, and to do that they must refactor their (currently) monolithic webpage mindset into Small Tools thinking. To make the tag box slick and interactive, they've opened up a simple RESTful webservice that only says, "photo(id).attach( tag )" -- who's now to say I couldn't decide that I don't want to cruise into FlickR, I want to feed my tags directly from my cellphone at the moment I take the shot, or use a clever robotic-vision object-recognition system or garner the consensus of a thousand unknown friends to do my folkseconomics?

To make AJaX work, these are exactly the sort of services that must open up, whether or not the vendors are brave enough to advertise the API to use them (and grant the security rights) they are, nonetheless, latent in the design, maybe unused and disallowed today, but tomorrow is, as usual, anyone's game.

the ironic postscript

and it's a good one: while AJaX subverts the MVC design style and binds information to the apparatus, while it undoes the progress we'd made in divesting document contents from the chains of their file-format and the flexibility in use that comes from seperating content and method, AJaX is doing precisely that sort of dependence-liberation to the components of the apparatus!. The new paradigm is, as usual, not cut and dried this or that black or white, but Mv-Vc-Cv-Cm fragmented collections of dual-space information/process components, each readied and able to interrelate with others in new and unexpected ways. Come back another day of omni-everykind device space, we may find the AJaX has been tossed out the window and in it's place a ready-made infrastructure of a billion small tools!