There are certain elements in computing that, despite the years, have never managed to improve. At the top of the list are printers, historically problematic and expensive... but progress bars aren't far behind. Imprecise, erratic, and unreliable, progress bars seem to drag every negative aspect. Why is that? Tom Scott explains it in a short video.
We've all seen them. We all know their variants. A bar that grows from left to right, an increasing percentage indicator, or a fixed amount of megabytes to transfer. Progress bars have received multiple aesthetic adjustments, but their underlying problem remains intact: they don't work that well.
Obviously, this isn't something new or recent. MS-DOS veterans remember those bars that seemed frozen on screen until they suddenly sprang back to life, and we'll never forget the "five longest minutes in the universe" when installing old versions of Windows. So what's going on? Why don't developers fix the problem?
The "Problem" with Progress Bars
Tom Scott explains it wonderfully in one of his videos: The progress bar is necessary to visualize (in a way) the work the computer is doing, but that work is divided into multiple phases whose speed can vary without warning. Unlike a progress bar in a video (which is essentially a single task), a program's bar represents things like downloading files, decompressing them, writing them to storage, and configuring the operating system.
And that's when precision flies out the window. File download depends on how fast and/or stable the internet connection is. Decompression is up to the installed processor and the amount of available memory. The speed for writing files can have enormous differences whether it's a hard drive or an SSD, and not all operating systems are in the best condition.
https://old.neoteo.com/por-que-no-puedes-llamar-a-un-archivo-con-en-windows/Popular alternatives like counting the number of files or the amount of megabytes to copy improve things a bit, but the progress bar's advance won't be smooth either. Some files are naturally larger than others, and copying many small files takes longer. And speaking of time, a clock with "seconds remaining" is at the mercy of spontaneous system changes. For example, imagine a program takes 60 seconds to copy a file, but Windows 10 decides to download updates in the background. Guess what happens to those 60 seconds...?
One of the options Tom proposes is simply calculating an average, that is, taking as a reference everything the program did in the last ten or twenty seconds, and developing an 'estimated time' with that data. Thus we arrive at a fundamental truth about progress bars: They don't need to be perfect or advance smoothly. Indicating 'progress' is enough.
