Designing for the subtlety of Ajax, by Jeffrey Veen

Designing for the subtlety of Ajax

As I've been incorporating more and more Ajax techniques into the interaction design work I do, I've started to realize the importance of subtle clues to indicate change -- a design challenge I really haven't had to worry about much before.

Not all that long ago interaction on the Web was a lot simpler -- you clicked a link, the page you were on disappeared, you waited a bit, a new one appeared. No feedback was really necessary. Clearly, something had occured. Whether it was what you were expecting was another matter entirely. From an interaction point of view, there was no question that your action had a reaction from the system.

Enter Ajax. Now, I have the option of requesting bits of data whenever I need it, and updating just parts of a page that has already been rendered. No longer am I required to refresh an entire page every time a user clicks a link or submits data. With Ajax, I can chose.

That choice, however, has implications. For one, it flies in the face of most established conventions and user expectations. "Click-reload" is pretty different than "click-add an item to a list." So it's not surprising that designers are starting to respond to the fact that users might not notice those subtle changes.

One of the first, and likely the widest linked, examples was from 37Signals in their Basecamp project management app. In it, they showed users that something had been added to the page by turning that item's background bright yellow. "Hey! Look at this!" Then, they quickly faded the obtrusive color back into white. It was effective, and widely copied. And rightly so -- it's a good example of making the subtle obvious.

Recently, I saw a demo by Bill Scott of Sabre Airline Solutions. He was showing an application for their travel logistics application, and in particular, how to use Ajax for what he called "cinematic effects." These were created, he said, to help users understand that an Ajax action had the intended effect. When dragging and dropping, for example, existing items nudged out of the way to show users they could drop. Buttons faded out after clicking. Accordion controls scrolled smoothly when opened. All of these techniques where appropriate and even delicate, never veering into the gratuitous -- though it would be so easy to over do it.

Even cooler, Bill and his team have released their Ajax framework under the Apache 2.0 license at OpenRico.org. The demos and code are all online (though, not quite working in Safari yet).

I'm looking for other examples, both good and bad, of designing for subtlety. Know of any?

This entry was written by Jeffrey Veen and posted 12 June 2005 at 9:37 PM. It was filed under Web Design.

Comments

1. On 12 June 2005 at 11:44 PM Roy Schestowitz wrote:

The lastest release of the Horde project has plenty of subtle feedback for interaction.

Examples: pointer changes to a finger when unfolding menus; "+" changes to a "-" and vice versa; Hovering will result in different background colours to indicate 'severity'.

2. On 12 June 2005 at 11:49 PM Robert Bousquet wrote:

A lot of Ajax/Javascript stuff is happening within the Ruby on Rails community. My favorites:

Ajax Upload Progress - http://sean.treadway.info/demo/upload
Autocomplete on Steroids - http://mir.aculo.us/images/autocomplete1.mov
JavaScript Visual Effects for Prototype - http://mir.aculo.us/effects/index.html
JavaScript Drag-and-Drop extension for Prototype - http://mir.aculo.us/demos/draggable.html and http://mir.aculo.us/demos/draggable2.html
Prototype Javascript Library - http://prototype.conio.net/

3. On 13 June 2005 at 1:26 AM Eddie Sowden wrote:

I know this was arround before the 'Ajax' hype started. But Dunstan Orchard's (1976design.com/blog/) live search has a nice little activity disk to show that some server side is happening.

4. On 13 June 2005 at 6:07 AM Jody Ferry wrote:

Similiar to what you were describing Jeff, there are color changes and text hover effects that let user's know they can drag and drop the modules here http://projects.backbase.com/RUI/portal.html

5. On 13 June 2005 at 8:10 AM Michal Migurski wrote:

Javascript-level activity indicators are a little too bespoke. They'll do for now, until Safari or Firefox comes out with more explicit XMLHTTPRequest status display built right into the browser.

6. On 13 June 2005 at 8:26 AM Dave wrote:

Been playing with myself, although i've only so far been able to manage the guestbook based on AJAX

7. On 13 June 2005 at 1:03 PM John Dowdell wrote:

These are new issues for JavaScript developers, true, but there's a wealth of info out there from people who have already been designing high-continuity interfaces -- for instance, last week Sho Kuwamoto describes some of the interface issues he's encountering in his own move from JavaScript to SWF:
http://www.macromedia.com/cfusion/event/index.cfm?loc=en_us

But even classic desktop apps from the 90s had to deal with these same issues, right...?

jd/mm

8. On 13 June 2005 at 1:05 PM John Dowdell wrote:

whoops, sorry, copy/paste error... try:
http://www.markme.com/sho/archives/007873.cfm

9. On 13 June 2005 at 5:21 PM vanderwal wrote:

One of the things I have been noticing while playing with Yahoo's beta travel planner, it updates items I am adding to my list of things I have interest in. That section of the page that is updating, visually flushes the content, which causes a semi-noticible blink. Personally this works well for me as I am not distracted from my real task, which is finding things I want to do on that trip.

