Ajax and Information Architecture
Nov 23, 12:21 PM by Rich Webster
For the last year, I’ve enjoyed watching the emergence of Ajax as a revolution in web design and architecture.
For those unfamiliar with Ajax, you might want to read about it here, on Wikipedia. The basic idea is to use JavaScript with the “XMLhttpRequest” call. This allows server-side interaction to occur without reloading the web page. A single web page can replace a series of user actions and page loads that can be tedious and confusing.
The design challenge is not such a big deal for those who have designed software on the desktop… this kind of interaction has been there all along. Even those of us who don’t do any serious programming can understand the design issues if we’ve used tools like FileMaker to create databases, or complex Flash user-interactions. The whole point is to make a page responsive to user actions. In fact, what Ajax allows is real web applications. While Flash has allowed that for awhile, Flash is somewhat rigid, and is proprietary. The upside of Flash over Ajax is that browser presentation is absolutely consistent with Flash, while the variability of form elements between browsers is very limiting. Really, the biggest failure of CSS2 is the ugliness of forms.
Unfortunately for non-coders, creating Ajax pages will require you to learn coding, or to get really friendly with someone who knows code, both client-side (JavaScript) and server-side (PHP, Ruby, Java, Python, etc.). Note that I don’t include the Microsoft-centric technologies… there’s no need, and no percentage in learning the Microsoft way, unless your paycheck depends on it. Just stay with the open stuff.
The biggest mistakes I’ve seen with new Ajax web applications is intentional obscuration of interactivity. I see this a lot in Flash stuff, too. The ability of Ajax (really DHTML) to hide a form element, like an “input” element (a field), and have it pop up when the user clicks is pretty awesome. But this is a new, and a learned, behaviour for the user. It’s good to have this ability, but include an “edit” button, too. Be obvious.
Always remember, most websites are not applications: the user does not learn a site (with some exceptions). Most website visitors will only return to the site occasionally, and doesn’t have the time, the energy, or the motivation to figure out how to use a site. The user must be able to intuitively, or by reading, understand what their next action should be, and what the result of that action will be, prior to committing. It is up to the designer to provide these cues.
Also remember: While many people have broadband, and most web designers can barely remember a time before they had broadband (being early adopters), at least 40% of internet users still connect with a modem — poor bastards. It always strikes me as odd when web designers go on about “accessibility” for the visually handicapped, that they then go and fail a much larger percentage of users: the bandwidth deprived!
If you want to learn about Ajax, I’d recommend watching the Ajaxian blog and consider the excellent Head Rush Ajax book.
| del.icio.us | | Digg This | | Technorati |
commenting closed for this article