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 subconciously 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.
Ajax Mistakes: This resource is so, so necessary. As I've ranted about before, Ajax has the potential to introduce a massive new dimension of UI problems into the Web. Ajax is also a dangerous technology for web developers, its power introduces a huge amount of UI problems as…
Ajax-ified Weblog: This is a neat example of Ajax-ifying Movable Type comments. if you try to submit a comment now, the form fields will go "dark", and you'll see a progress bar as your info is sent to the server. When the server gets the data and processes it, it sends…
ajax: a new approach to web applications: Adaptive Path sticks a name on the current crop of XMLHttpRequest-enabled apps. An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a…
I read Joel Spolsky's book over the weekend: "User Interface Design for Programmers." This is an excellent guide to usability — for client apps and for Web development. The strength of the book is that it doesn't start by presenting many hard-and-fast rules, but instead concetrates on general concepts that…
I think you may have a point to some extent. However, I think that like anything new, it will take some time to get used to it, and it will take some restraint on the part of developers.
In your example of an address book, I can certainly see the problem. However, there are several ways I'm sure that you could adjust the design so that it is clear how to search for a new address.
As for TaDa lists, I think it's great. Sure it is startling at first, but that is really the draw for that product. Instant feedback. As a bonus, the list items on TaDa can be unchecked also if you change your mind.
While perhaps not easy, the solution is simple: Allow the user to select the functionality.
"Do you wish to be prompted to confirm your choices?"
Again, it's a pain from the programming side ... but we're talking about the human-machine interface, no?
"Allow the user to select the functionality."
In that direction lies the path to madness.
While this sounds like a nice idea, it's essentially a way of punting and placing the design problem in the users' laps. With Ta-da lists, 37S looked at the options, made a decision, and implemented it. That's the way Ta-Da lists works. The first time a user makes a list, they may make the mistake of looking for the save button, but after that, they'll get a feel for how it works, and there's really no penalty for messing up. I'll disagree with Deane on this one and say that they made the right decision on that.
If you add an option for it, though, you've essentially asked the user to solve the problem for themselves, when all they really want to do is make a list. That's how my install of the Konqueror web browser wound up with around 50 full pages of settings full of options like "Use entropy file". The designers punted to the user instead of making a choice. Do I need an entropy file? What is an entropy file? It's not checked, so I guess I'm OK without it.
"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."
The feedback has been overwhelmingly positive. In fact, we haven't had a single email complaint about how Ta-da works. Nothing but praise, actually. Here's some feedback: http://jf.tadalist.com/lists/public/1005
People get it because it works and there's no penalty for experimenting. People can play with it and figure it out without fear or losing their data or making a mistake. Check something off and then uncheck it and you'll grok the behavior instantly.
Silly me, thinking choice was a good idea.
Make a decision; make that the default. Bury, if you want to, the 'advanced' settings. Have a 'Reset to default' button.
Or not, your choice. No ... wait ... :-)
The idea of a middle asynchronous tier on the client (the 'Ajax' model), is 'A' solution that can be used for a design problem.
Like any other solution, it has its strengths and its weaknesses. Determining if it is the proper solution requires the developer to analyze the problem and determine if it will satisfy the users. In the case of tada list:
‘it works and there's no penalty for experimenting'
The problem lends itself to the solution, and I applaud the developers. In many other cases, the pattern is not applicable because of the penalty the user will incur during the learning curve. The use of asynch processing on the client has many applications, but it is not a catch-all.
It is the responsibility of the engineer to determine if the technology is applicable. Simple guidelines, and best practices will begin to develop to guide us in when to use the Ajax pattern of design, and when not to.
Hi all! Great site! G'night
