5

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
  • 1
    My concern is that this delay seems to indicate that something is happening, but doesn't in and of itself indicate if it did it successfully. The latter seems much more important. – DA01 Aug 19 '15 at 16:56
  • 4
    Helpful article: 90percentofeverything.com/2010/12/16/… – DasBeasto Aug 19 '15 at 17:05
  • Das --- FANTASTIC ARTICLE LINK! thanks!! totally awesome. – Fattie Aug 19 '15 at 21:41
  • "but doesn't in and of itself indicate if it did it successfully.." Hi DA .. I think these days one just "assumes success". By all means, you're right, for an "even more important process" ("you just purchased the house") one would, exceptionally, indicate success. But these days apps "just do things". If you add a post or a comment it just does it, there's no particular message like in the old days. – Fattie Aug 20 '15 at 12:30
  • 1
    See this prior post on a too-fast progress bar. – Ken Mohnkern Sep 1 '15 at 14:32
3
+50

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.

  • fascinating case ! – Fattie Sep 1 '15 at 11:07
  • I think you have perfectly explained the situation, in a crisp way. that's just what I mean. You've just made me realise that "splash" screens are indeed an example of this. On iOS these days, there are very few cases where you actually need a loading screen (ie: apps just load instantly, other than a few enormous games). HOWEVER, I suppose exactly analogously to what I propose here, clients often have you put in a "fake" loading screen that "loads" for say 2 seconds, just because -- it looks cool, traditional, or whatever. – Fattie Sep 1 '15 at 12:10
  • yea, the rule of thumb in UX is to behave "as expected" – Tomer W Sep 1 '15 at 12:50
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.

  • Interesting considered comments, thanks. "For your business transaction, I'd simply remove the button and put a label displaying 'transaction accepted'"..hmm, I can't think of many cases where that applies these days. If you have a menu, and you do something, it all goes away. Typically you go to a new screen. In all "stateless" interfaces (common example .. you add a post to a feed), of course there's "no nothing", no button (buttons are an ancient idea), no function, nothing, it just moves to some new "shape". So, I'm not sure if that helps in many modern cases you know? I'm not sure... – Fattie Aug 19 '15 at 18:53
  • "however, if the transaction is almost instant (e.g. <300ms)" (Why would anything take longer than that these days!? heh...) By all means, that's the raison' d'etre of what I'm talking about. Almost always today when there's a delay for a spinner ............. in fact there's no delay at all. – Fattie Aug 19 '15 at 18:54
  • Erm...I'm confused here...are you against your own question? There are definitly things that take longer then 300ms, just look at any mobile connection, which is unstable in nature or the uploading of a file... Anyway, you gave me the example of a business transaction... in a list where you can except a lot of things, its definitly a possible and viable solution. Like you say, if clicking a menu item (which isn't the example you gave), you should go to the page instead, after which the menu isn't relevant anymore. You may put a spinner in the region that's getting updated... – Xabre Aug 19 '15 at 19:01
  • ...but again, IMO, only show the spinner if the page takes longer than expected...due to connection instability or simply because the page needs to render something...or fetch something from another server ... or a large DB transaction. I bet you can think of enough cases yourself here ;-) – Xabre Aug 19 '15 at 19:02
  • Also, perhaps you could explain what you mean by "buttons are ancient anyway" ? – Xabre Aug 19 '15 at 19:04
2

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.

  • 1
    interesting suggestions about the sizes, positions etc. – Fattie Sep 4 '15 at 11:44
