I’m curious what effect Ajax will have on usability. With this technique, the unspoken nature of Web apps is changing, and apps using Ajax will likely do things that users don’t expect.
When I first starting using client-side HTTP requests back in 1999 (long before the snazzy name), I did it really badly. I wrote an intranet phone directory which used background HTTP calls from the browser to retrieve the data and load it into a DIV on the interface without re-loading the page. It worked great, but if the users wanted to find another phone number, they always pressed the “Back” button…and got sent backwards, out of the phone lookup system.
Web users have a “user model” of how forms work (we discussed user models in this post). Web users are accustomed to the fact that nothing happens on a form until they hit a button called “Submit” or “Save,” and that this gives them a new page, so they can usually hit “Back” to get back to their form input. I broke this user model, and the user paid the price.
With Ajax, it’s easy to break the model of stateless request and response that users are subconsciously aware of. You shouldn’t do this lightly or you’re going to get some confused users.
Here’s a current example:
37 Signals' great Ta Da Lists use Ajax to “check off” items in a list. If you click the box next to an item, it’s immediately removed from the list in the interface and a request is dispatched in the background to change the item’s status on the server.
I understand this and it’s quite slick, but what about people who don’t spend as much time with this stuff as I do? I know a lot of people that look at a list of checkboxes and think, “I can check a bunch of boxes, then review my selections before finding and clicking a button called ‘Submit’ that’s got to be around here somewhere.”
This is the user model that a lot of people have for Web forms. They get to do whatever they want, and nothing counts until they press “Submit.” I like Ta Da Lists, but I think 37 Signals made a mistake here. I’d be curious what feedback they’ve gotten about it.
Where we’re going with Ajax is to allow developers to really mess with the unspoken “rules” that users have gotten used to. Ajax is great and provides a revolutionary way to do things, but I know some people will take it too far, too fast. User confusion won’t be far behind.