Slow down job for better progress animation

Question

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.

Questions:
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!

EDIT:

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:

Answer 1

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.

Answer 2

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.

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.

Answer 3

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!

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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 :

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.