meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Increasing the Strength of Ajax

There’s been some comment recently about how Ajax programming requires a different approach to UI and user notification.  What Jeff Veen wrote about Designing for the Subtlety of Ajax, and Alex Bosworth‘s post on the top 10 Ajax Mistakes, are just two examples.

I pretty much agree with both pieces.  I’ve missed upates more than once on Ajax pages, just because I’m too used to how pages usually work.  I’ll click on something and then my attention will, out of habit, instantly go elsewhere—another window, another application, another computer, whatever—and keep subconscious track of what was happening in the window where I clicked, monitoring it in my peripheral vision for the flicker of a page reload.  Eventually there will be a little tickle in the back of my brain that says, “Hey, didn’t that site ever do anything?”  When I finally look straight at it, I realize that it did something quite a while ago, probably a split second after my mental focus moved away.  Instead of being efficient, I was wasting time waiting for a refresh that never came.

One might think it’s time for an “Ajax enabled” badge on pages so we know “better pay attention, ’cause this ain’t your father’s Web page”.  I don’t think that’s the way to go, however.  I think what’s needed is a more mature HCI design sense.  Web design has long relied on the page-update refresh to tell the user something has happened; this was such a part of the Web’s fabric that designing around it was almost unconscious.  There hasn’t been a need for sophisticated HCI considerations… until now.

In other words, Web design is going to need to grow up, and become more HCI-oriented than it has been.  The usability of a Web site will become as much about how you let the user know they’ve done something as it is about getting them to the thing they want to do.  In addition to getting the page to look inviting and present the information well, it will be necessary to obsess over the small details, implement highlights and animations and pointers—not to wow the user, but to help them.

In this endeavor, it’s worth remembering that there is a very large and long-standing body of research on HCI.  For years, many HCI experts have complained that the Web design field is making all sorts of errors that could be avoided if we’d just pay attention to what they’re telling us—a criticism which was not totally inaccurate.  Some Web design experts shot back that the Web was a different medium than the sorts of things HCI people studied, and anyway, the Web was not an application—and that rejoinder was also not totally inaccurate.  But with Ajax, the Web-application dichotomy is disappearing.  The retort is becoming less accurate, and the criticism more accurate.

I don’t claim to know what should be done.  The simplest update notification would be to set the visibility of the body element to hidden for half a second, and then back to visible, thus visually simulating a page refresh.  Crude, but it would play directly to users’ expectations.  The fading yellow highlight in Basecamp gets a lot of attention (and imitators), and that’s a good way to go too.  We could envision tossing a red outline onto something that changed, or animating a target-reticle effect on the updated content, or any number of other ideas.  Again I say: the decades of work done in HCI research are a resource we should not ignore.

From my perspective, there are at least two good things in the Ajax world.  First is that the need for understanding and using CSS, XHTML, and the DOM has never been greater.  Okay, it’s a slightly selfish thing, but it leads directly into the second good thing: that the need for standards support has never been more critical.  If a browser wants to play in the Ajax space—if it wants to be a serious platform for delivering applications—then it’s going to have to get along with the others.  It’s going to have to support the standards.

Eight Responses»

    • #1
    • Comment
    • Mon 20 Jun 2005
    • 0611
    Gregory Wild-smith wrote in to say...

    Surely this isn’t anything to do with AJAX, it’s about UI design? AJAX is just exposing how little most web-designers know about application design.

    Putting the blame on AJAX enabled pages is wrong, but does seem to be what people are doing. As you say Eric – it wasn’t the AJAX that foxed you – it was the lack of responce.

    Basically it’s starting to sort out who knows good web design, and who just knows how to create something pretty…

    • #2
    • Comment
    • Mon 20 Jun 2005
    • 0615
    Gregory Wild-smith wrote in to say...

    Reading that back it sounds like I missed your point, which I didn’t, so I should clarify.

    Surely rather than making a list of “AJAX Mistakes” it is better to talk about “common UI mistakes in web applications”? Because else it is like blaming JavaScript for popups – accurate, but not really getting to the root of the problem.

    Therefore isn’t it less about increasing the strength of AJAX, and more about increasing the strength of the web?

    • #3
    • Comment
    • Mon 20 Jun 2005
    • 0634
    Nico Edtinger wrote in to say...

    When I did a webpage with AJAX I added a throbber. That’s what my browser does next to the URI and at each tab. Having this rotating animation tells me “something’s loading”. And it worked quite well.

    b4n

    • #4
    • Comment
    • Mon 20 Jun 2005
    • 0846
    Anup Shah wrote in to say...

    Good points Eric. The other issue with Ajax for web sites may also be accessibility.

    Parts of a page automatically updating will cause some screen readers to start reading the updated content, and thus lead to a LOT of disorientation due to the unexpected change.

    Not sure if there is always an easy way around this, depends on the nature of the particular web site being developed. (And becomes even more of a gray area when considering if it is a web application as opposed to a web site!)

    Perhaps it implies again that “progressive enhancement” is a key — start with semantic markup, add css, add javascript, add Ajax? (But how does one ‘disable’ the Ajax, or even know they might need to…?)

    Many questions, in what is otherwise an interesting area!

    • #5
    • Comment
    • Thu 8 Sep 2005
    • 0619
    Julian Turner wrote in to say...

    In my rough (and not very cross browser) attemps at AJAX, I inserted a status bar at the bottom, which advises of status, and flashes orange when loading is complete.

    • #6
    • Pingback
    • Tue 8 Nov 2005
    • 1017
    Received from Meriblog: Meri Williams’ Weblog » Links II

    [...] ind this elusive Web 2.0 idea… On that note, Eric has written a great article about the demands Ajax places on web design. I agree that we’re goi [...]

    • #7
    • Comment
    • Tue 22 Nov 2005
    • 1003
    Dustin Kirk wrote in to say...

    Data loading is something that I imagine will quickly have to be adopted by browsers. For example status indicator such as that at the bottom of IE will likely need to function much more like that of the loading indicator on Google Earth. Not only should one know that something is happening, but also how much is happening. An icon shouldn’t throb simply because a connection is left open, but should also indicate if data is being loaded and how much is expected. Sites may supplement this indication temporarily via their own indicators, but at some point soon this will need to be handled by the browser.

    • #8
    • Pingback
    • Tue 2 Jun 2009
    • 0524
    Received from Max Kiesler - Designer » Blog Archive » Downloadable Web 2.0 and AJAX Widgets

    [...] and what not to do with AJAX. Have fun. : ) Jeffrey Veen posts: Designing for the subtlety of Ajax Increasing the Strength of Ajax Alex Bosworth posts Ajax [...]

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


June 2005
SMTWTFS
May July
 1234
567891011
12131415161718
19202122232425
2627282930  

Sidestep

Feeds

Extras