Will Ajax Hurt Usability?

By Deane Barker on March 29, 2005

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.

Gadgetopia
What Links Here

Comments

  1. 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.

  2. 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?

  3. “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.

  4. “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.

  5. 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 … :-)

  6. 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.

  7. This is an excellent article. I’ve carried out usability testing on quite a few sites that used AJAX. Every time I did so, the development team had gone a little too far with AJAX. Brent is right when he says it requires restraint. But its difficult to know when your restraint actually means binning a good idea.

    What surprises me most in this respect is the gap in understanding between people in their late teens, early twenties and older users (I don’t mean silver surfers).

    I would always recommend usability testing but more so with AJAX and Flex based sites. The key is to test on prototypes because it can become complicated to fix otherwise.

  8. I am not at all opposed to being a fly on your wall.

    Yeah yeah, Web 2.0 4.0 8.0 is mucho-spiffy. Ajax is teh shiz-nizzle. Here is the philosophy I have come to respect when it comes to implementing ANY client-side processing, especially as it might apply to stateless internet protocols like HTTP.

    First, client-side processing is cool. Useful for catching the eye of your user, and for simplifying and gratifying your user experience. Second, client-side processing is annoying, dangerous, and error-prone. This is because one cannot guarantee what client-side functionality will execute, or execute correctly (yawn). Annoying, because some user out there is clicking a check-box on your “Ta Da List”, and nothing is happening. And there’s no submit button to make something happen. And there’s maybe even some cryptic box that keeps popping up saying “error on page”… Dangerous, because some retarded web designer thought it would be sufficient to protect against, say, SQL-injection attack by, say, verifying form submission with a client-side “onclick” event. And error-prone for oh-so-many tired reasons.

    That said, there’s no reason NOT to tinker away on spiffy new functionality that’ll astonish and amaze your users and friends. I’d never think of advocating AGAINST any free and public technology like Ajax, just because it might not be universally established and un-conditionally functional. That would be like advocating against a given character set, or language even. Instead, I would encourage you all to continually put functionality ahead of form. Don’t make your entire web site, with all it’s useful features and content, depend upon Ajax. My bank has dabbled in Web 2.0 and I wouldn’t complain, but it looks downright cheap to see un-supported and un-runable code in a web page viewed from my mobile phone (not that I should be banking from my phone – nor would I, since it doesn’t work).

    The last point I would like to make regarding Ajax and other Web x.0 technologies is this: embrace with extreme prejudice. What goliath corporation wouldn’t love to make market share of countless independent web development projects? Think Sun, think Macromedia, think Adobe, think Oracle, think Microsoft. Exactly what spiffy web 2.0 project are you working on now which doesn’t amount to revenue for some bloated non-contributor who, rather than exploring and developing along with you, would force you to demand that your users download yet another plug-in, widget, utility, application, API, development kit, virtual machine, or other such nonsense?

    I am a proponent of client-side processing, but only to the extent that I can anticipate, control, and accomodate errors in the client-side processing. And if I can’t control some aspect of my overall application functionality which happens to run client-side, I insist that the overall application functionality does not depend upon the correct implementation of said client-side code.

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.