The entire purpose of a progress bar is to let the user know how much longer he or she has to wait till the program finishes doing whatever it’s doing. But most progress bars I have come across are useless. Have you not seen a progress bar that randomly switches between varying lengths of time from 2 hours to 5 minutes, when the actual file copy operation took 10 minutes?
What’s the use of progress bar if it can’t show the actual progress? Having the bar filled up to 99% and then waiting for an eternity gives users a false hope of completion and returning back to work, when it’s not. I have always wondered why programs do that.
Recently I came across a story on The Daily WTF that has me convinced that most developers include the progress bar entirely for cosmetic purposes.
"One of our desktop applications has a progress bar in it," Bryce N. writes, "and as I was working more and more with the code, I noticed that the progress bar would progress to a seemingly random part in the bar, but never past the halfway mark. This would probably be ignored, if it weren’t for the fact that I noticed that my breakpoints would only be hit when the bar reached the ‘random’ mark."
"While I was trying to discover why, I found this in the code:"
/* There is really NO eloquent way of calculating what the progress of a given method/task will be. One task may be downloading or copying a file while another one might be grabbing huge chunks of data for file creation. Since we want to see a progress indicator but can’t determine this value, we’ll simply play with it so it has the
appearance of running; (i.e. we’ll take it to 50%, execute the task, then come back and finish the progress upon completion.) This is a Microsoft STANDARD… I’m sure of it!