Submitted by “Most software packages employ progress bars to visualize the status of an ongoing process. Users rely on progress bars to verify that an operation is proceeding successfully and to estimate its completion time. Typically, a linear function is applied such that the advancement of a progress bar is directly proportional to the amount of work that has been completed. However, estimating progress can be difficult for complex or multi-stage processes. Varying disk, memory, processor, bandwidth and other factors complicate this further. Consequently, progress bars often exhibit non-linear behaviors, such as acceleration, deceleration, and pauses. Furthermore, humans do not perceive the passage of time in a linear way. This, coupled with the irregular behavior of progress bars, produces a highly variable perception of how long it takes progress bars to complete. An understanding of which behaviors perceptually shorten or lengthen process duration can be used to engineer a progress bar that appears faster, even though the actual duration remains unchanged. This paper describes an experiment that sought to identify patterns in user perception of progress bar behavior.”
This is all very nice, but probably the single best thing developers could do is not employ the exceptionally annoying concept of once the progress bar reaches 100% it then goes back to 0% and starts all over again, and then repeats this 50 times..
It would be better to just have some spinning icon like in Firefox or IE which symbolises it’s still working, rather than give people false hope that it’s almost complete.
You beat me to it. The biggest, and most annoying, example of this is the Windows MSI installer. It progress bar is no reflection at all on how the install is progressing, and it insists on going back to the beginning several times. The net effect of this is that a user simply doesn’t believe it at all, and finds it annoying that it seems to be deliberately trying to mislead.
I don’t believe this is the correct article, because the link I’m getting is to do with Vista SP1.
This commment is coming in:
..1
….2
……3
……..4
……….5 seconds
I agree. People should not use a 0-100% progress bar for unknown quantities. They should only be used when the exact number of items/events is known. When I am in an unknown situation that may take a while, I usually show the user a status bar displaying items or events as they are processed. Then they know what is happening, and can see progress (items changing), but they are given no false illusion of percentage of progress.
[Edited for spelling]
Edited 2008-03-05 22:24 UTC
Here’s the correct link: http://chrisharrison.net/projects/progressbars/
And there’s a short summary of the study at least here too:
http://kostuff.blogspot.com/2008/01/progress-bars-to-make-people-ha…
To quote the last article:
“Chris Harrison et al. has a paper showing that people perceive time as running faster if they are looking at an appropriately accelerating progress bar. It seems that a progress bar that slows in the beginning and accelerates near the end (called “Fast Power” in the paper) makes people happiest.”
Edited 2008-03-05 22:46 UTC
Oh, and another thing. Get this. The MSI installer actually has a progress bar that goes backwards if the install rolls back – several times.
The progress bar going backwards I think is actually a good idea. It’s that, “several times,” bit that is annoying. Of course, also the part where its position isn’t based on a meaningful measure of how far along it is.
The best setup I’ve seen used is a two bar combination for current step and total progress. The current process bar can restart over and over as long as the total progress bar ticks along slowly with an accurate estimate of remaining time.
Someone could even do it as a pair of circles with total progress wrapped around process if they wanted to be different.
I agree fully on a single progress bar that starts over for each process step though; it’s usless screen clutter that does nothing but tease the user.
It might actually be rather difficult to choose one general best way to to visualize the status of an ongoing processes that would suit all kinds of processes, users and situations as well. I suppose that personally I would usually prefer to see more information about processes than just some simple graphical progress bar – how ever well designed it might be.
Operating system booting process is often visualized by showing a simple progress bar too, like in Ubuntu and MS Windows. But what if there are problems in the booting process? How much information can a very simple graphical progress bar give of complicated processes?
If I take Ubuntu as an example, I tended to like the older Ubuntu Dapper Drake version graphical boot screen better than the new supposedly all graphical boot screen. The new version seems not to work very well as it constantly changes back to a pure text mode all too often, although it is not supposed to do so in theory. The old Dapper version of the Ubuntu boot screen was better – in my opinion – as it combined both a visual progress bar and some simplified textual boot information scrolling on the screen. Enough information but not about non-essential details.
Progress bars are complicated, but they are more than just indicators of when the job will be done.
The are indications that something is happening.
If you put just a twirling icon to say ‘i’m busy’ the user could not tell if any progress is being made at all.
Even the most flawed progress bar still gets feedback that something is happening. Take the MSI installer…sure it bears no resemblance to time. But you know its doing something. Helping progress bars might even have text to tell you what they’re doing (see the text changing…it’s doing something).
Exactly my point!
Well, interesting paper, especially (to me) pg. 4 § 2.
There’s something I’d like to mention additionally, from my daily experience. My main file manager is the well known Midnight Commander. It utilizes a triple progress bar, combined with an ETA indicator. This looks like this:
———————- Copy ———————-
Source: foobar.tar
Target: /export/home/foo/bar/foobar.tar
File: (#######################__) 95% ETA 0:02.10
Bytes: (#####____________________) 24% 2.57 MB/s
Count: (###______________________) 22%
(Skip) (Abort)
Thiese indicators show you in an appealing setting,
1. that the system (the application) is busy,
2. that something is happening,
3. which files are involved,
4. how the process is going on for the actual file,
5. how the process is going on regarding all the files,
6. how the process is going on regarding total byte count,
7. which bandwidth is occupied,
8. when the process will be finished.
These informations are presented in an appealing setting. Of course this is an example for a simple task (copying file), but it can surely be applied to other kinds of progresses (image manipulation process, DVD recording process), too. I know my comment is not very scientifical and lacks a chi-square factorial analysis. 🙂
Copying a file actually is a easy to predict operation. You know the amount of bytes that will be copied in advance just by stat()ing them. Other operations are often not as easy to predict.
However, I’m pro Progressbar for the already mentioned reasons.
For Mac OS X 10.4 (Tiger) users, this is an interesting command to try:
/usr/libexec/WaitingForLoginWindow
Fun, uh? 🙂
(don’t worry, it’s harmless – you can kill the process at any time from Activity Monitor or the Terminal)
Not sure if it is the same in Leopard. What is that? Is the fake “progress bar” displayed during startup. It doesn’t actually measure startup progress, it simply guesses how much time will take based on how much did it take the last time.
More details (and why is it done that way):
http://daringfireball.net/misc/2005/04/tiger_details#waitingforlogi…
Nothing like getting time to do a proposal about trying to best represent actual progress in non-linear plots.
Next.
If you need a progress bar when installing your program it’s to bloody bloated. Code more efficient, lazy B*D!
I miss the old 99% Win 95 – Win 98 – Win 98SE – Win ME all quality products with their life cut short.
I thought Microsoft will Support an OS for up to 10 years Win 2000 will be the first to last 10 years.
When will 128 bit computing come out 2012 or 2015.
I’ve found the paper very interesting, but it doesn’t explain the problems with the progress bars when downloading something, just a mention about a particular case of net installation. In these cases anyone can predict the behaviour of the net, so the progress bars, even with the proposed functions, are useless in such scenarios, and are used in every browser and in every networking tool.
I know that the paper doesn’t try to find an alternative or a better approach for progress bars, but I think progress bars are mostly useless due to the quantity of variables that can affect the behaviour of a task.
Edited 2008-03-06 13:46 UTC
The paper actually instruct programmers how to lie more convincingly. Bah. Just wasted cycles calculating fake accellerations that could be used to start another process instead.
I’m rather partial to the old classic FOSS progress bar that we used to use: It simply displayed “It’s Ready When It’s Ready” on the screen for the duration, with an occasional popup message informing you that the latest nightlies are awesome.
The new linear time-based progress bars lack all the suspense and excitement or their predecessor. 😉
The problem with the “progress bar” is just one of poor presentation. If you merely want to indicate that a process is ongoing, the “progress bar” shouldn’t reflect a quantity, just toggle between colors at every quantum of activity to indicate that something’s going on (and give some subjective feedback as to the rate — “gee that blinks twice as fast on that other computer, I wonder if something is bogging this one down”).
If a process occurs in stages, provide a gauge with stages and advance the gauge per stage — preferably with a label indicating the stage. If the process has a problem, you can tell when. If there are substages, provide a second stage gauge.
If a process is going to take a perceptible amount of time to complete, display the estimated-time-to complete or make a time-based estimate of the completion.
After graduate school, I had a job writing some UI wrappers for bioinformatics tools. Some processes were simple and nearly instantaneous, but there were complex processes, often multistage, that could take some time. My representation of progress was gauge-style. Steps indicated by chords (segment of a circle); in the foreground the chords were equally divides per number of steps (5 steps = 5 equal-length chords), and sub-steps another ring of chords inside. Unperformed steps were grey, in-process were yellow, complete were blue (errors red). Steps generally progressed counter-clockwise (but they could go in parallel). Behind the chords was an arc indicating the estimated ratio of time elapsed to time required. There was a small counter showing time elapsed, and in the middle a circle that flickered to indicate activity (like a hard disk light).
It was a little strange to look at, at first, but people really seemed to go for it (unfortunately, that product never shipped — the company became a small consulting firm). The progress indicator gave very concise information about the progress and activity of the program. Not as simple as a bar — but once the indicator object was formalized, it wasn’t any more difficult to use.
The best replacement for the flawed progress bar, in my opinion, is something similar to the rotating activity indicator in SQL Server Management Studio with the progress percentage beside it.
It’s simple.
It clearly shows process activity.
It clearly shows completed progress.
The information is accurate.