Have you tested around to see if people are distracted from their task at hand? Quite curious.

This is a very helpful perspective, thanks for posting.

10. On 13 June 2005 at 5:51 PM jason carlin wrote:

I'm in the process of designing a new registration process for a client. I'm considering running a validation for each field onblur or onchange with a delay. I'll be using an RPC to check username and email availability, but not committing anything until the form is submitted.

In this case, there's a definate risk of distracting or confusing the user by giving feedback each time they leave a field or change a value. I think, though, that intuitive design and careful language will prevent any confusion and (hopefully) provide the user with a positive experience.

11. On 13 June 2005 at 7:14 PM veen wrote:

John Dowdell:
"But even classic desktop apps from the 90s had to deal with these same issues, right...?"

I think it's a bit different now. Interaction design for the web has to struggle with the page metaphor, whereas applications do not. For example, when I use a word processor, I don't intuitively think that clicking a toolbar button will cause me to navigate somewhere.

It's a strange place we're in -- designing interactivity into a document viewing medium. A lot of stuff that worked in hypertext no longer makes sense in web apps. And our understanding of traditional UI design may not make it over, either.

Thank god people like to share now. I don't know what I'd do if I couldn't steal. ;)

12. On 13 June 2005 at 10:10 PM Ahmad wrote:

I'd like to add to what you said in your last comment, veen, that there is still a lot of inconsistency in both the design of GUI elements and their behavior in web pages. This makes it really hard to spot subtle changes. Even if we get used to the fact that pages are now more alive, we wouldn't know where to look for changes or clues if they were subtle.

13. On 14 June 2005 at 2:59 PM Brett Lider wrote:

When designing AJAX applications where server-processing time is an issue, taking "responsiveness" into account in the UI is more important than in tradition web apps. Check out these notes on the core principles of communicating UI responsiveness, from a BayCHI meeting.

Note: I know travel websites commonly handle long delays with interstitials. The below links with get into a lot more detail and nuance.

Brief notes
http://everybreathdeathdefying.com/blog/archives/000012.html

Detailed notes
http://www.baychi.org/calendar/20031111/

14. On 15 June 2005 at 9:07 AM Matt at Urban Pug wrote:

I think a big thing here is not "how do we design good apps" -- because people have been designing good apps for a long time. That's not to say that there aren't bad apps out there, there are. I'm saying that good app design principles are out there, and many people use them.

I think the issue is that the world has a lot of web designers and coders who have either gotten used to the "luxury" of not having to worry about certain elements of design or have come up not having to worry about it, because *there wasn't much you could do* given the state of web-technology.

This is not to say that the ajax folk don't need to hear this message, they do. I just think that a lot of what we'll all eventually find is that a good app is a good app, using the same principles of "good appness" across multiple platforms.

15. On 15 June 2005 at 11:08 AM Patrick Corcoran wrote:

I blame some of this on less than brilliant UI by the browser makers themselves.

Normal HTTP transactions are not inherently any more intuitive or comfortable than Ajax transactions. To compensate for this, the browser makers gave us throbbers in the top-right corner of the application, and also a progress meter, usually in the lower-right corner of the browser. Without these elements for feedback, we would be just as lost, not knowing what's going on with normal HTTP.

Enter Ajax, and for some reason the browser makers have decided not to reuse these simple queues for telling the user something is going on. Not sure why they chose to do it this way, but I'd really prefer being told when there is network traffic to and from my browser. (And without needing a separate app like the networking monitor of the task manager, for example.)

This feedback wouldn't invalidate the need for a 37signals type of visual cue, but it would be a step in the right direction toward treating Ajax transactions like what they really are -- standard HTTP transactions.

16. On 15 June 2005 at 11:37 AM Patrick Corcoran wrote:

I am of the opinion that the 37signals approach to visual cues is not always appropriate in web design.

I spend a lot of my time developing complex, rich UI applications for the corporate intranet. If we were to use the yellow-fade-to-white approach every time an Ajax transaction completed, the user would find the experience incredibly annoying.

With web design, as with traditional software design, usability is not the only factor to consider. There is also the issue of "learnability", for lack of a better term. Something which is easy to use may be difficult to learn, and something which is easy to learn may be difficult to use.

My challenge is to build rich web UI that is both learnable and usable. In general, once a user has learned that their explorer-model master-detail interaction pattern UI will be updated via Ajax on each click, they don't need to be reminded of this fact with every single transaction. So yellow-fade-to-white, while potentially solving a learnability problem, is also adding a usability annoyance in the case where the Ajax transaction is not a brand new thing on a first visit to a new web site, but a standard interaction with a very familiar software interface.

Appropriate consistency vs. foolish consistency, that's the battle. :)

17. On 16 June 2005 at 7:07 AM Bruce wrote:

I have to laugh at all the whining about so-called "browser makers" who haven't stepped in to provide adequate visual feedback about Ajax requests. how about some perspective? 90% of the browser market is owned by a company who haven't even gotten around to proper CSS support or transparent PNGs.

