Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I'm sure many people have noticed this before and I can't be the only one to be annoyed by this, but progress bars (I'm referring typically to those that display the progress of the execution of multiple tasks rather than single tasks - i.e not an image upload) rarely offer a true representation of the progress and time taken.

Progress bars are able (or should be able) to tell us two things.

  1. How far through executing a certain procedure the computer is.

  2. Approximately what pace it is progressing (the speed it fills up - a visual indication).

However, the nature of most progress bars is somewhat 'stuttery' and I gather the reason why is something like my diagram below:

For some reason progress bars seem to be divided into equal sections for the number of tasks to be completed, so in my example, 33% will be given to a task that takes roughly 6 times as long as the other 66%, giving a false representation of the progress made.

What I think progress bars (continuing my example) should be like is as follows:

Why don't the majority of progress bars seem to follow this example? And furthermore, why can't progress bars fill up at an even pace, rather than halting on one particular task for 10 minutes, leaving the user clueless as to whether the installer has crashed or if its processing a lot of information. If it's the latter, why is that process not broken down further to be represented on the progress bar?

share|improve this question
You would get a far better answer to your actual question on Stack Overflow, since it's all in the technical details of installers. There's a UX question in here, but as it's written, it's really a technical question. –  Charles Boyung Sep 26 '11 at 1:40
Knowing that an install/ect process hasn't crashed is amazingly useful, and is one of the most important things a progress bar can do. if it can give an approximate ETA that's great. If it tries to be more specific than that it's probably just going to be wrong and even more frustrating as it's trying to be more accurate than is feasible, or even possible in some situations. –  Ben Brocka Sep 26 '11 at 3:03
Because just like when your boss asks you when something is going to be ready, you really don't know. –  JeffO Sep 26 '11 at 13:04
@JeffO You can at least give a rough idea though... which is the point. :) –  Anonymous Sep 26 '11 at 13:57
xkcd.com/612 –  jfrej Apr 18 '13 at 10:27

9 Answers 9

up vote 15 down vote accepted

You think that's bad? In some cases, progress bars aren't even tied to anything in the first place! They just display a scrolling animation to try and soothe the user.

Why is this? Well, I don't know installer tools well, but from what I've seen, most off-the-peg progress indicators rely purely on the number of commands in an install script, and don't let developers attach extra 'time' or 'weight' to anything particularly time-consuming.

What's more, estimating installation time isn't trivial. Traditionally, installers just used to copy files, and could therefore just set the progress bar to reflect the proportion of bytes shifted, but modern installers are more complicated. An installer might have to check if certain libraries are present on the client machine, or connect to the internet to check for updates. These sorts of things make building a truly useful progress bar all the harder, and without the will to address the problem, it's unlikely anyone will address the challenge.

That's not to excuse badly implemented progress indicators, though. One of the biggest problems with these 'non-linear' progress bars is that they make it very hard to tell when an installer has crashed, or merely chugging through a large task very slowly. This could prompt the user to close an apparently 'crashed' installer prematurely, which risks damaging the operating system or complicating future installs. In today's applications, that's just not acceptable.

share|improve this answer
and don't forget installers that have to connect to network resources (usually over the internet) to download content and/or write data (like configuration to a database) which has performance unpredictable during the creation of the installer. –  jwenting Apr 18 '13 at 11:14
Also: Copying a large number of small files takes much longer than a single large file of equal size; making neither files remaining nor bytes remaining useful on its own. Sometimes another process or the user decides that it would like to do stuff during your installation, making the time to execute identical instructions variable. –  Matt Apr 18 '13 at 18:00

One reason why the progress bars don't progress at an even speed is that they are meant to indicate 'real' progress. So, until a task is finished, the progress should not be visualized... however frustrating that may be for the user.

One of the things I've noticed is that progress bars are more task oriented than goal oriented. You can see one file being copied and then another... this is not useful as it doesn't give a real indication as to how long it will take to finish the goal.

A goal oriented progress bar, on the other hand (in the way that you propose) is sometimes very hard to achieve as some subtasks could be optional.

Having said all that, I do like your idea, but the reality is that the world is full of incompetent (ups, did I say that?) programmers/analysts/consultants (or lazy, or both).

Edit: I'm with Jimmy, it's not trivial but neither should it be acceptable to just wing it.

share|improve this answer
I suppose the most common example of what I'm suggesting is installers with two progress bars - one for the current task progress and one for overall progress. –  Anonymous Sep 25 '11 at 21:35
The problem with saying it's not okay to just wing it is that often more explicit progress bars are often over complicated and still give no actually useful ETA, despite immensely greater effort put into installing them. The most important part of a progress bar is an indication that the steps are indeed executing and not stuck. A general ETA is a great bonus, trying to accurately estimate a real ETA is too complex and will be greatly misleading in the large likelyhood that it is infact incorrect in any particular case. –  Ben Brocka Sep 26 '11 at 3:01
@BenBrocka, I'm not going into any technical detail, but the UX will not even be close to decent without a useful ETA, and that's really what we're talking about here. –  GUI Junkie Sep 26 '11 at 18:18

There's two reasons I can think of why progress bars are not that accurate:

  1. Developers are lazy; or
  2. For some tasks it is REALLY difficult to guess or determine how much time they would take proportionately. Take for instance a progress bar for a task that queries a database, returns a number of record, does something with them and then accesses a web service: there's no way to know at time of coding the app how many records would be returned, and the time taken to access the web service would depend on the user's connection speed.

Ever heard of Microsoft-minutes? :)

