9

All over my CMS I have buttons that toggle something on or off by sending an ajax request, updating the db, and then changes state and value of the button on success. Very basic "ajax" and "toggle". It could be anything: publishing an article, deactivating a user, or closing a poll.

The actual server response time is pretty fast, but not instant. At first I showed a progress indicator inside the button, but it can give a laggy feel when you click one and want to move on to another, so I sped up the response by immediately changing to the other toggle state, and deactivating the button for the short time while the request is pending. If the request failed (which it never should), I change the button to an error state and disable it completely. I'm not concerned with the "in-between" time, because typically the button will be clicked once, not repeatedly.

This makes a huge positive difference in how the interface feels, but I have some concerns:

  • If for some reason there is an error, it might not be seen by someone moving really quickly through the control panel.
  • What happens if the user goes to a new page during that 0.5 seconds while the request is pending, will it be aborted?
  • Is this a really bad idea, and should I always wait for the server response?
  • What else I can to to improve the feel and/or speed up the perceived response time?
Improve this question
1

3 Answers 3

Reset to default
8
  • If for some reason there is an error, it might not be seen by someone moving really quickly through the control panel.

To solve that, use frames in your website, so that there is a constant parent frame and 'top bar'. That can be a place for a loss-of-communication indicator. AJAX to the server can be made to go via that parent frame. This combination can handle rapid page changes within your site and notify of a problems from a child page that has just been left.

Catch the page unload() event on the parent to warn of pending unconfirmed changes when navigating away from your site.

A visible top bar for the communication failure message to be tied to is not essential. Use whatever style of notification you like with this technique. You can pop-up a message over whatever page of yours you are on, if you want.

  • What happens if the user goes to a new page during that 0.5 seconds while the request is pending, will it be aborted?

The AJAX request happens in the parent frame. It is not a problem.

  • Is this a really bad idea?

It is a good idea. A very good idea. Users like responsive pages. GMail changes state well ahead of confirmation from the server. Google have also put a message in a fixed position on the screen showing what is going on. To me it looks like a left over from some developer's debugging, but I like that.

  • Should I always wait for the server response?

You do not need to wait, but you do need to be careful about dependent actions. If some of the earlier incomplete actions would change the options available, based on content from the server that you cannot predict, you at that point have to tell the user that they need to wait on the server.

  • What else I can to to improve the feel and/or speed up the perceived response time?

A story goes that software engineers were asked to improve the scheduling algorithm for some lifts to improve the perceived waiting time. They made no progress, until someone had the bright idea of having mirrors near the lifts. People spent time preening themselves whilst waiting for the lifts, and felt the lifts were arriving much faster.

The advice that seems to derives from this is to give the user something useful to do whilst they are waiting. For example, use progressive disclosure, a data-dependent revealing of instructions.

If you have a very laggy server, a way to cheat is to animate some transitions to give yourself more time for the communication with the server to happen. It doesn't sound a good fit for your site as you have a responsive server and users who are going to be using the interface heavily. The novelty will wear thin quickly.

Improve this answer
3
  • I definitely like the unload() idea in this case. As I said, the response time is pretty fast (also due to the simplicity of the operation). 99.9% of the time users simply won't be able to move that quickly, so the obnoxious prompt will almost never show. Frames are out of the question (personal distaste). Initially I had a small fixed popup with the response message, but they were a bit tacky - too many notifications (or my poor implementation). Continued->
    – Wesley Murch
    Apr 8, 2011 at 23:11
  • 1
    I think something along the lines of storing the error in the session and giving a return route to fix it via mentioned popup notice (If they are somewhere else) might be what I do, you've given me some ideas. Note taken on dependent actions - luckily it's not too relevant in my case. Thanks a lot, this is pretty much exactly what I wanted to hear.
    – Wesley Murch
    Apr 8, 2011 at 23:13
  • Possibly of interest - Zero height frames can sometimes be useful to hold javascript without actually showing any frames to the user.
    – James Crook
    Apr 9, 2011 at 10:57
2

I would take this approach:

  • Show the state change immediately

  • While the request is pending on the server, display some type of progress indicator (without making it too distracting -- a small spinning disk, maybe)

  • Once the request completes successfully, turn off the progress indicator

  • If the request fails (rejected by the server or timed out), roll back the state and show a pop-up error message

Improve this answer
1
  • That's what I was doing before that made it feel laggy (but without the immediate state change), I will update my post with that information as well. I think showing the new toggle state and indicator at the same time will be confusing.
    – Wesley Murch
    Apr 8, 2011 at 22:00
2

It may feel fast to you, but will it feel fast to that person that's in Jamaica on vacation when her editor calls her and insists she updates the press release on the home page and she's sitting there with her iphone on a 2 bar connection? ;)

My point being that there's a gigantic variable you have no control over: the network. So probably safe to do the typical 'show processing while waiting for a response, THEN update with success or fail.'

Improve this answer
1
  • That's a good point, but I think they will have a pretty horrible time with the rest of the CMS on a bad connection in the first place, and if so - it will be pretty much unusable (or painfully slow) to begin with. This is definitely relevant, and I will take it under consideration while searching for a better solution, thanks a lot.
    – Wesley Murch
    Apr 8, 2011 at 22:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.