[Demonstration of a small progress bar and a large one at 100% and at the smaller size as seen from across the room]One important aspect of interaction design is determining typical usage patterns for your application. What many people overlook here, is that these patterns don't just happen inside your application, but may also be influenced by what happens outside, in the real world, in the user's home. As an example, let's take a feature that a friend of mine implemented in Toast 8:

As you are no doubt aware, Toast is a disc burning application. Most of the user interaction here is pretty straightforward: You drag files into a window, and then click a button to burn the disc. And this point is exactly where it gets complicated: when you burn a disc, your computer gets busy. Not only does it have to encode video content if you are burning a DVD, and decode the original data. After that it also has to write all that data that that was generated to a silver disc.

A lot of data is moved around during this, and you do not want to put additional strain on your machine, for fear of causing the CD drive to run out of data and creating a coaster. Of course, there is buffer underrun protection, but if your Mac starts thrashing, your backup CD could still become a coaster. So what many people do, is just leave the computer alone for a while and go to the other end of the room to do something else.

Knowing that the user does that is what gives you an opportunity to create a better user experience: Imagine the user is, for example, vacuuming the room, or cooking lunch, or reading a book. They will occasionally glance at the computer display, to determine whether disc burning has finished.

Now, today's progress bars are roughly 16 pixels tall. Not really suitable for reading from across the room. Furthermore, when the window isn't frontmost, progress bars actually turn a pale gray and become slightly transparent. This makes it a lot harder to read them from a distance, since pale gray and the white of the track merge into the background. So, what my friend did for Toast, was to create a custom progress bar control that was not only bigger and had stronger colors when inactive, but also showed different colors for the different phases of progress.

This not only made it easy for the user to spot the progress bar from across the room, it also made it obvious whether Toast was currently verifying the disc, or whether it was still writing the lead-in or whether it was actually in the process of burning a particular track.

[Toast 9's scross-the-room progress bar close up and at a distance]

As with any custom user interface, one has to be very careful here. There is a reason why progress bars turn pale in the background: all of the user interface is designed so that color and strong lines will draw you to the current, focused window first. Since Toast actually needs color to make the current phase obvious from across the room, it was decided to not have an animation in the progress bar, which would otherwise have overwhelmed the user interface while the user is sitting in front of the machine.

From what I have heard, this feature has been welcomed by the overall user community. Many of the professional users seem to be starting a burn job on one machine and then continuing to work on another.

I recently came across a backup application that not only used a small progress bar, but also had it on a blue surface. This didn't just interfere with the partly transparent progress bar in a background window, it also made it hard to distinguish the blue background from the blue part of the progress bar. It was hard to see where the bar started and ended, only the little white "unfinished" area was still clearly visible.

I sent the developer an e-mail with a suggestion for fixing this. If you are a developer, I encourage you to look at your progress bars. If any of them shows for a longer time, it might be a good idea to ensure that it can be read more easily from across the room. You don't have to go as far as the Toast developers went, but simply choosing the bigger progress bar size in Interface Builder, and making sure there is enough white space around the progress bar that it can easily be spotted, and its edges can easily be made out from a distance, would already help.