After seeing Eric Pascarello’s thread at ASP.NET forums entitled “AJAX – Is it Hype? Is it for you?” I decided to post a thread at ASP.NET forums with a reference to my post from July entitled “AJAX: A Panacea, or a Pending Train Wreck?” UkBtlog responded so I’m blogging my reply below:
UkBtlog states:
I think there needs to be a big distinction between web applications (gmail, google maps, online banking) and web sites (msdn, wired, www.asp.net. AJAX is primarily useful for web applications. AJAX has limited use for web sites.
I’ll agree there is a big distinction in some ways, but that’s part of the point. Most web developers will be drawn to AJAX because it’s the “next cool thing” and you’ll see AJAX on practically every site, and in most cases very badly done. This is no different from when people went crazy with desktop publishing software using tons of fonts and colors in a document! But bad AJAX on the web will have a much more profound negative impact than ugly flyers posted on a light pole.
I’m not arguing that web developers can’t use AJAX well, I’m arguing that AJAX opens a pandora’s box where most web developers will use AJAX and few will do it well.
UkBtlog states:
I don’t believe that AJAX is actually useful for things that search engines are best at searching. To use the example of MapQuest and Google Maps, I have never searched for London Bridge and had MapQuest come up as a result in a search engine. This although it uses query string parameters to be deterministic it isn’t something that is searchable. I can also use the robots.txt to stop search engines and google even tells me how.
Again, we mostly agreed, but UkBtlog again missed my one of my points; web developers will use AJAX badly on web sites that should be searchable.
UkBtlog states:
This is the same as restarting an application and isn’t really a suprise to developers. Sure this may not be the expected user experience, but perhaps the dom standards should give web application developers a way to stop the use of refresh if web apps are to mature.
It’s not a surprise for web developers, but it’s a huge surprise for web users! And a bad one at that!!! One of the reason for the success of usability on the web has been the consistent and constrained UI. Web usability guru Jakob Nielsen quotes in The Top Ten New Mistakes of Web Design (May 30, 1999):
Jakob Nielsen states:
1. Breaking or Slowing Down the Back Button
The Back button is the lifeline of the Web user and the second-most used navigation feature (after following hypertext links). Users happily know that they can try anything on the Web and always be saved by a click or two on Back to return them to familiar territory. Except, of course, for those sites that break Back by committing one of these design sins:
- opening a new browser window (see mistake #2)
- using an immediate redirect: every time the user clicks Back, the browser returns to a page that
- bounces the user forward to the undesired location
- prevents caching such that the Back navigation requires a fresh trip to the server; all hypertext
- navigation should be sub-second and this goes double for backtracking
Further, from Why Frames Suck (Most of the Time) (Dec 1996):
Jakob Nielsen states:
13% of users are still using Netscape 2 which had one of the worst usability problems to be seen on the Web so far: the BACK button in the browser simply didn’t work with framed sites. The BACK feature is an absolutely essential safety net that gives users the confidence to navigate freely in the knowledge that they can always get back to firm ground. We have known from some of the earliest studies of user navigation behavior that BACK is the second-most used navigation feature in Web browsers (after the simple “click on a link to follow it” action). Thus, breaking the BACK button is no less than a usability catastrophe.
And I wouldn’t attack the sources for being old; usability is based on the way humans process information and that doesn’t change rapidly just because someone coined a new term and all the bleeding edge web developers have jumped on it!
Also, Jakob hasn’t written about AJAX, yet, probably because he writes about his usability research results, not just his opinions (like you and me :), but I’m sure he will as soon as he has solid data to back him up.
UkBtlog states:
Developers of web application spend a lot of effort and tears trying to remove the problems of back buttons and refresh behaviour. The web browser shouldn’t be trying to hold state, although it happens to cache the previous page, as HTML is supposed to be stateless. So if I want to buy into implementing state into a website such as using cookies or hidden fields or fancy frameworks like ASP.NET I don’t want the browser interferring with my application state. If I am writing a web site for a company that informs the world on what they do, then I am not keeping any state and the back, forward and refresh buttons hold no fear. Your view is a little simplistic for the variance in reasons for developing for the web.
The criteria for expanding web functionality shouldn’t be about how to make it easier for the developer!!! The web should be about making it easier for the user, and about empowering solutions that were previously unavailable. The stateless web addressable via URL with a well defined content set (HTML, GIF, JPG, and now PNG and PDF, DOC, XLS, etc.) is the technology that has empowered so much economic expansion and functionality on the web. Making it easier for the developer while ignoring other goals will just drag us down into the new dark ages; the dark ages of the web.
UkBtlog states:
AJAX maybe abused as it is the new cool feature, but using framesets or domain rewriting can lead to similar problems. I can also use pointers without correctly releasing the memory, but I don’t.
And you’ll note most web developers have finally stopped using framesets (thank god!) I had some of the same issues with them. (I don’t know specifically what UkBtlog meant about domain rewriting.)
UkBtlog states:
Any of the technologies developers are presented with can be used in a way that is not best practice. If you do this with an information website such as Wired.Com or MSDN the information will not be found and your business will suffer. I only see this “misuse” of AJAX existing in proof of concept and misinformed developers.
This isn’t about what one developer such as UkBtlog does. It is about the health of the web. Many cities have ordinances that say you can’t have a grill on the balcony of an apartment or condo for the same reason. I can make sure I don’t burn down the building with *my* grill, but what about my neighbor? If he doesn’t use his grill safely, he’ll affect *me*. Albeit an extreme analogy, the same is true for AJAX and web developers for the web.
UkBtlog states:
Perhaps we should encourage article writers to discuss best practice use of AJAX to help remove your fears.
Now with *that* I complete agree! So why do you think I am writing these blogs? :-)
But not only writers. We should also encourage tool vendors like Microsoft with their Atlas, and anyone making AJAX toolkits to really think through the issues and make sure their tools encourage best practices.
But what are those best practices? Thus far, I’ve only complained about AJAX. When I have time, hopefully soon, I’ll make some recommendations as I see it for minimizing the threat and maximizing the benefit of AJAX.