Although it's an extreme example, TDWTF's latest post shows an interesting concept: purposefully pausing an app to show a progress bar, to convince users that it's doing something.

This kind of thing came up before in an answer I gave - I suggested that a spinner be shown even if saving is instantaneous.

Obviously you don't want to slow down access to your app, but in small quantities, can this improve people's perception of your app?

  • 1
    Google effectively shows an app going fro "saving" to "saved" basically instantly just by switching the Save button to a disabled "Saved" button. I think there are always better ways than showing a fake loading bar.
    – Zelda
    Commented Jul 30, 2012 at 15:46

2 Answers 2


The idea that you should show users your app is responsive is spot on, but I don't think arbitrarily slowing your application down is the way to do it. Instead, I would use success notifications, and make sure buttons have hover and active states (depression on mousebutton), to help communicate that my app is responsive and that the user's action has a reaction in the service.

For things like save buttons, the simplest way to do this is to have the save button transform into 'Saved!' after the action completes. Users have focus on the area, so they'll spot the change even if it's quite minor. You can then revert the save button's state once the user starts modifying content.


I had an issue once, where the users didn't notice that the change they requested has already happened. It was a registration form, and they just kept pressing the button, without realizing that it's been done already.

It didn't matter if it was blinking up once, they were occupied by pressing the button, concentrating on that one, despite being the change next to the button.

Our solution was to put a 250msec delay in that, thereby rising the response time above the 120-200msec cognitive barrier, and framing it as a reaction. Worked.

Personally I hate loading indicators that show up only for a fraction of a second, as all they cause is flickering - if it's below 120 msec, the user doesn't even notice, and it takes about 300 msec just to realize "what the f..." can that thing be.

Therefore, when I expect the results to come nearly immediately, but there's a risk that it'll take more time, I put a timer for the load indicator to about half a second. If the answer comes before that, it's instantaneous, if it doesn't, they still get a quick feedback.

  • Related to the timer idea, if you start showing "Loading" after 200ms and a file takes 240ms to load, keeping the message on screen for an extra 110ms might not be a bad idea if its continued presence would not delay the display of the newly-fetched data [it doesn't have to be shown long enough to ensure that the user can read it--just long enough to be seen as a real message rather than a subliminal flash].
    – supercat
    Commented Jun 11, 2014 at 18:36

Your Answer

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

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