It seems that every Monday afternoon when I sit down to write this column, Microsoft Updater tells me that a patch for Microsoft Word is available. So every Monday afternoon, I dutifully download and install an update to Word. A thought occurred to me as I sat and waited the three or four minutes it takes for the update to complete.
I’ve probably spent more than half my time in front of a computer just sitting and watching progress bars.
All you DIY computer gurus know exactly what I’m talking about. Every time you download applications from the Internet, what do you see? A progress bar. Every time you have to apply software updates, what do you get to watch? A progress bar. Do you need to reboot your system for some reason? Guess what, another progress bar.
Of course, the intention of the progress bar is noble. Most of what a computer does is not visible to the user. The progress bar is how the computer says, “Hey, be patient! I’m working on it!” And back in the early days, we were glad see it. As a matter of fact, we designed our own progress bars to show off. Well, we never admitted that – the intent was to always “ensure optimal program performance.” However, the program always seemed to run better when integrated with a cool progress bar.
The classical progress bar possesses a couple of flaws, however. The standard left-to-right rectangle fill assumes that a process will run from beginning to end 1) at a reasonably constant pace, and 2) without error. In reality, poor software design, bad data and click-happy users tend to invalidate these assumptions. The resulting condition consistently ranks in the top three of the most frustrating computer issues – a stuck progress bar.
Software designers utilize several techniques to mitigate the occurrence of stuck progress bars. For example, the rectangular progress bar can be changed from “fill” to “bounce.” Instead of displaying progress from 0 to 100%, the bounce bar simply restarts in the reverse direction and repeats until the process completed. While the users won’t have any idea when the process completes, at least they believe the process is running.
Designers also use other forms to display progress. First popularized in the early-1990’s with the Mosaic browser, variants of the spinning icon are now ubiquitous. While more graceful than the angular progress bar, the spinner still only displays activity. While useful, a hung application forces the user to helplessly endure the endless rotations of the spinning wheel of death.
Interestingly, the behavior of the progress bar influences the user’s perception of application performance. A faster spinning indicator makes the application seem its running faster. A progress bar that accelerates toward completion gives the indication of accelerating performance. A progress bar that “empties to the left” feels faster than one that “fills to the right.”
Designers have spent a great deal of effort to make applications seem fast. Wouldn’t it be interesting to transfer these techniques to every day life? Specifically, what would happen if you replaced traffic lights with LED progress bars? Would wait times feel shorter if we watched a red bar empty? Would drivers feel more confident when approaching a stale green if they saw that the bar is three-quarters full?
Yes, I know what you are thinking. Traffic lights won’t matter when we all have driverless cars. But its still fun to think about.