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?
Answer
- 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.
No comments:
Post a Comment