Since I wrote about AJAX the first time back in March, it has steadily become THE thing on the web. I hate quoting myself, but here it goes:

Right now, I'd wager that to get VC money, you'll have to do it. Within a year, most webapps will have to do it just to keep pace. Two years from now, no one will even think about building an application without it.

Well, this already seems to be coming true. I have seen an inordinate number of RFP (Request for Proposal/Price) for various sites incorporating all kinds of AJAX functionality. These have ranged from community sites for non-profits to porn sites. It has seen a dramatic uptake faster than many technologies that I've seen online. In addition, I have talked with and met many web developers who are desperately looking to get their application funded and have therefore incorporated RSS & AJAX in an attempt to capture some of the buzz. Is it working? Well, only time can tell.

Regardless, it is a cool technology and has given us some beautifully smooth interfaces such as Google Maps, Gmail, and well, just about everything else from Google. Now I have seen numerous sites attempt to incorporate it simply to be able to talk about their “AJAX implementation”. AJAX in itself is simply a tool that lets you do some great stuff, but if you're just using it to use it, you might want to consider there are times to use it and times not to use it.

Last fall, I did a pre-AJAX implementation which did field validation in real time of work tickets submitted to the system. By putting in a job identifier, information such as the job location, billing address, etc was pulled from the backend system without any further user action. If the job identifier was not valid, it would notify the user and give them the opportunity to continue or change it. [Sometimes work orders would happen before the system was updated, so there was a legitimate reason for non-valid identifiers to be input.] This was a perfect scenario for AJAX because it provides realtime validation and information completion and therefore allows the user to work faster.

Next, I was talking with Cyberhorse (a member of the Web-based Project Management Tool dotProject core development team and part of CaseySoftware) about a simple AJAX implementation that I've just completed. We had a heirarchy which could be N deep and M wide and is built recursively. In this area it made sense to use AJAX because I could go with a Lazy Load Pattern (Fowler, Patterns of Enterprise Application Architecture, pg 200). Cyberhorse pointed out – to my surprise – that the task trees in dotProject currently work the same way. This allows the minimal amount of data (a given layer of a given branch of the heirarchy) to be loaded and we simply don't worry about any other data until its requested… yet another perfect scenario for AJAX as it reduces the load on the server without the user even realizing it.

But I have already seen AJAX used for terrible purposes… for example with navigation bars. At first thought, having a AJAX-loaded navigation bar seems like it might be a Lazy Load Pattern, but ask yourself this: How often does your site structure change? If you have a site like most, once the overall structure is established, specific areas tend to grow, but not the structure itself. Therefore, it is probably a much better idea to simple have the navigation either a static file, created directly from the database, or – if necessary – created from the database on a regular interval. This is important for a few big reasons: a) search spiders can't find your navigation if it's created on the fly, b) users can't use the Back button, and c) users will have trouble bookmarking anything.

AJAX is great for certain things like improving the speed of a users' interactions with the system, validating data in realtime, and decreasing load on the server. It is bad for replacing basic things that normally help users figure out the site/application and/or impede their ability to come back. Complexity for complexity's sake is a bad idea.

Got it? Good.

Write a Reply or Comment

Your email address will not be published.