18. On 16 June 2005 at 8:01 AM Mike Stenhouse wrote:

I recently popped out an article trying to tackle some AJAX usability issues - the back button and bookmarking.

Fixing the Back Button and Enabling Bookmarking for AJAX Apps
http://www.contentwithstyle.co.uk/Articles/38/fixing-the-back-button-and-enabling-bookmarking-for-ajax-apps

There's also an interesting rant from Marcus Baker on AJAX usability:

Listen kids, AJAX is not cool
http://www.lastcraft.com/blog/index.php?p=19

Without serious thought to how we signal this shift in process to users, we are going to create all sorts of problems...

19. On 17 June 2005 at 10:09 PM Jesse McCarthy wrote:

Interesting topic. This brings to mind a Macromedia article on their HALO experience model for Flex. In fact, the concepts you credit to Bill Scott sound very reminiscent of what Macromedia talks about in this article from over a year ago.

Considering that Ajax is about achieving the same kind of functionality as Flex, if the concepts in the article are worthwhile (and judging by the slick, intuitive feel of the Flex demos, I tend to think they are), it seems like they'd be equally relevant to Ajax development (to the extent that it can achieve the suggested behaviors).

http://www.macromedia.com/devnet/flex/articles/halo.html

Highlights:

"HALO . . . provides a consistent set of visual cues, interaction patterns, and application navigation conventions for developers of Rich Internet Applications."

One of the design principles they suggest employing:
"Visual continuity: Filmic transitions preserve the continuity of the experience so users never feel or get lost. Help them develop a tactile feel for the effect caused by each action they make."

Hmm . . . "cinematic effects" sounds a lot like "filmic transitions".

"The feel is intended to be responsive; it gives immediate feedback so that, for example, all components light up slightly when your mouse rolls over them and light up even more when pressed."

"The default set of components have particular behavior embedded into them, such as the way . . . the accordion slides open smoothly."

"One example of a behavior built into Flex is drag and drop, which defines a transparent overlay of dragged images, a clear visual feedback for drop targets, and an effect that conveys the drop action"

20. On 18 June 2005 at 8:33 AM veen wrote:

Jesse McCarthy:
"concepts you credit to Bill Scott sound very reminiscent of what Macromedia talks about"

And the Macromedia stuff is almost identical to what my partner Tim was doing at Human Code 6 years ago, just like my partner Peter was doing at Voyager 10 years ago. They were copying what they saw in video games and film from 20 years ago. We're all standing on the shoulders of giants.

Looking through the Macromedia stuff, I'm so impressed! This is great stuff. Let's steal the techniques and put them into Ajax apps. Let's put our Ajax learning into Flex apps. Everything gets better.

21. On 18 June 2005 at 12:19 PM Jesse McCarthy wrote:

veen:
"Looking through the Macromedia stuff, I'm so impressed! This is great stuff."

You actually mean that, right?

"Let's steal the techniques and put them into Ajax apps."

Yes, let's; as appealing as Flex is, I don't want to be beholden to a $12,000 server to be able to do any RIA development.

22. On 19 June 2005 at 2:36 PM wrote:

Jesse McCarthy:

"You actually mean that, right?"

Absolutely. If you took Mike Sundermeyer's whitepaper apart and presented as a technology agnostic collection of interaction design patterns, it would stand up in value to most others. Same could be said of Apple's Human Interface Guidelines. Good design is good design.

I think Macromedia is well-positioned to develop conventions in interaction design, much as Apple did two decades ago with interface design. But again, it's only interesting when agnostic of technology. Saying they've got some great examples of web-based drag-and-drop has nothing to do with $12k servers. At al.

23. On 20 June 2005 at 6:01 AM Jesse McCarthy wrote:

"I think Macromedia is well-positioned to develop conventions in interaction design, much as Apple did two decades ago with interface design. But again, it's only interesting when agnostic of technology. Saying they've got some great examples of web-based drag-and-drop has nothing to do with $12k servers. At al."

You're right, you can skip the $12k Flex server and use another Flash based solution.

I'm not sure I see how those conventions _could be_ technology dependent (e.g. Flash) unless there's no alternative technology (e.g. Ajax) that can actualize them. Rico and other projects demonstrate the exciting potential for RIA development with Ajax, but let's face it, Ajax can't yet rival the UI sophistication that can be achieved with Flash based solutions today.

You seem to agree that the Macromedia article is an example of what you're looking for -- it's agnostic of technology to the degree that you can implement those conventions with Ajax or any other platform.

24. On 27 June 2005 at 6:20 AM nader wrote:

there's a cool live-search javascript on http://www.bandnews.org - no loading-sign but actually not needed as it is pretty fast

25. On 27 June 2005 at 6:56 AM nader wrote:

there's a cool live-search javascript on http://www.bandnews.org - no loading-sign but actually not needed as it is pretty fast