Do the progress bars you see when you install a software or load a saved game in a computer game have any relation to the actual percentage of workload completed by the system? In many cases, the bar fills up very rapidly, but shortly before reaching the 100 per cent mark, it slows down so the last few per cent take about as much time as the first 90. I’ve repeatedly heard the story that there is no actual significance to it at all; the reason why progress bar is featured in most software products is simply because the average impatient user doesn’t want to stare at an empty screen while waiting for the installation or loading process to be completed; he expects “something to happen.” What is the Straight Dope behind this?
I don’t know their significance but agree they often proceed in a way that predicts the final completion time very badly. They could be made in a way that was useful though imprecise, for example by timing typical progress on a variety of machines and linearizing an estimate, such that the end user observes a typically rough estimate depending on the exact balance of abilities in the user’s machine and details of this run of the problem.
More than just expecting “something to happen”, a user could want to see some indication that the process has not just stalled. Even a very inaccurate progress bar could provide that. A better tool for doing that, though, would be a little bit of text announcing the name of each step of the process, and perhaps percentages whizzing by for each step.
Recently I used some software whose progress bars keep starting over again at the left once they’ve reached the right. This reminds me of those cards that say “Turn this over to see how to keep an idiot busy for hours” on both sides.
I prefer the way that various Linux distro’s show each file as it is downloaded/installed. Seems a far better method to me.
For the most part they are indeed just there for looks. For some things you can actually, easily, tell how long it will take. But in general different steps in a process take a different amount of time depending on different circumstances. You could figure this all out, of course, but spending a few days timing things so that you can get an accurate progress bar is a waste of time and money. The thing will end when it does.
Yes, getting an accurate progress bar has never been a major priority in the specs for any software I’ve written. The priority has been to have something there that continues to visibly progress while that piece of the program is running, so that the user can see that the program is running and hasn’t crashed, or crashed their PC.
What the progress bar is actually measuring is dependent on the program that generated it.
There is actually a different progress bar for things that you don’t know the duration of. It goes back and forth repeatedly.
I think people don’t use it because they have multiple steps of indefinite duration. So they can say 33% done, then 66% done, etc. The percentage isn’t representing time, it’s representing something else.
I asked basically the same question a few months back:
Ditto. There is significance to the standard progress bar, but it’s really hard to predict the duration of actions so the bars tend to be very inaccurate. There are several different forms of the “indeterminate duration progress bar”–some have the KITT-style back-and-forth appearance; others appear as round animated icons similar to the Vista swirly icon.
For actions that have indeterminate durations but well-known steps, another alternative is to show the “action” animation and a list of the steps, and display checkboxes next to each step as it’s completed.
As others have said, they exist because they give a user some very rough indication of progress, regardless of the accuracy.
From the perspective of a programmer, it is somewhat challenging to create a decent progress bar for a couple of reasons. The first, and most basic, is that in order to have a progress bar that shows 0-100%, you need to know what 100% means. If your program simply chips away at a job until it’s done, with no knowledge of how much work remains, then you can’t implement a standard progress bar.
The more fundamental problem comes because of the traditional layered approach in which larger programs are written.
When you write a simple program using a tool like Visual Basic, you create visual screens and attach code to the buttons and such.
When a user clicks a button, your “button” code runs and all is good.
It is quite common in small apps for all of your code to be stuffed in the “button” event handler, in which case every bit of your code has total access to the visual elements. It is easy in code like this to update a “files processed” progress bar since the code that is processing the files can easily stuff a new value in the progress bar occasionally.
As programs grow in size and complexity, it is very common for whole project teams to develop the application, with each developer working on a different corner. It is common practice to divide the app into layers, with each subsequent layer building on the lower layers, but the lower layers do not know about the upper layers.
Imagine an app that a pharmacy might use for tracking prescriptions: it is most likely that there is a database design, with some business layer code written on top of that: code that does things like “create new patient” and “dispense prescription.” At this point, one could either write a web application or a Visual Basic application that sits on top of it all. Imagine we write both. The database and business code do not know anything about what is driving it, and we have two different applications that drive the same code.
Now is the problem: when someone starts a long task, the only code that really knows the duration and progress is buried in the business layer, and it can’t communicate directly with the progress bar – remember, our app has two different clients, so it wouldn’t know whether the web app or the VB app is calling it.
Unless one breaks the layers and makes the business layer aware of the visual layer, the progress bar isn’t easily updated by the code that is actually doing the work.
The answer is to have the business code fire occasional events that other layers can listen to and respond to accordingly, but this is not necessarily easy since this involves creating an alternate communication path for the events. Furthermore even this will not be perfect since your business code is still at the mercy of vendor libraries that are black boxes. For example, an Oracle database won’t fire events telling the progress of executing a query that takes ten minutes to run: you simply wait ten minutes without knowing at all what the internal progress is.
One nice little touch I like about Mac is that the standard Mac progress bars admit that they’re imprecise. Instead of saying “34:26 left”, they’ll say “About half an hour left”, or the like.
How about that progress bar at the bottom of Internet Explorer? What is that thing doing?
System Shock 2 had such a circular swirly thing. Basically, it had the logo of the ship the game mostly takes place on (the Von Braun), and two contra-rotating concentric notched circles spinning around it. As a progress indicator, it was useless, but it was adapted into a pretty keen screensaver.
Browsers are really hard to do progress bars for. You don’t how many images need to be downloaded until after you download the page’s html. Plus there you can have references to files that reference other file and so on. So essentially you end up adding steps when you’re in the middle. Plus this is all on the network so the time of retrieval is based on transfer speeds which vary from site-to-site.
So it’s pretty hopeless, beyond indicating “done” vs “not done”.
If you search msdn.microsoft.com you’ll find there is plenty of documentation on progress bars. The idea is that you split your task into discrete chunks and increment the bar after each chunk.
According to the docs, if you are loading a file you would stat the file to get the size, divide by 10 and then register the progress bar with your loader function (a so-called callback hook). Every time you load 1/10th of the file you callback the progress bar and it increments a chunk. Of course, this works best when you know how long (or how big) your process will take.
One reason (other than just plain bad coding) you see a jumping bar is because the amount of work, and therefore the length of time, isn’t completely known. For example, if you are saving data (say in XML) and your source data is in a different format in memory - as it will often be - you know you have 10MB of data to write, but you don’t know how big it will be once formatted. You can take a guess but if you end up with a very complicated output file, your guess could be way off.
For an extreme example, consider saving out a huge picture as a highly compressed JPEG. You estimate that copying the data in memory will take 2/10ths, compressing it in memory will take 3/10ths and writing to disk will take 5/10ths. Except somebody loads Word whilst you are compressing and suddenly all the free memory is used. What would have taken 3/10ths of the total time now takes much longer as you use hard disk as virtual paged memory. And writing it to disk is a lot slower as the system is now using paged memory which causes contention for the disk. If you were using a progress bar that was hooked into a timer (so it nudges on every 2 seconds - after guestimating your copy+compress+write would take 10 seconds in total) you could easily be at 100% whilst you are still in the 4th/10th of the process.
Sorry if this sounds complex, but as with most things that appear simple, so are progress bars!
trmatthe
I use Adobe Audition audio editing software every day, even on my days off. The progress bar in it is usesless as a gauge of how long it takes to do a process. It also has a display of how long in minutes and seconds it’ll take. It starts at a number, then increseases in duration! So it’ll say 18:00. Then it starts going upward. 29:00. 47:26. 58:04. Who knows what it’s measuring and by what standard. It certainly isn’t time! So I’ll go away and come back to it, and the whole thing has taken 12 minutes and change. But hey, the blue bar gets to the end just as the process finishes. Maybe the process would go faster if the program didn’t have to generate this useless display.
In Tiger (OS X 10.4.x), the startup progress bar is “fake” in that it completely ignores any actual progress, and instead uses the measured time of the previous startup to give a (fairly accurate) estimate of the current startup.
The usual progress bar function in Flash uses two variables, getBytesLoaded and getBytesTotal. The most common way I see it used is as a percentage: Loaded/Total * 100, but often you’ll get to see Loaded1000 and Total1000, so you can actually know how many kbytes are left to load.
The bar itself is proportional to those values.
Ironically when you compile (‘publish’) in Flash, the loading bar is crap. It often doubles back on itself if you have an particularly large file. Chalk it up to poor programming I guess.