This one is astonishingly trivial but…quite a number of computer programs I’ve installed recently displayed “progress bars” during the installation process. In most cases, these were effectively useless, for one of the following reasons:
(1) The rate of “fill” on the progress bar was highly variable, with no text telling the user what was being done – so, for example, the first half the bar would fill in ten seconds, but the second half would take twenty minutes. You couldn’t look at the bar to figure out how much was actually remaining.
(2) The bar filled at a steady rate, and/or there was text explaining stages, but when the bar filled it would be replaced by…a different bar. Without knowing how many there were going to be, you’ve gotten no real information from the thing.
So…what’s the reason for including the progress bar in the installation program? Is it to let the programmers know something while developing the program, and they just don’t take it out? I could easily see that with version #2, since if the thing hung, you’d know where it was running into trouble. I’m at a loss on version #1, unless maybe focus groups have indicated that they feel more confident about the installation simply because they can see a bar there (in which case, I suppose you could just add a filling bar graphic that has nothing really to do with the installation…)
As someone who currently develops at least one program with a progress bar, I apologize to all computer users for how bad they are.
Part of the fact is that it’s really hard to accurately estimate how long something is going to take. Most of the purpose of the progress bar is just to convince the user that the program hasn’t crashed or something.
You have to have some kind of user feedback to let the user know that something is going on. Unfortunately, a computer program can’t really know for sure when it’s going to end (if ever). That means progress bars can’t be perfect – they’re always an estimate. A further complication is that the progress bar doesn’t have insight into everything that the program is doing. For example, say your installer has to unpack a zillion files from a compressed archive and store them somewhere. It does this by relying on an external decompression program, and this takes a long time. There’s no way for the progress bar to know how many files have been decompressed[sup]1[/sup]; all it knows is when the decompression program started and when it ends. So the best the programmer can do is say “fuck it, when the decompression program ends, bump the progress bar up to 50%.”
Better integration with external stuff can alleviate this – for example, if the decompression program has an API with callback hooks that can be used instead of launching a separate process, then the installer would have more information to present to the user.
As for situations involving multiple progress bars, the good way to do that is to have two parallel bars, one for the task group as a whole and one for the current subtask. But some interface designers are just jerks and want you to suffer. It’s not like there’s a GUI Police anywhere.
[sub]1. Without some horrible hack like periodically checking the destination of the decompression to see how many files have been written there.[/sub]
The ones that really drive me bats are the ones that fill in a progress bar, then up pops a new blank progress bar to fill - it’s as if they’re just repeating an animated GIF.
And then there’s what we laughingly call “Microsoft Minutes” - For a variety of reasons, Windows is bad at estimating time to do almost anything, so the last time I wanted to copy some files off my PC to a network drive, the progress indicator starts out as 25 minutes remaining, then jumps to 35 minutes remaining
27 minutes remaining
17 minutes remaining
16 minutes remaining
22 minutes remaining
15 minutes remaining
I’m just an amateur/hobbyist coder, but I think what others have said is key. It’s not at all easy to estimate time, so when you code a progress bar you tend to bump it when specific tasks are completed. So if your progress bar is reading 50%, take that to mean that the program has completed 50% of the instructions it has, not as a measure of time.
I suspect these numbers come from estimating the time remaining based on how much has been loaded already and the rate. Way back when I had a dial up connection I saw the same effect when downloading something. If you ever use a GPS for a long trip, you can see time to destination wandering all over the place depending on your speed vs. the average speed of the trip so far.
I’m a professional software developer with 20+ years experience – 16 years on Windows – and I’ve done a few installers. On Windows boxes, most installers use Microsoft’s Windows Installer technology (MSI), a standardized set of interfaces & specifications for software installation, patching, and un-installation.
MSI is data-driven – most of the time, the developer doesn’t have to write any code to create the installation package. The MSI file itself is basically a SQL-like database; the developer uses a third-party tool (InstallShield, Wise) to populate the tables in the database.
Microsoft’s system code reads the database and executes the appropriate operations (copy file, update system registry, etc.) based on the data in the database. So for most installations, the updating of the progress bar & associated text is largely outside the control of the developer.
Microsoft does provide a way for the advanced developer to customize the progress bar – basically, you can set the number of ticks on the bar, move the bar some number of ticks, and set the text. However, this is somewhat difficult to do, even by MSI standards, and requires the developer to write code. In many companies, the installer developer may not be trained in coding – after all, one of the main selling points of MSI technology is that you don’t have to write install/uninstall code.
In my 16 years of Windows developement, I’ve done just about every kind of programming one can do on the platform – device drivers, installers, e-mail servers, COM, you name it – and writing MSI-based installers is by orders of magnitude the most complicated thing I’ve done. The complexity of MSI lies in the completeness of its functionality (they’ve thought of just about everything), and the interconnectedness of it all (change one cell in a table can affect the install in subtle non-obvious ways). Combine that with the usual errors/ambiguities in the documentation, and things get real hairy real fast.
The best ones I’ve seen had two progress bars - one for the entire job, and one for the current file. But I’ve also seen some that are finished when the bar is half full. What’s the point.
As for the reason, they are pacifiers, true, but there used to be a very good driver. Back when we were developing EDA programs on UNIX, with a pure command line interface, you’d have to do some long translations where nothing apparently was happening. Users, especially ones on flaky systems, would get convinced that the program had hung and kill it. Some progress indicator, even simple type and erase / \ and - 's which look like something is spinning, let the user know that the program hadn’t hung after all.
Often, it comes down to laziness. My favorite are progress bars that are obviously keyed to the percentage of files processed. If I unzip a folder with ninety-nine 1K files in it, and one 1 GB file, the progress bar will shoot to 99%, and then stay there for eternity.
The Mac OS X startup bar simply calibrates its duration to how long it took to start up last time.
I used to laugh at this, and then I wrote a program that took several minutes to do one task and I tried the Mac cheat on its progress bar. It is actually a reasonable way to make a progress bar for long-winded tasks that are fairly stable in duration.
I remember long, long ago when most of the programs I used didn’t have these pacifiers. As long as the bar doesn’t freeze for a long time, I’m relatively happy. I know that the delay is the computer’s fault and I’m not waiting because I didn’t retry when it froze.
Trust me, looking at a blank screen or static installation message is worse than an inaccurate bar. The uncertainty, it itches in your mind like bugses.
A similar thing is the progress bar that shoots to 100% and then sits there, without going away or saying anything. So is it finished or not? Who knows?
In fact, we use an animated GIF on the join pages for the AW site. As a user, I hate learning that kinda shit, but as a coder, it saved a week’s work, and does a good job.
the worst install i have ever done was a mcafee one we use at work. i am in IT. you double click the setup…and NOTHING comes up on the screen nothing! the only way to know its running it to double click it again which it will say its already running. you just wait a half hour and it tells you its done
And then there are things with “barber pole” progress bars… It’s constantly moving, but not actually moving to or from anywhere. Which I actually kind of like: If you don’t know how long something’s going to take, then at least admit that you don’t know, instead of telling me you’re 73% done.
