Tuesday, May 24th, 2005

Ajax Usability Mistakes

Category: Ajax, Usability

Alex Bosworth has written up 10 usability mistakes that he thinks Ajax developers make. Fortunately, these are not intrinsic to the Ajax platform so we can work around them.

  • Not giving immediate visual cues for clicking widgets:
    There are many patterns emerging here, such as showing the Firefox/Apple spinning wheel next to widgets, when work is being done.
  • Breaking the back button:
    Toolkits such as Dojo make it easy to handle forward and back.
  • Changing state with links (GET requests):
    With JS you can make links do POST, so I would argue that you can do the right thing better.
  • Blinking and changing parts of the page unexpectedly:
    Sure. Don’t. :)
  • Not using links I can pass to friends or bookmark:
    You can change the URL for various actions. This bugs me too (e.g. I want to have a direct URL to a GMail message).
  • Too much code makes the browser slow:
    I guess.
  • Inventing new UI conventions:
    Always a problem.
  • Not cascading local changes to other parts of the page:
  • Asynchronously performing batch operations
  • Scrolling the page and making me lose my place:
    This is where it would be nice if the browser was a LITTLE bit smarter and could do some more for us.

Posted by Dion Almaer at 9:43 am

3.5 rating from 15 votes


Comments feed

I could be misunderstanding your 3rd point, but it’s generally considered good usability to have data loads be done with a get request. This allows a user to bookmark that view of the data. Simple example; Amazon.com use’s a get request to load data on a book that you wish to view. This let’s you bookmark that page or send the link to a friend without the need of an additional ‘bookmark this’/’link to this’ link.

Comment by Ryan — May 24, 2005

Edit: That would be Alex’s 3rd point, not yours :-)

Comment by Ryan — May 24, 2005

If I understand correctly, Alex’s 3rd point addresses so-called ‘idempotent’ actions, such as using a GET request to perform a potentially dangerous action. Creating, editing or even deleting an item using a GET request could be considered dangerous.

For example, Basecamp [http://www.basecamphq.com] uses GET requests to perform delete actions. If a GET request were able to be reproduced elsewhere, it could be used maliciously to spoof security and do something nasty.

POST requests can be reproduced as well, but with proper security measures in place, spoofing a POST request is much more difficult.

Comment by Brett — May 24, 2005

Also, could you imagine a security hole allowing a search engine spider to follow all of your GET-based delete actions? It’s happened before. Ouch.

Comment by Brett — May 24, 2005

One usability issue which I think may trump any of the above is to include some type of support materials for any browser-dependent site — to tell people in which browser brand/version/platform combos the JavaScript was tested, and what visitors should do if they don’t see what the developer saw.

(The “breaking the ‘back’ button” line is regularly used, but I haven’t seen anyone yet propose a clear specification of the ideal browser behavior here. When *should* that browser button change from “go back to the previous document” to “stay on the current document but go back to some previous state”?)


Comment by John Dowdell — May 24, 2005

[…] This is the number 1 item on Alex Bosworths Ajax Mistakes list, and is expanded on somewhat over at Ajaxian.com and here at Alex Bosworths Backpack. […]

Pingback by be eXtreme weblog » Blog Archive » The hunt for Ajax processing icons — February 20, 2006

Leave a comment

You must be logged in to post a comment.