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.

How far through executing a certain procedure the computer is.

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?

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 BoyungSep 26 '11 at 1:40

6

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

3

Because just like when your boss asks you when something is going to be ready, you really don't know.
–
JeffOSep 26 '11 at 13:04

@JeffO You can at least give a rough idea though... which is the point. :)
–
AnonymousSep 26 '11 at 13:57

9 Answers
9

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.

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.
–
jwentingApr 18 '13 at 11:14

2

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.
–
MattApr 18 '13 at 18:00

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

Developers are lazy; or

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.

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.
–
JosiahApr 18 '13 at 13:01

The worst one in my code is that when saving our large files, there's a step that can fail if the virus scanner grabs the file at the wrong time, so we put in a workaround, but the workaround is really slow, often doubling the total time. And it's completely impossible to predict when we'll need to fall back on the workaround. So the progress bar goes to 99%, and if the workaround kicks in, the last 1% takes as long as the first 99%, otherwise it takes zero time. :/
–
Mooing DuckApr 6 at 20:43

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.

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.

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.
–
AnonymousSep 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 JunkieSep 26 '11 at 18:18

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 ...

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).

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.

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.

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.

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

3

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 KorokithakisJun 28 '13 at 13:12