For example, AJAX applications exist in one URI namespace. In other words, the URI doesn't change when the user interacts with the application.

This makes sense, as that's one of the main selling points of AJAX: the ability to change application state without refreshing the current page or moving to a different page. However, this renders the browser's back button useless and might even cause the user to navigate from your application altogether.

In 1999 Jakob Nielsen, a well-known usability expert, issued an article indicating the top ten mistakes of web design. The number one mistake was disrupting the functionality of the browser's back button. According to Nielsen, the back button is the "second-most used navigation feature" after the use of hyperlinks. Workarounds do exist to partially replicate back-button functionality.

Another related usability problem has to do with the inability to bookmark a specific application state. In traditional applications, an application state is often unique to a single URI and can therefore be book-marked. An example of this is when a user navigates a product catalog to a detail page of a specific product.

The user might want to bookmark this page for later viewing. Additionally, the user might want to have a friend look at the product and attempt to send the URI over email. Breaking this bookmarking feature can have a significant impact on the effectiveness of word-of-mouth advertising. Workarounds exist that allow for one half of the equation, taking a given URI and forwarding it to your AJAX application to reconstruct the desired application state.

However, because for any given state, the address bar does not contain this URI, this method still leaves the problem of communicating to the user how exactly to bookmark the current application state. The browser's bookmarking feature is useless and the application must provide some other means of bookmarking, usually involving a nonstandard user interface element.

Work that tries to solve these usability and accessibility problems is constantly underway and advances are being made. However, the question that is often overlooked is: Is the usability problem to the result of an inappropriate use of the technology?

This was the case with usability problems with Flash: developers were trying to implement entire web-based applications with a Flash file. It was this misuse, not the Flash technology itself, that resulted in usability problems. The same is the case with misuse of AJAX.

The technology does a wonderful job with an application where it doesn't make a whole lot of sense to restore a given application state. Google's GMail is an excellent example of this. There is very little value in being able to bookmark a given state in a web-based email client. Form additions, such as Google Suggest, are another good example. There is no need to bookmark a state in Google Suggest.

A web-based chat client would also not benefit much at all from the ability to bookmark a specific application state. In contrast, a product catalog suffers greatly if the ability to bookmark a state is disrupted. The usability of a content management system would suffer greatly if the display of a given article could not be bookmarked.

The temptation to apply AJAX techniques to any traditional web application is understandable. However, many traditional web applications would be harmed by the use of AJAX. The commonality among applications that naturally tend to benefit from AJAX is that they are traditionally desktop applications. GMail is a web-based version of an email client, which has previously performed best as a desktop application (indeed, the only real reason traditional web applications for email came about was the ability to access it from anywhere).

Google Suggest acts very much like form controls that have traditionally been found in desktop applications. With the exception of Java applet and similar solutions, chat applications have been almost exclusively desktop applications. Developers have attempted to make pure markup and JavaScript versions of chat applications, but these applications do not compare to their native counterparts.

While there are certainly exceptions, a good rule of thumb is that AJAX is good for taking traditional desktop applications or elements and creating a web-based version. It opens up new possibilities for web applications, but does not necessarily benefit traditional possibilities.

You should take care when deciding whether to use AJAX and ask yourself whether AJAX will be beneficial for the application you are developing. If you are running into serious usability problems that require elaborate workarounds, chances are that AJAX was not the appropriate development model.

In addition to the usability problems, there are the problems of support. Having an application that relies on AJAX without any fallback support for older browsers can block out a very large portion of your potential user base. Even for current browsers, some corporations require JavaScript to be partially or fully disabled for security reasons.

Such users would also be blocked out of your application, if it does not degrade well and offer traditional web application functionality as a safety net. Whether this is acceptable will depend on the nature of your application, because with some applications it is not practi cal to offer a traditional version. Its acceptability will also depend on your expected audience and their likely choice of browser.