Three Places to NEVER Use Ajax	2.0/5.0 (1 votes total) Rate: Select 1 - Terrible 2 - Poor 3 - Average 4 - Good 5 - Outstanding
Bill Boulden May 30, 2006

The web is a-hummin’ with the wonders of Ajax and all it can do. Smoother user interface! No page load times! Makes it seem like a desktop application! Ensures buzzword compliance!

So now we have sites written in Ajax from top to bottom, from head to toe. And as if there wasn’t enough pressure from the blogosphere to implement it, we’ve even got the occasional guide on where Ajax must be used. As of lately, developers seem ready to use Ajax on anything that sits still long enough, plus some moving targets too.

Before you go drop-kick your new web app with the mighty boot of Ajax, perhaps you should stop and consider… the three places to never ever no not ever use Ajax. Plus, as an added bonus, you get reasons why! Everybody loves justifications!

1. Username and Password Logins. Yes, I’m sure I’ll get torn a new one for this, but there’s a pretty solid argument to be made for leaving all “login with username and password” to be performed the old fashioned way, with a normal page request cycle form submission. Basically, the vast majority of the web was built around an assumed standard for the way logins worked- a reasonable assumption that there would always be a field for the username or email address, another for the password, and a submit button. Thanks to this easily recognizable pattern, we can enjoy the convenience of password managers.
   Now, in the world of Ajax, we’re seeing some pretty zippy reinterpretations of this simple theme. A page can do trippy-fun stuff like slide the login box off the screen and slide your account summary back on in its place. Fantastic! Except it’s not necessary whatsoever and it comes at a big price…
   When you abandon the standard login model for an Ajax one, you effectively thwart every password manager in common usage today. Not only that, it’s not like future password managers will be able to easily develop a way to manage Ajax-based logins. The reasoning is pretty simple: there’s no longer any easily recognizable pattern to identify a login with; standards are notably absent. Where once, you had the ubiquitous submit button on a password field, now you’ve simple got some image with an onclick = “yourProprietaryNonReplicatableAjaxLoginMethod();” attribute. Not a trend that browser plugins are going to have a fun time adapting to. Meebo is probably the worst example of this. I log into it constantly all day, and no password manager I’ve tried can remember my passwords, since there’s never a form submit at any point in the meebo experience.
2. Credit card purchases or similar, uber-top-priority confidential data. Thank God, I haven’t seen a site attempt this yet; it’s more of a preemptive warning designed to make anybody who was even contemplating it think twice. When charges against somebody’s financial accounts are at stake, it is not the time to impress a user with your slick, shiny interface. It is time to present them with a comfortable and above all familiar procedure that they can immediately recognize as the way things are normally done. Maybe some of you are made of tougher stuff than me, but if I ever entered my Visa number and security code on a website, hit submit, and saw a “LightBox.js” fade in from the top of the screen with my confirmation message, I’d walk away feeling weirded out and a little unsure that it went through safely. Another potential problem is that this opens the door to double or triple submissions of orders. Most internet users are used to clicking submit and then sitting back while the little graphic in the upper right of their browser spins or the progress bar in the lower right loads; that’s a visual feedback symbol, informing them that internet communication of some type is happening right now, and at the very least, something is happening as a result of their submission. With asynchronous XMLHTTP requests, you can’t really count on those feedback symbols kicking in. So when a user fills out his information and hits submit, and doesn’t see the little “e” start spinning, what will he think? “Oops, I must not have clicked it,” and so he’ll click it several times, and then you’ve got an upset customer on the line with your billing department yelling about the triple charge to his credit card.
3. When a user is likely to be juggling multiple windows at once. With the advent of tabbed browsing, it’s to be expected that some of your users will be trying to manage multiple instances of your site open at the same time. The traditional model of hyperlinks works very well for this, but Ajax fails miserably without considerable amounts of work. Simple reason: a URL hyperlink is indifferent as to whether you view its target in the same window versus opening that URL in a different window or tab or whatever. Javascript callbacks are most definitely not. Consider the following example:
   I’m using eBay. Depending on whether I’m power buying or just browsing, I’ll sometimes do a search and then click items in place on that page, then hitting back, look at another item, back, etc. Or, sometimes, I’ll fly down the page and “open in new tab” every link that looks good, loading all the back tabs of my browser with a dozen pages that I can then browse through at my own rate. Or I can bookmark some for later reference, go back and then go forward again; in essence, I can pretty much navigate the site however I damn please.
   Now I’m using GMail. It’s pretty much the polar opposite. There’s only one way to use GMail, and it’s the way the designers of GMail intended: in a single window, using their mouse-intensive hyperlinks to go back and forth. I would love to fly down my inbox the way I do with eBay, opening each e-mail in a new tab and then dealing with them one by one, but that isn’t even an option- the e-mails are javascript triggers, not hyperlinks. Using the back and forward buttons in my browser is supported in some places but not others. It annoys me every single time I use GMail, and I still haven’t gotten used to the fact that I can’t middle-click those e-mails.