Far too often users were given weak guidance as to what to expect of format and style of names, credit card numbers, phone numbers, and dates. Much of the time the only way to determine the success or failure of a multi-step process was to get to the end at which point one was often returned to the beginning with some vague admonition that "an error has occurred. Please correct and resubmit the form."

One of the benefits of AJAX has been to radically alter the experience of filling out forms. Forms inputs can be validated character-by-character or line-by-line. The user can be informed immediately upon filling out a given field that the entry in that field is in error.

Indeed, some AJAX-enabled forms have been improved to automatically convert common formats to desired formats. For example, if the credit card number is supposed to be entered with no dashes or spaces, an AJAX-enabled form can simply drop any dashes or spaces entered by the user, adapting the entered data to the target format.

What's the business benefit to this approach?

First and foremost, it minimizes end-user pain. Anything businesses can do to make the experience of interacting with them via the Web less painful will create fewer frustrated customers (or potential customers).

Additionally, leveraging immediate feedback and data clean-up will lead to a greater number of successfully completed transactions, whether or not that translates into fewer abandoned shopping carts, more recurring transactions established, or even a larger number of customer complaints being accurately and efficiently recorded. (After all, if customers are going to complain, it's more effective to accurately and quickly record and acknowledge them than to frustrate an already disappointed consumer).

More Interactive Experience
Traditional HTML-based applications weren't in any real sense interactive. The user "browsed" pages ­ skimming text, identifying links, and then clicking on one of those links to retrieve and display a different text page. The model was (and still is for such applications) fundamentally page-based: the page is displayed, the user request received, the page displayed, the request received, and so on.

AJAX-based applications, on the other hand, can enable much richer interactive models. Assets on the page can be dragged and dropped, opened and closed, hidden and revealed, collapsed and expanded. All of this can be enabled without requiring a full-page refresh with its context-clearing impact on the user.

Google Maps, for example, revolutionized the online mapping space by letting users pan around the map space, updating in near-real time the newly exposed space at the edges of the map. It wasn't that in previous online mapping interfaces you couldn't get to what was just west of your field of vision; it's just that in previous maps you did so by clicking on the west arrow, and an entirely new page reloaded containing the new area of focus.

This was a very disorienting experience, one greatly improved upon by the smooth, continuous impression of the Google Maps approach.

What's the business benefit?

People enjoy using applications that are more richly interactive. They are more likely to use an enjoyable application more often and longer. Given that users increasingly expect the Web to function as the primary channel for interaction with the companies they do business with, its important to be able to offer those users an experience they find enjoyable, not merely create an experience they find less painful.

Responsive Local Actions
Because JavaScript in AJAX applications is run on the client machine ­ it executes in the browser's JavaScript engine, not on the server ­ it can provide a more responsive experience without the latency caused by the need to fetch additional data from the server.

Applications can be designed to download a set of data and then enable the user to take various actions on that data without reloading it from the server: expanding and collapsing items in a tree structure, switching between two or more visible tabs, or sorting data in a table structure. All of these activities, which users are accustomed to from desktop applications and operating systems, can be enabled with local data and JavaScript acting on that data.

So, what's the business benefit?

In traditional Web application development before AJAX, a user who wanted to sort the data in a table might have clicked on a column header. This request would have been sent to the server, which would have created a new copy of the page with the data sorted and returned the entire page to the client. This meant server processing time as well as bandwidth costs to resend data that the client already had. Similarly, the client's native processing power (in today's desktop PCs this is a tremendously underutilized capacity) was ignored, or used merely to render the HTML returned.

Enabling applications to act locally on data received for basic transformation, display, summation, or other functions lowers the need for server processing load and bandwidth in addition to delivering a more responsive experience for the user.

Automatic Updates
Because AJAX applications are delivered via Web browsers visiting Web pages, it's become very easy to update their functionality. Rather than having user download and apply large binary patches by running installers, AJAX applications can update themselves whenever the user visits.

Users get the benefits of always having access to the latest code base and all the newest features, while organizations get the ideal deployment model and don't need to ship CDs, send technicians to employee desktops, or even instruct users to download and run installers, resulting in a lower overall maintenance cost.

Which of these benefits can be realized in your application depends on whether you're integrating specific components into an existing application to solve feature-level usability problems (integrating immediate feedback into registration forms, for example) or creating an entirely new self-contained application with desktop-like interactions.

Just Because You Can, Doesn't Mean You Should ­ Approaches to Avoid
I've focused primarily on the benefits AJAX applications can bring to Web applications. Enterprise users should also be aware, however, of the following cautions with respect to AJAX applications:

We Must AJAXify It!
Beware of any business or IT stakeholder that insists on using AJAX for AJAX's sake. Given any multi-page business application, it's certainly possible to identify places where an AJAX-style approach (partial page transformation, asynchronous request) might add value. But the requirements should be driven by improving the experience rather than having the improved experience tacked on as a post-development justification.

We Need More Widgets!
In the world of AJAX applications, it can seem that whoever ships the most widgets wins. But too many interactive components on a single page can overwhelm the user. If your users aren't early adopters, they may still be coming to terms with the notion that part of the page can update without a page refresh ­ make sure you're not so far ahead of your users that you end up making the experience more confusing rather than less. What works in the latest greatest hot application for bleeding-edge Web developers may not work in a consumer-facing application for e-commerce, at least not without major modifications.

Rip and Replace
Enterprises should focus on deploying AJAX techniques and technologies in the new applications they develop today, and should look carefully at existing applications for opportunities to improve their experience. Rather than creating a set of applications to be "upgraded," look at each application whenever it's up for enhancements or maintenance.

We'll Poll for Changes Every 10 Seconds
Multiple approaches to creating long-lived connections between AJAX applications and their server-side components are being developed and prototyped in many popular AJAX frameworks. However, most AJAX apps still use some form of client polling to simulate server-pushed information. (In other words, an AJAX component in a page polls the server to see if new information is available, ever x seconds). Enterprises, especially those deploying applications to users, have to be careful about leveraging client-side polling due to the potential impact on bandwidth. This isn't to say it's always a bad idea, or even most of the time just that you shouldn't assume no adverse impact. Design, prototype, test; repeat as necessary.

We'll Write It All from Scratch
I've occasionally seen otherwise sane developers confronted with AJAX-style applications turn back into "start with a blank screen" coders.

There are numerous production-quality ready-to-use application frameworks for AJAX-style applications: in just about any server-side coding language, and in pure client-side JavaScript. Many are open source. Some are commercially available. Make sure you're getting appropriate leverage from the frameworks before you dive into custom coding.

Above all, the key to delivering effective AJAX applications is to focus on the business value and the user experience first and worry about the implementation details second. If you find yourself trying to "sell" management on leveraging AJAX, think about what the benefits to the business could be and sell those instead: you'll likely find a much more receptive audience.