Ajax for Ajax’s sake

Brian Dillard, Tuesday, August 7, 2007 @ 4:56 am

The problem with new technologies is that they quickly get misused the same way the old technologies did. Case in point: this discussion of Ajax in an article from Internet Retailer titled Web 2.0 tools improve shoppers’ experience, sales, experts say (emphasis mine):

Web 2.0 technology enables customers to get more product information and interact with e-retailers, says David Fry, president, Fry Inc., an e-commerce development and services provider. Key features include customer ratings, user-generated content and even customer photos showing how they use a product, Fry says.

Ajax design tools enable such features. "We think Ajax is the most important technology to be using now," Fry says.

This kind of boosterism may help generate revenue for web shops by making the target audience (business and product folks at small and mid-sized eCommerce sites) afraid of falling behind the times. But it's also short-sighted. Ajax shouldn't be an end in and of itself. It should be a means to an end: making the user experience richer, the application faster and easier to use, or the product more compelling. If Ajax features aren't backed by intelligent UxD, then they're just high-tech wallpaper.

Just look at Flash circa 2000. So many useless bells and whistles. So many slow-loading, low-value splash screens with oh-so-enticing "skip intro" links. So many pointlessly animated navbars with silly transitions slowing down every interaction. It took years - and the maturation of ActionScript - for Flash to lose the stench of its early overuse and misuse. When effects libraries and Ajax interactions get thrown onto sites with the same reckless abandon as .swf files did at the height of the dot-com bubble, it just gets easier to argue that "Web 2.0" is an overheated marketing term.

Over at Bank of America's online banking application, they're really trying to get with the times. When you type in your password and press the submit button, a little message pops up:

Your request is being processed. Please wait.

Cutting-edge, right? Of course, the message is in red, making it appear to most users that they've made an error. There's no visual transition to signal that an event has taken place. Presumably this little enhancement was made to reduce the number of users who spawn multiple requests by repeatedly submitting the form. Yet the submit button itself doesn't disappear. So what's been gained other than the magical appearance of a confusing message - especially when the application on the other side of this login screen benefits from no RIA functionality?

This example is pretty insignificant, but it's indicative of the silly uses to which Ajax (or just plain DHTML) can be put. Another example comes from a previous job of mine at which my team developed a pretty sweet JavaScript library for the management of modal content. Once the product-development folks got a look at the demo, "lightbox" and "microcontent" were the buzzwords for months afterwards. Every new screen had to feature either a little popup bubble full of additional information or a full-screen overlay with scads of content. Never mind whether cramming these new interactions into the same old screens made any sense to the users - or contributed additional click-throughs and purchases.

So how _does_ a small or medium-sized site without a huge app-dev team of its own get some of that Ajax magic? I think a good first step is to treat Ajax as high-teck spackle. Apply it to the holes in your Web 1.0 user interface and you'll provide some real value without having to re-architect from the ground up.

• Replace popup windows with lightbox and microcontent: For small and medium chunks of supplementary data, it makes sense to get rid of popup windows and replace them with inline Ajax popups. You get to bypass popup blockers and some types of security alerts while delivering structured data one step at a time within a single window. Because informational popups are usually such a self-contained funtion of your UI layer, you can often do this with little impact on the brains of your webapp.
• Replace huge chunks of content with lightweight outlines and asynchronous calls: Why weigh down your initial pageload with a photo slideshow, mind-numbing product minutae and dozens of paragraphs of user reviews? If this content gets hidden way below the fold or squirreled away in DHTML tabs, most users will never see it. Instead, scale back to a lightning-fast initial page and grab the additional content only when the user requests it.
• Replace client-side validation with successive server calls: Like info popups, client-side validation is usually handled by fairly self-contained code. It's easy to rewire the display of error messages to use DHTML instead of alert() popups. For a little more investment, you can ditch your redundant client-side libraries altogether and query the matching server-side validation logic one form field at a time. If you already rely on server-only validation, then it's even easier. Depending on how you currently handle validation, you'll either reduce code maintenance costs, improve the user experience, or both.

However you choose to dip your toes into the Web 2.0 waters, just remember: Save flashy effects libraries for when you're ready to provide a true RIA experience. Sure, some cool script.aculo.us transitions _seem_ like an easy way to jump on the bandwagon, but if you employ them for their own sake, without a strong grasp of how and when they're useful, then you might as well replace your homepage with a gigantic Flash animation. Just remember to provide that "skip intro" link.

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment