This one snuck up out of nowhere. There we web developers were, minding our own business, happily coding away on our web applications, occasionally using a bit of what we used to call 'DHTML' to liven up the UI, which occasionally involved using little bits of JavaScript jiggery pokery to sneak additional bits of data down from the server without refreshing the browser page - IFrames, background HTTP requests, web service calls, whatever. And we would happily apply this sprinkling of user interface enhancement across our websites whenever the requirements demanded it (but with care, because such things were notoriously hard to test across browsers and apt to blow up in your face whenever Microsoft releases a service pack and removes several useful bits of functionality that you called 'features', but that they call 'security holes').
Then recently, some people noticed that Google had started using these out-of-band HTTP requests a lot in their web UIs. And that now Firefox and Opera and IE were all gradually aligning to the same sort of standards agenda, there were some pretty good ways to introduce these kinds of effects in a chilled-out, eco-friendly, cross-browser, standards-compliant, compatible way. And they gave it a name: AJAX - Asynchronous JavaScript And XML. And it's been shouted from the rooftops that this is the platform for all future web applications. If you don't got AJAX, you don't got nothin'. We've even had customers forward us URLs of blog posts saying "Isn't it about time you started using this AJAX stuff? It's the next big thing, according to this random blogger!". And in the face of this there's little to do but nod, smile, and say yes, actually half of your existing UI is implemented using what these people call 'AJAX techniques', but which we simply put in under the guise of 'neat hacks to get around the annoying need to refresh the whole page'.
Now, those of us who've been playing with browser-based JavaScript for a while, and those of us who've used XML and web services for any length of time, and those of us who actually understand that HTTP lets you do a lot more than just sent GET requests by typing URLs into the address bar and clicking on hyperlinks, tend to think 'big deal, so what, AJAX is nothing new, we've been doing this for ages, go away and take your bandwagon with you'. But we'd be wrong to do that. There's a lot of power in giving something a name, and AJAX is a very good name. A name gives you something to hang onto. It gives people something to put in the titles of books. It gives people something to write on their CVs (or resumes, if they must). It gives something legitimacy. And that's going to help the user interface of the web move on.
The truth is, bog standard web sites make rotten applications. The web imposes a tedious linearity on user interaction. Present the user with a series of questions they need to answer. Click next to continue. Do server-side processing to figure out what to do next. Present the user with the next set of questions. Click next to continue. This is not how any sane GUI designer would choose to work with the user. Think about it: in all the years you've been using your word processor, have you ever wished it had a back button? No. Why would your online banking application actually be any different from that? Yet, because they are presented in a page-bound browser, such applications almost inevitably have such a feature.
Consider the most common web application UI pattern - the shopping basket. The user browses from page to page, finding the things they want to buy. This process - catalogue browsing - is ideally suited to the HyperText concept of navigable pages of information.
A brief aside: HyperText is, though it's easy to overlook it as a meaningless prefix, still what the 'HT' in HTML and HTTP stands for. There was a time when it was the Next Big Thing. This was, I think, about a year before multimedia and the CD ROM wave - which was the year before virtual reality took over NBT status. I find it amusing that nowadays nobody bats an eyelid over the fact that the first 'H' in the ubiquitous 'http://' actually stands for the gloriously dated marketing buzz-modifier 'hyper'. Regardless, HTML and HTTP are probably the only surviving carriers of the HyperText flame (they preserve some of its buzzwords too, like 'home' and 'hyperlink'. Ever wonder why web sites have 'home' pages?). One alternative evolution of it was Bill Atkinson's 'HyperCard' application for the Mac, which still defies description in terms of modern computer applications, and truly broke some moulds. What all HyperText and HyperMedia formats had in common was that they anticipated the idea that delivering content would be an important function of computer systems, and they introduced the idea of a computer user taking on the role of a 'browser' of content. This was probably one of the most significant UI developments ever made. But I digress.
Back to shopping baskets. The rot sets in in most sites with the 'add to basket' button. This isn't a HyperText concept - it doesn't take you to another piece of information. On most sites, you can't see this mystical basket; you're just setting some kind of invisible flag somewhere that does something intangible. We accept this as normal, but it's not the best UI decision ever made. And then things break down thoroughly when we choose to navigate to the checkout page. There, the page metaphor begins to get thoroughly messed around. We're no longer browsing content, we're performing actions. We've ceased being a browser, we've become a customer. But the web UI forces a browsing paradigm on our interactions, and it gets in the way. We enter the checkout wizard litany: enter personal details; click next; enter address details; click next; choose delivery method; click next; enter credit card details; click next; read confirmation page; click next... we're stuck doing something that could be done in a number of different orders in a strict linear sequence of pages.
It doesn't have to be like this, and AJAX (you see how much easier it is to say that than to write 'dynamic client scripting techniques that break away from the navigation model of browser interaction'?) is the tool that helps us let that world go. The handholding, linear user experience has wormed its way to desktop applications in the form of wizards, and they are almost without exception horrendous pieces of user interface design. The inability to cross reference what you're entering on one page with what you've entered before; the modality of the UI preventing you from finding out things you need to know in order to complete the wizard, the sheer number of mouseclicks involved in navigating them; the infuriating splashscreens they insist on presenting at the start and 'congratulations!' message at the end... They are travesties of clean, out-of-your-face interface design. But they're also the only UI that works in the page-based web. Yuck.
Consider how it could be. We could build our order up by dragging items out of the catalogue onto a separate window holding our order form. We could click at any time in the shipping details to enter the delivery address. We could use menus to bring up dialogue boxes that enable us to choose order types, save incomplete orders, load in orders we've previously stored... Ordering from the web could easily adopt a document-based UI more consistent with the way every other application that isn't a web browser operates... But it can't do it if we insist on using hyperlinked pages to progress the user through a process.
I really think AJAX could help save us, because it gives us a name for the kind of programming that we ought to be doing whenever the page model doesn't fit. It means it's easy for us to find the tools and the techniques online because we have a hook to search for, and it gives us a hope, therefore, that more and more development will be done that uses these techniques; and that means that users will become weaned off their expectation that browser-based applications must be strictly page-based; and that means that we'll be able to hit them with even better, richer user experiences. The web might just get interesting again.
There's much more to it than this, though, of course. There's a lot of questions it raises in my mind about the right server-side programming techniques to expose functionality to AJAX client UIs. I really must get around to rereading Web Service Faceplates, one of the books that came out of Wrox Press's ill-fated Early Adopter program but that feels like it might well have been (if only we'd had the foresight to title it so) our Early Adopter AJAX. I'm experimenting with AJAX .NET, which is an incredibly elegant solution for publishing server-side logic via dynamic JavaScript proxies and which provides some very quick development paths for quite tricky problems. I'm not entirely happy I have a clear state management story for this sort of application yet.
And then there's accessibility, and code maintainability, and development methods, and debugging, and separation of content and behaviour from presentation, and... many more issues to consider when we go down this path. It's not going to be easy. But I'm certainly emboldened by this wave of hype for AJAX to refuse to compromise and deliver a UI that stoops to the client's low, page-bound expectations of what a web app can do for them. After all, I can always say to them, "we'll be using AJAX. It's the next big thing. Haven't you heard of it? All the cool kids are using it...". They won't be able to resist...