34

Our WPF desktop application will be executing various tasks. In general, the average length of time for each task will range from basically instant to a few seconds or longer (possibly minutes).

We are trying to establish a standard to determine when to change the cursor to an hourglass to indicate processing and for longer tasks display a progress bar in the interface.

Where are these thresholds in seconds? At what point does a user think nothing is happening and start to become frustrated that no progress is reported (which is what we want to avoid)?

Improve this question
4
  • Related: Will forcing response time to the average time as a minimum improve UX?
    – Nicholas Pappas
    Commented Apr 30, 2015 at 20:24
  • While this OP may not have an option in this particular scenario, my own opinion is that in the bigger scheme of things, the better direction to explore in is whether the application can show something useful and relevant instead of going into a blocking mode, so that users can get on with their tasks and feel like they are continually making progress at their own pace rather than waiting around for things all the time.
    – Roger Attrill
    Commented May 1, 2015 at 8:26
  • 1
    It isn't the question you asked, but: please only change the cursor if you mean to indicate that the application will not respond to clicks while it is busy. It's a really good cue for that and misleading otherwise.
    – Kevin Reid
    Commented May 1, 2015 at 20:15
  • Just quickly, WPF?
    – Alec Teal
    Commented May 2, 2015 at 23:49

5 Answers 5

Reset to default
62

Remember 0.1, 1.0, and 10 seconds...

You have about 1 second to show something whether that be the finished result or an indicator that the computer is working (usually some type of spinner)

spinner

Not doing anything for 1 whole second after a user initiates an action can still make an application feel sluggish (as noted in the comments below) so I like to provide immediate feedback to my users by showing the spinner right away while fading it in slowly.

Demo of a spinner that fades in

Spinners only work for so long, however, and any operation that could take over 10 seconds should have a more advanced mechanism for letting the user know when the task they initiated will be completed (such as a progress bar)

progress bar

Here's the data backing this up...

The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]:

  • 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
  • 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
  • 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

source: Neilson Norman Group

Improve this answer
7
  • 2
    Disagree strongly with "1 second to show something". UX is bad if there's any perceptible delay, so I would put the limit at something like 16-33 ms (assuming perceived 'framerate' of 30-60 fps).
    – R.. GitHub STOP HELPING ICE
    Commented Apr 30, 2015 at 15:10
  • 7
    The idea that "UX is bad if there's any perceptible delay" is not really defensible position. Users perceive delay on a daily basis in just about anything they do, including those who's UX is just plain fine. There certainly is no research backing up the idea that "if it isn't instant, its to slow".
    – Nicholas Pappas
    Commented Apr 30, 2015 at 20:22
  • 9
    @EvilClosetMonkey: I don't know about research, but most non-computer interfaces do not have latency to observe an effect. Mechanical buttons/switches/keys move when you press them. Buttons on a microwave beep when pressed. Etc. Take on the other hand new TVs that have to boot - I've seen/used several where there is no indication that the power button press on the remote was acknowledged by the TV until 1-5 seconds later, and you end up turning them on and off trying to figure out if the remote is working or not. This should be common sense, not something that needs research.
    – R.. GitHub STOP HELPING ICE
    Commented Apr 30, 2015 at 23:05
  • 5
    @R 1-5 seconds is one thing, but to me it seems a little extreme to require < 50ms response times. I think I would press the power button only once if the TV showed some indication (e.g. A light) anytime under a second.
    – gandalf3
    Commented May 1, 2015 at 2:05
  • 7
    @R.. - you're mixing action feedback with progress feedback. Absolutely the initiation of an action should have immediate feedback (beep, light, state change, etc.), but progress of that action is different. As DaveAlger points out, one second has been found to be a suitable delay to indicate "I'm still working at what you asked me to do."
    – Nicholas Pappas
    Commented May 1, 2015 at 14:25
5

DaveAlger's answer seems to pretty much cover the question, but I would contend that if a process is wired up to display a progress bar, you might as well show it immediately in all cases.

An hourglass says "something is taking a long time when we didn't expect it to". A progress bar-- even the fake barber-pole kind-- says "this is taking a while, but we knew that could happen". If the progress bar disappears after half a second, then of course that's even better.

Improve this answer
2
  • that is some interesting insight. it would definitely take more work to wire up a moving progress bar to indicate the function's current step versus just the barber shop ones, but i would submit that adding that to the interface consumes real estate where the spinner/hour glass would accomplish the same thing.
    – ikathegreat
    Commented May 1, 2015 at 15:06
  • 1
    It can be difficult, but part of the attraction of committing to a progress bar is that it then motivates you to make it fully functional. The extra work will often improve your code in other ways-- usually the lack of a percentage is because you're running a single huge loop, and that probably also means you're not responding to user "cancel" actions, yielding time to other UI events, etc. As for screen real estate, there are always solutions to that-- coalescing progress bars, putting the progress in the window status bar, putting it in the background of the button...
    – bobtato
    Commented May 1, 2015 at 17:21
2

1 second is a long time at work. 400ms might be better. longer than this is often identified as "laggy" and calls performance into question. One of the applications I worked on some 20 years ago waited on transactional data from a server that typically took 15-25 seconds to arrive in extreme cases (9600b/s multi-drop line). On the window concerned the programmer did not put up the hourglass (it was an animated clock face) at all. We found that for longer transactions some of the users were rebooting after waiting 10s as they assumed the PC had hung. Putting it up instantly reduced the user's angst considerably.

Improve this answer
1

Couldn't it be a simpler choice?

A spinner or rotating hourglass, as you put it, for operations where the length of the operation is undefined by factors outside of your control, network latency etc...

A progress bar for a defined operation i.e. we know we have to read 480 records from a database and can easily convert this into a percentage read figure.

The spinners are a little more wooly and I would hesitate to recommend their usage without providing feedback for a lengthy operation feedback and the ability to cancel should it take longer than expected.

Improve this answer
1
  • it does depend on the function's context: something that is recursively searching folders and subfolders for files with a certain file type is an example of something that may take a while, but the number of files to search through is unknown at the start of the function. so a progress bar would be difficult to display.
    – ikathegreat
    Commented May 1, 2015 at 15:08
1

It is all relative. If it is a database application with millions of records a user will (should) have a different expectation.

My approach is for anything that might take longer than 1 second is to display an hour glass AFTER 1 second. I like to keep visual clutter down.

If it is a task that can take more than 10 seconds and you can display actual progress (e.g. 50%) then show them a true progress bar.

There are some search conditions that I know are going to be hard (long) and I give the user a warning up front this is going to be a longer search.

If it is a task that can take more than 10 seconds then give them a chance to cancel out. They may have entered the search wrong and it is taking a long time because of a weird search. If it is likely to take more than 10 seconds and there is no option to cancel out then give them a warning.

Give the user to option to automatically cancel out after X seconds. In my application if search is going to be hard they will often come at it from another direction.

Can you break the task up to return a count first. Like I have some bulk operations and I will return a count first and if it is > 1000 I tell the user are you sure you want to process X records? This will take a while. In a demo I saw a person mess up and create a workflow for then entire library of over 1,000,000 record and it finished in 10 minutes which is fast for that many records but it felt like an hour during the demo.

I have one common operation that takes 2-3 seconds every time. For that I don't display an hours glass.

Improve this answer

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.