share|improve this answer
As a longtime developer, it's option 2! –  DJClayworth Sep 27 '11 at 20:45
Also as a developer, I agree with point 2. However I must say that in some cases, it is because developers are lazy. It would take a ton of work to figure out approximately how long things would take, and update progress bars on an un-equal level. Take me, most of the time, I just use a progress bar that never "fills up", instead it just keeps showing that something is happening. Now for longer tasks I might try to add some logic, but it usually isn't worth that hassle to make things extremely complicated. –  Josiah Apr 18 '13 at 13:01

As other stated, it's impossible to know how long a task will run on any given hardware. It gets even trickier if there is more to an installer than just moving files from A to B, for example if it needs to download more files from a different computer during the install, or has to close another program (and wait for the user to close it manually) in order to replace files or services currently in use.

even more annoying are those progress bars that start again at 0% after they hit 100%. Some older installers during the Win95 area used to give you the progress for EACH FILE copied sometimes; so you wouldn't know if the installer tries to copy 10 or 500 files ...

share|improve this answer

1) During "loading" and/or installing of software, there are many difficulties in determining how long each process will take. That's why quite often, it's jerky.

2) Where this isn't the case, it can still be beneficial to go from slow to fast, as it screws with the way we perceive time. A slow start, and subsequent buildup of speed, decreases a user's annoyance.

And if I'm to throw in my own two cents: nothing's more annoying than waiting for ages on those last 10%. Hence a lot of progress bars going slow & jerky in the beginning, and then the second half happens ridiculously fast or instantly.

share|improve this answer

I believe you missed the point of progress bars. They are not intended to represent the progress of a task, they are intended to show that the task is not stuck. Windows 7 progress bars flash every so often so indicate that it is not stuck even if it is not moving. Some software gets away with showing progress with totally unrelated messages such as "Hiring bits...", "Packing bits into bytes...", "Acquiring memory leak protection insurance...".

Some progress bars use a logarithmic scale, they advance half the unfinished part per 10 seconds, so there is always progress but the bar never gets filled (until the task is complete).

There is of course a problem here in that a task can be stuck and the progress bar keeps assuring the user that the task is not stuck.

Attempting to estimate the required time correctly and moving the progress bar accordingly is extremely difficult as seen in the other answers and mostly pointless. The best you can do is to make a progress bar that moves when there is progress being made and gets stuck when the task gets stuck. Sometimes the progress bar will get stuck, then continue, assuring the user that the progress bar is meaningful. How fast it moves does not matter. If that seems like cheating to you you can replace the progress bar with a cyclic animation like youtube's video loading animation that shows progress being made but not how much (except that it does not get stuck if there is no internet connection like it should).

share|improve this answer

for the most part it is better to use a checklist of phases and use a filling progress bar were the number of operations is known. such as copying where the number of files to copy or their total length are known. and otherwise use a indeterminate progress bar when the number of operations is unknown.

from the OP's example the copy and delete files phases are known length so they should use a progress bar but the install is of unknown length so a indeterminate progress bar would be better for it.

share|improve this answer

Using a progress bar to show the completion of steps is utterly wrong, IMO.

I use progress bars strictly for those task that,

  1. I can predict the time/size of the task, in one single unit (e.g. seconds/megabytes).
  2. I can divide the task to progressive units, and all units have equal weight.
  3. I can calculate how much of progressive units has been completed.

Thus, if I do a download, and then an install, I will never show them in a single progress bar, because I cannot assign units such that there is equal weight for download/install units.

Example scenario: The task has three steps: Download, install, and configure. Download has completed, install is 30% done, and configure has not been started.

There are few ways I can show this kind of information:

A Task List, and a Single Progress Bar

|  x Download       | Progress:                                               |
| -> Install        | [============----------------------------]         30%  |
|    Configure      |                                                         |

Multiple Progress Bars

|                   | Progress:                                               |
|    Download       | [========================================]        Done  |
| -> Install        | [============----------------------------]         30%  |
|    Configure      | [----------------------------------------]     Pending  |

Of course there are million ways to design these two UI concepts.

Additionally, you can show the units next to (or instead of) percentage. E.g.:

  • Downloading a file:

    [============----------------------------]  30% (26.7 of 89.0 MB)
  • Extracting an archive:

    [================------------------------]  40% (2617 of 6543 files)

Points to Note

  • I always try to choose units of progress so I do not have to tell a lie to the user. For example, I do not measure progress of a download by time (because I cannot!). It should always be Bytes/Kilobytes/Megabytes.
  • If I cannot robustly calculate a progress, I don't show a progress bar. For example, I don't have a suitable unit to calculate the progress of my "delete temporary files" step. I use an indeterminate progress bar in these situations.

    [---------------====--------------------]  Deleting temporary files...
share|improve this answer

I think many times developers developers intentionally make a progress bar ambiguous, because they know about the Halting Problem.

In computability theory, the halting problem can be stated as follows: Given a description of a computer program, decide whether the program finishes running or continues to run forever. This is equivalent to the problem of deciding, given a program and an input, whether the program will eventually halt when run with that input, or will run forever.

Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist.

In general, it's not possibly to accurately determine if an installer will even finish, never mind when. While this is somewhat theoretical, it is actually a hard problem to determine with any exactness when an installer will finish.

share|improve this answer
the halting problem says that there exists no program to determine if any program writen in a turing complete language would halt. this doesn't mean that it isn't possible to prove that some programs will halt. and in some restricted non-turning complete languages, all programs are guaranteed to halt. –  Dan D. Sep 26 '11 at 5:18
When you have a list of files to copy, it's pretty easy to see that it will finish, the halting problem has absolutely nothing to do with this. –  Stavros Korokithakis Jun 28 '13 at 13:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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