On adding fake delay, to, network delays

Question

Consider an app, where there's a function (perhaps a button, or, when you hit return to send some text, for example).

It results in a network connection, and there will be a small delay while the connectivity happens.

During the delay there will be a spinner (or some other indicator) showing that the network connection "is happening"...

... indeed that indicator shows you that something "actually happened".

Now regarding that spinner appearing during the network connection: these days it is often pretty much instantaneous, you barely see the spinner or perhaps don't even see it.

Thought: in fact deliberately make a minimum time for the spinner to appear (say, 1/3 second). That is to say, even if the connection is near-instantaneous, add a "fake delay" (perhaps 1/3 second).

In this way, as it says above, the user definitively knows something happened.

Good idea? Bad idea? Already in use?

• drastically simplified the question here

Answer 1

My 2 Cents:
From a developer Point-of-view it is "plain stupid",
But as a business decision, it is "Genius!".

Consider this hypothetical situation:
You go to a fortune teller,
Ask: "when will i die?"
It instantly answers: "5th, June 2049"
No crystal ball, no humming, anything...
? what would you think ?

Example of an instance of intentional delay:
I know one commercial product (which I written) which introduced fake delay, even as long as 5[sec]. and i will explain:

The product I was writing came as an Engineering Tool built as an add-on for a well-known diagramming software used widely across the industry,
But it was vast and added much functionality that is "could" live on it's own...

when you start the add-on, you barely could see you are out of diagramming software and into my product: The design was following the same schema & the loading time was somewhat instantaneous.

Our team wanted to make sure the user knows where is "our contribution" to his work, and not the "parent" software!

So... We introduced "The Splash Screen":
Which was nice, containing the Name of the product, the company name and the product version.
But... The Splash-Screen was popping very briefly, so we introduced a delay on the Splash-Screen, a perfect progress-bar, and later on, some tips on using the tool.

Note on your implementation:
Either way, I suggest that you first execute the operation, and only then (if needed) introduce the delay... and not vice-versa, further more, if the operation fails, give the delay up and let the user know right away.

Note2:
Instead of a Modal Note stating "operation was completed successfully! [OK]".
you can use a alert-frame like G-Mail's "email sent successfully! [X - dismiss]".

But of course, every case has it's own considerations.

Answer 2

1. Have you seen this in any production apps? (That is to say, I guess you'd have been on the development team - as you wouldn't necessarily know about it, I guess, as a user!)

   Yes, I think most of us have probably also done this because they like to see their clever little loader... but then move on. A loader should IMO only be used when something takes longer than anticipated. Say that after 300ms, no response has been noted, than one should show the spinner.

