This elegant solution lets the user remain in control rather than deciding on the user's behalf. If, indeed, the user intended to navigate away from Zimbra - perhaps using the application for now - the user can simply hit OK and be off to the requested page. If the user didn't intend to navigate away, a simple cancel returns them to the active context without interruption.

Google's Gmail, on the other hand, supports the back button by taking meaningful action when the user clicks it. If you're viewing your inbox and click on a particular message, Gmail loads that message in the center content pane. Click on the back button and you return to the inbox view. Because Gmail treats the different views in a fashion consistent with the Web-native page metaphor, it makes sense that the back button should funct ion this way.

Similarly, applications that run in Web browsers should either support or provide meaningful alternatives to bookmarkability and link sharing. Google Maps is a wonderful example of this, providing a "link to this map" icon that enables users to reproduce a complex map, complete with zoom level, map type, and current center point, simply by providing a URL.

Learning What Not to Do, All Over Again: Security in AJAX Applications
Some have argued that AJAX applications are necessarily more insecure than traditional Web applications, because they inherently expose a larger "attack surface." While I'm not certain I agree with calling any broadly defined development approach inherently less secure - we've all seen how poor development practices can make any application prone to successful exploits - these critics are right to point to two specific concerns. These concerns are not in fact unique to AJAX development, but they do have to be understood in new ways.

First, never trust any data that comes from the client. This has been a truism of Web development from the beginning. In fact, this was true in client/server environments as well: just because it was much more difficult in client/server environments for someone to manipulate the client didn't mean that client input shouldn't be checked.

The difference that an AJAX application introduces, as compared to a traditional Web application, is the fact that more data manipulation and processing can be done on the client, and more complex interactions can be expected between the client and server. The developer has to be aware that the threshold is fairly low for users to create alternate clients that return falsified, inaccurate, or (worse) deliberately malicious data. Any kind of Web input form was always already subject to such forgeries and attacks - but in an AJAX Web application you may have many more of them.

While one might be tempted to assume that an HTTP request generated by a client-side JavaScript function deep within your complicated application is less likely to be forged than a simple Web form, but this is a slippery slope. Far better to assume that any input that comes from the client (either directly from the end user or from a JavaScript function) is guilty until proven otherwise.

Second, don't send data to the client that you don't want the user to see. This has also been a Web truism from very early on. Many systems are careful in responding to failed logins to avoid giving more information than necessary about what went wrong - typically not telling you, for example, whether there is or isn't a username matching what you entered, just that the username-password combination is invalid.

The fact that AJAX offers the ability to do client-side form validation doesn't mean that you can skip server-side validation (remember truism number one above), and it also doesn't mean that you always should do client-side validation. Doing so will reveal to the user what the correct formats are. (In general this is not a bad thing - but if, as in one recent public example, what you are validating is a "discount code," revealing that code to prying eyes is a no-no).

The Internet Is a Series of Tubes, and the Tubes Can Be Filled: Keeping Traffic Light
Another common complaint about Web applications that leverage AJAX is that they can be hard on the infrastructure: creating additional traffic through a higher number of requests and swelling bandwidth as large JavaScript files are downloaded. Although the increasing prevalence of broadband has made site download size less of a factor, it's still critical that Web-based applications don't ignore bandwidth consumption and traffic generation.

AJAX developers should pay close attention to caching strategies, designing, segmenting, and combining code so that libraries of JavaScript can be aggressively cached on the client and don't require frequent downloads. In addition, developers shouldn't overlook compression options for JavaScript code.

It's also important to be cautious about the network travel your AJAX application generates.

Remember that there are two important factors at play: actual performance and perceived performance.

The actual performance is the volume of requests the Web server handles in a given unit of time, and it includes asynchronous JavaScript calls as well as the direct user-initiated clickstream. AJAX applications often increase the number of HTTP connections each client will make to the server, and may or may not increase the number of requests each client makes.

The perceived performance is much more difficult to measure, but has to do with how responsive users perceive the application to be. If certain requests are made asynchronously, they may appear more responsive when the user actually examines the data, having been "pre-fetched." On the other hand, if the number of asynchronous calls going on is high, it may actually begin to negatively impact the users' experience.

The key is that at the end of the day, actual performance and perceived performance are tenuously linked: applications with lower actual performance may be perceived as having higher performance, and vice versa, depending on the end users' experience. (Of course, there are infrastructure cost factors to the actual performance as well, perceptions aside.)

Your best bet is to prototype rapidly, measure early, and improve iteratively. Don't wait until the end of a cycle to discover that your application will saturate your connection or take prohibitively long to load.

The More Things Change...
All in all, the good news is that the principles that make well-designed AJAX applications aren't radically different than those that have been best practices all along in Web-based applications. The new capabilities AJAX offers inevitably create scenarios where there is no clear design consensus and where the application of the principles requires careful planning, thoughtful design, and a fair amount of trial and error.

But it sure beats DHTML and the "Stupid Browser Tricks" it forced on us.