There is an art to making good progress bars. It takes a lot more time and effort than anyone is ever willing to put into it, and as a result they are often overlooked.

There is something inherently pleasing about watching a good, well-designed progress bar load to completion. I've thought about this quite a bit before, and for some time, I've become rather obsessed with them. I would download and install a bunch of things I didn't need just to watch progress bars. I share my conclusions below.

The motion of an ideal progress bar should resemble the plot of a novel. It's not terribly interesting to watch a progress bar zip right through to the end without encountering a hint of difficulty along the way. Would you enjoy reading a novel that didn't have a plot or an antagonist? That would make for a boring novel!

The progress bar should start off confidently, ramp up some speed, but slow down around 15-30%. It doesn't mean stop - you don't ever want a progress bar to stop entirely - but it should start to visibly struggle. It should not stutter or jump around violently or go backwards or anything like that, but its progress should become unsteady. It should come in waves. These waves should build up overtime. It you got some things you need to load that you're uncertain about time-wise, the 30-80% range is the ideal time to load those things.

The climax portion is the most important part. This is where shit gets real. You should slow that sucker to a crawl (but don't you dare stop it entirely or I will find you). If you're printing out any sort of details about what's loading, this is the part where you start spitting them out rapid-fire. Make it up if you have to - write you're "Reticulating splines" for all I care - if you do it right, I won't have time to read it anyway. If you're thinking about writing to the hard drive, this is the time to do it - make some noise with it. If you don't have anything you need to write, implement a hard drive stress test algorithm and run it during the 80-95% range.

Don't you dare let me down in the last 5%. There is nothing more disappointing than a progress bar that just disappears when it reaches 99%. If you do this, I will go to your house and tear out the last page of every book you own. If you get nothing else from my rambling, at least remember this, because it should be relatively easy to implement, but it needs to be done deliberately: Pause - for just a brief moment, pause when you reach 100%. Will you promise me that you will do this the next time you implement a progress bar? Just put a Thread.Sleep(500) in there once you get to a 100%, that's all it takes - but it makes all the difference in the world. Don't make it too much shorter than 500 ms, or it will look like it just disappeared, but not too much longer, because you never want a progress bar to hang. A half-second delay to give some closure to the ordeal, that's all. Please do it.

So there you have it. I hope we can all walk away from this being slightly more attentive to these finer details of the user experience and give progress bars the attention they deserve. Thanks for reading.

I think you need to get out more ;)

Nah, he can "play" this

The crazy thing about progress bars is that their very presence slows down the process that they are informing you about. I use one in my new game for the process of loading file & folder names inside a given folder. But the process is much faster if I don't display the progress bar.

The crazy thing about progress bars is that their very presence slows down the process that they are informing you about. I use one in my new game for the process of loading file & folder names inside a given folder. But the process is much faster if I don't display the progress bar.

You're probably doing it wrong then. You shouldn't be updating the progress bar hundreds of times a second - only update and display it once there has been sufficient progress for it to display something new, and if the task is sufficiently long that it deserves a progress bar to begin with. Also, you probably don't need pixel accuracy on a progress bar - even the old Windows 95 progress bars were good at what they did and had sufficiently large discrete steps that it was only necessary to redraw them a handful of times:

Inside the code logic, you should only be updating a variable called "progress" or something like that, then redraw the progress bar component if drawing it would cause the currently displayed progress to change :)

Sure. But a lot of the time when stuff freezes, or the window becomes unresponsive, those UI elements keep ticking away.

I test software at work, and one project (an iOS app) had all load indicators fail one build. Trust me, that was hellish to use as it constantly felt like the app had locked up and crashed. (Something that it frequently done in pervious builds due to being so early in development.)

To share some recent experience!

We did some user testing when implementing an installation bootstrapper (installing tons of big packages) last autumn, and when there was both a normal progress bar and a spinning wheel at the side the users felt that the installation was faster than with just a normal progress bar. And a lot faster than only a spinning wheel. The worst user experience though came from the indeterminete progress bar though, which is interesting because it's as useless as the spinning wheel. But maybe not as pretty!

I use a progress bar but only update it between stages. I don't see the need to update it for every file loaded, only when a particular step in the initialization stage is complete. In a way it is a 'lazy' update but it does let the user know something is actually progressing. I don't bother with showing what is going on internally but it does show about 30 steps worth. Since I've implemented that perceptually it seems as if the loading time is much shorter even though I know it is a few ms longer than before due to the draw code.