IA in the age of Ajax

Brian Dillard, Wednesday, December 19, 2007 @ 5:25 am

On Monday, Richard F. Cecil of UX Matters published an interesting piece titled Documenting the Design of Rich Internet Applications: A Visual Language for State. In it, he discusses the challenges facing information architects in the Ajax era. Full of practical, how-to advice for IAs and developers, it's already prompted some interesting comments. I'd recommend it to anyone interested in the process of developing RIA specs.

A few months back, some former colleagues of mine - both of them top-notch IAs - approached me about putting together a panel discussion about just this topic. The panel never happened, but our initial discussions got me thinking about the role of IA in RIAs. As web-based user interfaces grow more complex and modular, many of the traditional approaches to IA fall by the wayside. Steve Hansen, a commentator on Cecil's piece, nails the problem:

As someone who designs and builds complex RIAs, with complex non-linear work flows, I have been struggling to find the ideal modeling vocabulary. Things get even more interesting when you have complex server back-end functions. I currently use a hodge podge (technical term) of wireframes, UML activity, sequence, and communication diagrams and whatever else seems to fit the bill. This is surely an area ripe for discussion and exploration.

It's clear to anyone who's ever worked on even a moderately complex Ajax application that screen-based specs don't cut it. Unless documentation breaks things down into individual components, controls and user actions, it will fail to capture all of the possible conditions. Even a component as commonplace as an image carousel or a rich-text editor includes more discrete points of user interaction than an entire webapp did five years ago. Throw in something like keyboard commands - a topic Cecil's piece doesn't broach - and the complexity multiplies. And let's not even talk about the need to document accessibility modes.

I'd be interested to hear from people with more of a desktop software background - the same folks who are flocking to GWT - about their approach. I don't know much about IA in the desktop world, but I imagine that webapp IAs will be looking there for inspiration. Desktop GUI frameworks don't offer the free-for-all that HTML, CSS and JavaScript do. There's less freedom, but there's less of a burden to reinvent the world over and over.

That's why the GWT or Ext model offers productivity gains not just for developers, but also for IAs and designers. If your interface is built out of standardized widgets rather than build-your-own components, much of the documentation can live at the widget level. Application IA then benefits from a shared vocabulary in which common interactions have already been described and it's only corner cases and the interplay between components that need individual documentation. Users win, too, because they don't have to figure out how, for example, your date-picker works; it's just an instance of the same date-picker widget they've used in other applications on the same platform.

As Ajax UI toolkits mature, it will be interesting to see how their authors balance the desire for completely customizable interface components with the productivity and usability gains of componentization. At what point do bells and whistles cost more in complexity than they deliver in novelty?

Technorati Tags

• information architecture
• usability
• JavaScript
• Ajax

agile ajax

Comments

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

None so far.

Leave a comment