So, I am in a situation where I am developing an internal application that executes a list of many task items, some of which have multiple steps. For each task item, I also have a progress bar. Well, considering how fast these steps happen, some progress bars literally jumps from 0% to 100% immediately.

Now, my 'bright' idea was to slow down the background job ever so slightly that the user can see a smoother animation of the progress, but not so much that the job takes significantly longer.

Is this an acceptable practice? Or is this something that is used in commercial applications? Is it advisable to do this (or not to)?

I am intending to slow down the background job by just putting the thread to sleep for maybe... 50 milliseconds at a time.

At this point, it doesn't make sense to change my progress feedback UI, which I know might avoid this issue altogether. So, for the purpose of this question, assume that each task has a progress bar associated with it.

What do you UX experts think about slowing down the job for a smoother animation?

This is a very similar question, but I don't think it seems to address my question fully.
The answer by Aadaam is what I was thinking about doing. I am wondering if this practice is acceptable (not how to implement it). Though if there is a particular way that implementing makes it acceptable, please share!


As I re-read my question, it seems as if I'm talking about any type of application. Perhaps I should clarify that:

  1. The job (as a whole) could potentially take as much as 15+ minutes.
  2. It is important to me that the users know exactly what is happening. The information that is displayed is useful to the user, not solely the developer.

Here is an example of the type of UI I'm working with: Progress Bars UI

  • 42
    I'd say never slow down your app, if individual items are moving too quickly to give a "smooth" animation bar then maybe no bar is needed for that item(s) and less granularity would be better. Commented Apr 2, 2015 at 16:33
  • 23
    Imagine 15 tasks that could collectively finish in less than a second. Now imagine waiting 15 seconds so each one can animate 100%. That would be a very long and frustrating 15 seconds. Commented Apr 2, 2015 at 17:23
  • 3
    Way to put things into perspective. 100 items @ 150ms delay adds up quick... I hadn't thought of that. Commented Apr 2, 2015 at 17:25
  • 17
    From a development perspective if someone proposed this I would be so angry.
    – Eric S.
    Commented Apr 2, 2015 at 20:53
  • 4
    First thing I did was check when this question was posted. I was sure it was going to be April 1. Sadly disappointed. Why would anyone even ask this?? Commented Apr 4, 2015 at 6:15

14 Answers 14


I was thinking in a similar line as @Yako:

Do not slow down any tasks, but think on what gives a nice user experience separately.

My suggestion:

Don't slow down the task, slow down the bar

Just let your tasks run, and measure their progress, but rather than displaying the updated progress immediately, do something more smooth. For example: define a maximum speed for the bar.

So, if you think that it looks smooth enough if a bar takes 1 second to complete, you can build it in a way that it fils up at most 1% every 10 ms, regardless of the actual underlying progress.

Sidenote: Of course this is only good if your users need a general indication of when things are done, if they need to make decisions/see things based on whether a step just completed or not, then a 1 second lag may not be acceptable.

I think this method is especially nice for independant tasks, or tasks that take much more than 1 second, otherwise it will be confusing as you probably will get a cumulative display delay of upto 1 second per task.

  • This is a good approach (+1) but only if there's no pressing need to allow users to abort a process. If those subtasks are "Prepare missiles", "Arm missiles", "Launch missiles", don't give if the impression they haven't yet completed when they have! Commented Apr 7, 2015 at 16:40
  • Going to have to select this as the answer. It allows the UI to remain as-is and generally solves the issue of progress bars updating too fast. It gives a smooth animation, it's still very indicative of when the job is finished, and it doesn't slow down the actual task. Of course considering this option will completely depend on the criticality of the tasks. Commented Apr 23, 2015 at 16:58

Root Level Progression

I think a better approach if your sub tasks are completing very quickly would be moving the progress bar to the root elements.

enter image description here

