I've had a few people ask me from time to time why we don't use Ajax in WebGUI. I think they're not paying attention. We've used "Ajax" in WebGUI for years, even before there was a term for it. But before we get into it, we should probably talk about what ajax means.

AJAX is an acronym which means Asynchronous Javascript And XML. To a techie, that means that you can send data back and forth from your browser to the server without refreshing the page, and that's it. But to the end user, it means much more, it means dynamic HTML--meaning anything fancy you see in the browser. It means cool animations, faster pages, and non-web-like functionality. Basically, to them it means that the web acts more like a desktop application.

I said we've been using Ajax in WebGUI for years, and I meant it. And we're using it in both respects. We use dynamic HTML effects in the form of rich editors, date pickers, and other useful utilities. And we use asynchronous communication between server and browser in drag and drop content positioning. And we've been doing a lot of this stuff since the very beginning in WebGUI, more than six years ago.

Even though we've been doing this stuff years before anybody else was doing it, people complain that we haven't adopted Ajax. The reason is that the stuff we have been doing no longer seems special, because everybody and they're brother is doing these kinds of effects these days.

I'm not a fan of using buzzwords or technologies like Ajax, just because they're the latest craze. Sure it's cool, but is it useful? Does it improve the user experience in any way? Unfortunately the answer is 25 shades of grey. In some cases it actually does improve the user experience. It can make the web more intuitive. In some cases it can also make the page feel more responsive. Those are good things. However, a lot of it is just eye candy that works only in the latest browsers, makes things ridiculously hard to template, and causes performance problems on servers.

So how do you split the good from the bad? It's not easy. You can't be charmed by the shiny pretty things. You have to look at the nuts and bolts of the thing, and make decisions based on that. For WebGUI there are two pieces to this puzzle. There's admin mode, and regular viewer mode.

In regular user mode browser compatibility is a big concern, as are concerns for accessibility standards, performance, and usability. Therefore sorting the good and bad of ajax is a more difficult task. We've already started using ajax in the end user apps that demand it, like wiki, project management, and calendar. We'll continue to do that, but we'll be slower and more deliberative about making those decisions with end user apps.

In admin mode we have a lot more controlled environment. We don't have to worry as much about browser compatibility, or the impact of performance on the server, because we're talking about a relatively low number of users in a controlled environment. This is not to say that we can forget about those things either, but just that we have more flexibility. This means we have a pretty large opportunity to adopt ajax technologies in a big way in admin mode. I think we can improve usability somewhat. More importantly though, I think we can improve performance of admin related functions by 100% or more. That's significant.

More to come. Same bat time. Same bat channel.