2. Has this been previously addressed in the literature? (I couldn't find anything.) Does it already have a cool name?

   I don't assume anyone has given an official name to doing that, however, what has been talked about is that the user needs feedback of his action. It is a heuristic for usability. However, there are better ways to tell the user what is is the actual status of the system. For your business transaction, I'd simply remove the button and put a label displaying 'transaction accepted'...or something, perhaps even gray it out...anyway, just don't leave the button as is. I once had the same issue regarding a configuration page, when one clicks the button, nothing happened... so I simply enabled to button as soon something had changed in the settings form and after the button was pressed I simply disabled the button again.

   The most basic form of feedback is ofcourse the different button states itself:

   • on press: change color (e.g. blue)
   • on release: change color back to regular color (e.g. gray)
   • on hover: change color to something in between (e.g. light-blue)

3. Failing that, and most importantly, what is the opinion of y'all folks here?

   ...I don't really like opinions as much as fact, however, it seems bad practice to just do this. If you really want a user to actually wait and don't go anywhere else, you're best to simply overlay the entire screen and put a big spinner there untill the this blocking step is over...however, if the transaction is almost instant (e.g. <300ms)...don't do it, you'll annoy and confuse more than you help your case.

Answer 3

There is lots of evidence of interactions to give feedback to users. Just like every time you minimise a window on your PC etc...they're all animations that describe the action taking place but they aren't necessary from a computing perspective. One alternative to forcing a spinner in an unnecessary situation is to have a 'success' message appear so that users know that the performed action was completed. You can have this set to disappear after a few seconds or have the option for users to close it.

One note of caution: be careful when you start making assumption about what you can and can't lie to users about e.g. UBER recently being caught out for having fake cars on its maps. There's a really great publication about deception in interaction design recently publish that you can see here: http://www.cond.org/benevolent.html (there's a little link to the pdf of the page)

Answer 4

Good idea, indeed.

The whole idea of a Spinner is to have the user know, there's something happening in the background so they will need to wait until it's done.

Especially in the case of a network connection, Spinners have been required since the reception of the network as well as the speed cannot be determined and is subject to change. Networks also have downtime.

However, the problem with spinners are that, developers generally place one in the center of the screen in the foreground and fade the content on the screen itself. This is counter productive if the user would want to edit anything in between, and the network is slow.

A good way to do it is to allow the spinner to be on the Right side of the button you just pressed, smaller size than the button and it begins spinning while the button remains faded, to avoid duplicate data transfer.

If the network connection is successful and data is transferred + operation is performed, the spinner animates into a Check.

Else, into a cross.

This way, it becomes easier to know when the operation was successful and when it was not also eliminating duplicates.

Answer 5

In my opinion, as soon as user does some action he expects a response. That is, the app informing him that his action has been processed. A loading image for 3-4 seconds will give user a clear idea that his input has been received and worked upon. Now if user connection is super fast and loading spinner comes on the screen for half a second and then dis-appear. It will cause a flickering, which will be distracting(or say disturbing) than informative. But at the same time, the app need to notify the user his action has been worked upon. In order to do that app needs to give him visual indications, something like moving to next form in sliding effect. Another could be inputs/buttons user took action on could smoothing fade away and data is presented to user. These visual indications should be more intuitive than simply showing/hiding loading gif for 0.2 second which user eyes can't identify.

Answer 6

Spinner, loading bars, or other such design patterns are used to provide feedback to the user when a system cannot respond fast enough to provide the necessary feedback to the user's action. If the system can respond fast enough, then that would provide the necessary feedback and you do not need a spinner. In this case, there is no reason to cause a purposeful delay in the completion of user's tasks simply for the sake of causing delay in the completion of a user's tasks.

Answer 7

I don't like loading indicators. User may assume something is broken.

However, many times, if the user is informed, he may be more patient.

I think it is a good idea to give users something to do, to read in this time. Most sites took this waiting time to highlight something.

Answer 8

So, I bring up the spinner, and simply wait, oh, 0.6, 0.65, say, and only then actually call1 for the connection - which indeed then typically takes almost no time.

What is the point of this? You don't even mention any reason at all (unless I missed it), which makes me assume you do this because the connection call can be very fast.

Unlike the coinstar example linked above, 99.99% of your users will not have strong opinions on how fast database connections should take (even moreso when they don't even know where the servers are). So, your artificial delay adds nothing other than more time for your user to develop feelings of annoyance at having to wait.

So, do what you need to do to show that something is happening that is so important, it disallows other actions. Dim the background, put in an animated .gif or whatever -- but don't extend it beyond the amount of time it takes.

If you were using a service, especially one you had to use FREQUENTLY, what would you be more annoyed at:

• Having to wait .8 seconds every time you restarted the app but getting to see a nice animation,

or:

• Having to wait .2 seconds every time you restarted the app and seeing only a glimpse of an animation

To me, this question feels so obvious (not to be rude!!), that I feel as though I am missing a big piece of information as to why you are considering your current route.

Further reading: http://www.nngroup.com/articles/progress-indicators/

Answer 9

The idea behind a spinner, progress bar, etc. is to add the spinning element to your execution thread so when the operation starts the spinner shows up and when it ends, the spinner goes away. The way you are doing it seems to be wrong because you are not tying your spinner to the action itself and as result are adding an unnecessary delay to it.

That said, this has to do more with implementation rather than UX.