Monday, February 20th, 2006

Beware the toggle in Ajax Applications

Category: Ajax, Editorial, Usability

Ajax applications are different yet the same. I had an interesting observation the other day about long lived web applications. They live on a tab in Firefox that I open when I start it up, and they tend to sit there all the time. One tab would be Ajaxian itself, and others would be project management tabs and other web services that I use.

Let’s take the project management tab, which shows data that many users have access to and can add/change/remove.

By default, my browser isn’t going to poll the page(s) that I am on and update itself based on what other people are doing, so I can easily have stale data at some point. In a non-Ajax web app, I am aware of that and hit Refresh a lot to sync up.

In an Ajax app, I have this sense that the page is more alive. Also, instead of doing a browser refresh, the use case of syncing up happens differently between the applications:


  • I add some new info to the page I am on.
  • I submit that info.
  • The page totally redraws and I may be shown new updates made.
  • Or, I may be told I can’t make that change due to collisions.


  • I add some new info to the page I am on.
  • I submit that info.
  • The page adds a node INTO the stale info. At this point I can easily have the wrong representation of the data.

This becomes funny if you have toggling of items. We have a joint TODO list, and when we both get the initial page it needs to be done. You go ahead and complete it and toggle it done. I don’t see this and look to do it too and I toggle it done myself. What is the state? not-done again as it has been toggled twice.

Of course, there are simple solutions to help with these scenarios:

  • Favour stating the action versus toggle (e.g. completeTask vs. toggleTask)
  • Have the Ajax application not only send the action up to the server, but have the return arguments the new data and redraw that pane to reflect the correct state
  • Consider if it makes sense to have events sent back to the browsers when state changes, so they are constantly kept in sync, or if it doesn’t matter
  • Think about your long-time users, and how they may use the system!

Posted by Dion Almaer at 10:14 am

3.6 rating from 37 votes


Comments feed TrackBack URI

This is a problem that exists in many traditional client/server applications (non-web). I’ve seen the following:

1. Use must go into ‘edit’ mode.
2. Optimistic locking is used to determine if the user was looking at stale data when she made the update.

If you use (2) then when an error occurs the page state can be refreshed with the correct data and the user can be notified.

Of course, with a todo list you might go ahead and to the todo before updating it. In that case you did something that didn’t need to be done and maybe you would want polling in that case. Either that or users will eventually get used to refreshing the data before starting the task

Comment by Dave Tauzell — February 20, 2006

Funny, exactly this problem happened the last days in Basecamp. I finished an item, and a collegue also marked it as finished. Result: Reopened item. So this is a real problem and it should be solved as explained in this good article.

Comment by Dirk — February 21, 2006

Good information, but this is really just common sense, isn’t it? If people really code this way, perhaps they should find a new job.

Comment by Ray — February 21, 2006

Beware the Toggle!

A short note from Ajaxian about being aware of how your users interact with their data on the web, avoiding conflicts with stale data, and some possible cures.  A common pitfall of multi-user systems.Ajaxian » Beware the toggle in Ajax ApplicationsT

Trackback by AJAXGallery.Net — February 21, 2006

Leave a comment

You must be logged in to post a comment.