Or outside of the table completely (if it's an option) which also gives you the ability to use different icons if a sub task fails etc.

  • 1
    I think a nice addition would be to have some kind of indicator that a task is being worked on, for example, displaying ... or some kind of loading icon. This will also allow for concurrent tasks, if the application could do this in the future. Or at least make the bolded task the task that is currently being done.
    – Sanchises
    Commented Apr 9, 2015 at 12:22

I would hide the progress bar once a task is completed.

Progress bars communicate to the user that something may take awhile so maybe you could hide the progress bar at 100% and even change the word to DONE.


If all the tasks start out as DONE then awesome I have to tell all my friends how fast you are!


No, don't slow down the job.

There's nothing wrong with having something be instantly 100% done. Your app will actually seem better than if you slow things down so that the progress bar animation is visible.

Users would love nothing more than to have everything happen instantly.

  • Indeed, and many times we have very high-end machines, where tasks seem to run really fast, but on a user's "average" machine, the tasks are slow. Once I had a task complete in 3 seconds, where it took 15 seconds for a user.
    – harsimranb
    Commented Apr 7, 2015 at 16:41

I think that a perceptible progression may be a good idea after all:

If it jumps straight from 0 to 100, did it really work? Wasn't it a bug?

However, it's important not to actually slow down the job, but only its perception by the user.

So, here are a few features I would likely implement in that case:

  • an animation of 100ms between each step (so that it's perceptible from 0 to 100%)
  • If possible, do not wait for a job to be finished before starting a new one. Or, at least, do not wait for the end of the animation.
  • If a new % step gets updated during the animation, cancel the current animation and directly jump to the next value, so that the animation times of each step do not sum up.

Doing so, the progression would be perceptible, without slowing down the whole process more than 100ms.

  • 3
    If it didn't work then it would be at 0. The fact that the UI changed the value to 100 indicates that the task completed.
    – 17 of 26
    Commented Apr 2, 2015 at 17:28
  • My point was that some users (not every) may be worried if they can't perceive any evolution in a state change. They may wonder if the process actually started, or if it was finished before the job started, or anything else... A fast animation from 0 to 100 would wipe any doubts.
    – Yako
    Commented Apr 2, 2015 at 17:57

I don't want to go to far out on a limb and speak for all users here, but I'm not sure I would ever choose smooth progress bar animation over faster running task.

I would be perfectly happy to see a task take basically no time, in fact when I am watching an install or other staged process, I love it when one item zips right to completion, going directly from 0% to 100& would make me happy.


Don't forget that a progress bar is merely a feedback tool to indicate to the user that something is actually happening, if a task is taking longer than a second or two, and no UI changes are being shown.

Twenty years ago, in the days of Macintosh System 6.0.5 and prior (or if you were from the other side, Windows 3.1), processors were not fast enough generally to complete what we would, today, consider to be simple tasks in sub-second times. So the progress bar was born, for the comfort of the user, to allay any fears that the system had crashed, in the absence of feedback of (immediate) task completion, when in reality the system was churning away trying to complete the task.

Today, we have become so used to the ubiquitous progress bar, that we can feel naked without it.

You should never slow down a task (unless if is detrimentally affecting gameplay) in order to display an in progress UI feedback tool. The user wants end results, not to watch a UI. Face it, it the task is tardy enough, they have probably gone to make a cup of tea/coffee (much to the boss's chagrin).

In short, if the task is taking less than a second to complete (and ticks, or "DONE" messages, are showing that the task is complete) then the progress bar is obsolete, and is demoted to being merely a pretty UI element that makes your UI have that standard look and feel.


Similar to @DaveAlger's method, I would add that you could color the row as well. You would immediately know at a glance what has finished and what hasn't :

enter image description here

  • 18
    I wouldn't use red in that case, red means failed..; Commented Apr 3, 2015 at 11:50
  • 2
    Sure you could change the color. I never said it had to be red. 😀 Commented Apr 3, 2015 at 14:15
  • 1
    @Thomas - while the root point of your comment is valid - i.e., "be careful about the color" - red does not "mean failed". Color has no meaning outside personal experience. Red means lots of different things other than "failed". Commented Apr 4, 2015 at 3:22
  • 4
    Almost universally, green is good/yes/go/success, red is bad/no/stop/error and yellow (half-way between them) is ok/maybe/yield/information.
    – Jon
    Commented Apr 6, 2015 at 12:08
  • You are all missing the point. It doesnt have to be red and green I never stated it did. The point was coloring the rows easily helps distinguish between processing and complete. Thats all. No reason to downvote for such a simple and effective method. Commented Apr 7, 2015 at 17:13

I think the correct answer to this depends on your user's expectations.

I had something very similar: I had a varying number of process that would run. I only had an overall progress bar. All the jobs would complete before the progress bar could even be displayed. The users left comments like, "I ran it multiple times but it never did anything."

My solution was not to slow down the individual processes, but to put a miniscule delay between the processes, and a half-second delay when they were all done. Now the users see progress, and all the processes, including delay, run in about 1 second. Everyone is happy.


This is a question of mitigating the overheads in a job with many small steps.

The problem is a progress bar flickering between 0 and 100% for each of many little files. I have a similar issue in one of my own SPA apps which has a bootstrap loader (which loads bootstrap among other things). jquery-ui is huge, dozens of helpers and polyfills are not.

The point of progress bars is not to indicate progress. It is to reassure the user that things are proceeding according to plan, and to mitigate the perception of delay by diverting attention away from it. By making the frequency of progress update a steady 1Hz we can achieve these goals without ugly flickering or imposing ridiculous display update overheads. But how to do this?

Nagle's algorithm was invented to solve a fundamentally similar problem with telnet sessions: too many small updates produces a lot of overhead. If you send a keystroke message every time a key is pressed, you will get a 40 byte header for a 1 byte message, along with all the network round-trip delays. If you update a progress bar for every tiny little file, you get flicker and DOM update congestion.

Nagle solves this by batching with both timeout and maximum batch size. By sizing the timeout and the max batch size appropriately, you can produce a steady rate of update with an acceptable maximum delay. If you want the particulars it's thoroughly documented in RFC896.

You'll have to measure actual performance to find out average items per unit time. Don't be too fussy, you only want indicative figures, and if one or two items skew it by dominating the run you may want to exclude them from the measurement. For example, if you have 282 items taking 60s but two of them take 40sec your rate should be 280 / 20 = 14 items per second.

So in this case a timeout of 1000ms and a max batch size of 14 will produce steady 1Hz progress updates. Not slow enough to worry the user, not fast enough to worry the browser.

  • This is not a question of mitigating overhead of small steps, it's a question of "users being concerned at large numbers of tasks completing instantly", which Nagle's exasperates instead of fixes. Commented Apr 6, 2015 at 20:39
  • The word you are looking for is "exacerbates". You are also mistaken, and I have expanded my answer to better explain how Nagle can be used to improve the UX. Dennis Jaheruddin has suggested more or less the same thing (mitigate the frequency of update) with a less engineered method.
    – Peter Wone
    Commented Apr 7, 2015 at 1:43

I would not slow down the job for a smoother animation.

How does this look:
1) Can you try and use a circle loading and stay away from numbers all together. I am assuming lthings move very fast. Maybe you can show feedback only when there is an issue. Advantage less clutter on screen.

2) Instead of making 4 loading bars can you just make one for the main task. Maybe this time show text feedback like (Sub task 1 completed etc etc) along with the visual clue of loading bar on top. This might help slow down the job and yet keep the user informed at all times.


If a task happens instantly, give it a quick yet smooth animation. If a dozen of these happen at once, all the bars can animate smoothly at the same time. I would recommend using a smooth curve so each starts slow, speeds up, and ends slow, but I would recommend the animation only lasts around half a second at most. This way it appears smooth but it does not slow down the underlying application. It is a very bad idea to force your user to wait unnecessarily, but simply smoothing the animation itself would be better if you believe it is necessary to show a progress bar in your context.


Don't compromise. Have two animations that are optimised for their own purpose:

  1. An accurate animation showing the progress of the task. For example, the bar filling up from 0% to 100%.
  2. Then, an aesthetic animation marking the status change from 'in progress' to 'complete'. For example, a green glow surrounds the bar, then fades after two seconds, while a green "tick" icon or the word "DONE" fades in, or the bar fades out.

This way you get the best of all worlds:

  • The task completes as quickly as possible.
  • For super-fast sub-tasks, the user sees lots of pleasing, smooth status change animations happening very quickly. Everything looks like it is progressing smoothly, with the same smooth "success" animation for every task, (even if it completed in 5 miliseconds).
  • The user gets accurate information about what is happening right now. If the next subtask is "launch missiles" and they realise they chose the wrong target, they can abort in time.

As said by all don't put job in sleep state just to show smooth transition of progress bar. UX is not about only UI components of your app but it is how your app delivers delight collectively from all perspectives and efficiency is one among them. Your developers (or you) has done a great job to finish a task in less time so don't let UI components affect that work. Lots of good solution are already provided by UX geniuses, I just want to add a screenshot of MS outlook app, when you create an account in outlook. I thought it may be helpful to you.enter image description here

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.