1

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)

  • fantastic point about Uber. I HATE the fake cars on their maps. great link. – Fattie Sep 1 '15 at 13:21
  • (a modal 'worked!' message with ... ) "have the option for users to close it" ... Chris, surely that is a very old fashioned and clunky idea. I guess, the very raison d'etre of this discussion is, a natty way to avoid just that. (Note that, as mentioned a few times, sure, in extremely "important" situations, you can bring up a old-fashioned "That Worked ... click 'OK' to confirm you have read this" modal dialog...) – Fattie Sep 3 '15 at 17:08
  • even Google inbox has notifications telling you an email was sent (for example) and that's a very modern web service. Confirmation doesn't have to be barbic and in your face, it can be subtle and it is pretty necessary in a lot of instances. I never used the word Modal and just because others have said that word in their answers doesn't mean that should be the interpretation of a notification in the context I was mentioning – Chris Sep 3 '15 at 17:23
  • for sure, you're right, I imagine you mean a message, icon, something, which appears somewhere on screen (perhaps at the top with the mess of menu bars, etc), for a limited period of time. Right, an actual old-fashioned modal dialog box, I imagine most people would agree it is, well, old-fashioned and way too much. So let's stick to the idea of a (let us say) "in-line" message of some sort which appears, perhaps for .5, somewhere. (No action needed by user.) It still seems to me that you are, anyway, showing a spinner. And the entire point of a spinner is – Fattie Sep 3 '15 at 17:37
  • ... is to indeed let the user know that a network connection has happened. So putting it all that way, isn't it a good idea to make a minimum time (perhaps .3) for the spinner to appear? (which is equivalent to saying, add a fake network delay - a minimum of .3, say).... thoughts? – Fattie Sep 3 '15 at 17:38
1

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.

  • Hmm, something shown on-screen for .5 sec, even down to about .1 sec, is not at all perceived as a "flicker". Indeed it's quite normal that "doing something spinners" appear for very short times, I mean around .2 sec. Essentially what I'm saying here is make a lower limit of (say) .3 (which is quite "long")... – Fattie Sep 3 '15 at 12:35
1

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.

  • "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". Not really. Most users interpret "spinner" as meaning "network connection". (There is nothing else, at all, which causes a computer delays these days.) Additionally I am talking of the specific case (but again, there are no others) when in fact the user is doing a function where they connect to the net (example, "thumb up", "open garage door on holiday house", or the like). – Fattie Sep 3 '15 at 21:27
  • I don't think there is any evidence that most users think that a spinner means "network connection". Where is your evidence for that statement? Also, I do not understand your examples in order to comment. – user70848 Sep 3 '15 at 21:31
1

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.

0

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/

  • 1
    he clearly states in the question that the delay is introduced in-order to emphasize the importance of the operation. from a developer POV it is "plain stupid", but as a business plan it is "Genius!". consider this hypothetical situation: You go to a fortune teller, and ask: "when will i die?", it instantly answers: "5th, June 2049", no crystal ball, no humming... what would you think? – Tomer W Sep 1 '15 at 10:52
  • Tomer has perfectly explained it... – Fattie Sep 1 '15 at 12:08
  • However, users typically care neither for the developer, nor for the business. – calum_b Sep 1 '15 at 19:41
  • @JoeBlow that explanation still really makes no sense. – HC_ Sep 1 '15 at 21:36
  • Hi HC - it's a very simple concept. If you make the spinner a minimum of say 1/3 second (even if the connection is incredibly faster than that), the user definitively knows it has done something. (In contrast, if no spinner appears at all, it may be you fluffed the button or it just did nothing.) – Fattie Sep 1 '15 at 21:48
0

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.

  • hi Noah - maybe my explanation was too long-winded. In short, I'm suggesting adding more spinner time, to let the user know, positively, that something has happened. If the spinner time is incredibly quick (as is typical these days), the user does not positively know something has happened. – Fattie Sep 1 '15 at 12:07
  • @JoeBlow From a UX point of view, that's simply bad design. When a user clicks on something he expects a result. Now if that result takes time, you add a progress bar to it. Otherwise theres no point in having a progress bar. – Noah Sep 2 '15 at 16:54
  • Hi Noah! Then, please state how to make it clear to the user, that, something has definitively happened, ie, that the network function worked. How would you do it? Let me know. – Fattie Sep 2 '15 at 17:50
  • @JoeBlow Messaging. If something goes wrong, you say "There was a problem to do x." Or when something succeeds "Connection established, etc." – Noah Sep 3 '15 at 11:56
  • hi Noah, you're recommending bringing up a model dialogue which says "That Worked. -ok-" ... ? It's just way, way too slow, it's like 20 years ago, you know? {By all means you'd do that for incredibly major functions - like a massive stock trade; you really can't do that any more for minor, common functions.} – Fattie Sep 3 '15 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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