3%. 5%. 34%! 97%! 97… 98…
In: Technology
Tom Scott to the rescue:
____
Windows & Android phones have so many different variations for their internal components that it’s difficult for the software to calculate. Macs & iPhones are a bit better at having an accurate progress bar, but still not always perfect.
File sizes and a drive’s Read speeds.
For example, you need to move 3 boxes; small, medium and large in size.
The first box has 10% of your stuff. 10% done.
The second box has 30% of your stuff. 40% done.
The last box has 60% of your stuff. 100% done.
Loading bars are entirely a psychological construct. They aren’t tied to anything specific in terms of progress they exist purely to show the user that whatever process it is, be it an install or a patch or whatever, is making progress and isn’t just stalled.
Anyone that’s run complex cmdline commands knows how much of a pain it is to hit Enter and sit there seeing a blinking cursor and just waiting there for the task to finish wondering if the task is frozen or not.
Status Bars and the animated gif of the circle you get on phones during updates is just there to say “I’m working on it, be patient”
The status bar progress has little to do with the actual amount of time needed to do a task.
0-25% might represent finishing copying files that took 5 minutes while 26% to 60% was writing registry keys that took 10 seconds, and 61% to 90% was a checksum and copying a shortcut to the desktop.
It’s all pretty arbitrary, and the speed of the install varies from system to system anyway.
How fast files download and copy is entirely dependent on things like your internet speed, hard drive speed, etc which varies from machine to machine.
For a game, it would be because loading the mapping, the models, the textures, and lighting.
The amount of time spent on each of them isn’t equal, and it can’t tell how much it has loaded, until after it has done that. the textures themselves could cause the jump from 12% to 74%
Compare to downloading a file, where it is know how big it is, and so can know how much of it, it has recieved.
It has to do N steps to complete the load, but each step may not be the same size. And it is easier to just update the bar after each whole step rather than every 1% (or x%) of total work which may be just a fraction of a step.
Because progress bars can hide different things behind them that vary in how fast they are relative to one another from computer to computer. Downloading a file can be network dependent. Unpacking a compressed file is CPU dependant. Writing the output to disk is disk dependant. How do you divide those 3 tasks in a progress bar?
For an analogy, think about being in a queue of people at a bank. Each person in queue is going to take a different amount of time when they get to the teller. Someone depositing one cheque is different from someone opening an account.
Some parts of a process take longer than others. For example, duplicating twenty 1MB files is noticeably quicker than duplicating one 20MB file. So if you put those together into a 40MB file transfer, then the first 50% will take less time than the last 50%, and this is reflected by the progress bar.
It’s possible to have a smooth loading bar but it’s more complex coding for just cosmetic benefit. The reason the loading bar jumps like that is because it’s only updated after each chunk is loaded, and the chunks might not be the same size.
If you wanted a smoother bar, you’d have to break those chunks into smaller ones, or have some way for the chunk loading to communicate back to the progress bar to update it.
Every loading process is a little different. The developers have to fudge it most of the time.
One time I was writing a program to scan company hard drives for certain files. I had to write a progress bar for it. There’s no magic code in Windows for “look in these directories for these files and also give me an update every 1% progress you make”. Instead I just have “give me all the files in this folder”, “give me all the folders in this folder”, and if I want a progress bar I have to do it myself.
So it sounds like it’s easy, right? Just ask for all the folders and files, count them, then make the progress bar based off that, yeah? Well… it turns out doing that took as long as *just doing the work*. So if it was going to take 5 minutes to search, it’d take me 5 minutes to count the files, THEN about the same amount of time to do the search. That’s no good.
What I figured out is getting the list of *folders* was pretty quick, only about 10 seconds. So if I used the folders as my count for the progress bar, I could get somewhere. But that ended up being kind of lopsided. Some folders had 1,000 files in them and took a long time to search. Other folders had 1 file in them and went really fast. So my progress bar would be “chunky”. Sometimes it moved fast as I went through the small folders. Other times it moved slow as I went through the slow folders.
So I added other things to the UI so users could tell something was happening, like a counter of how many files I scanned. That way, if I hit a “chunky” folder, the user would see “Scanning files in folder blah, 45,687 so far…” and understand this one would take a bit. The other folders went by so fast the text was a blur.
Most stuff with a progress bar is like that. A lot of times there’s no good way to tell you “How close are we?” or “How long will it take?” It’s not like Microsoft just neglects to give us the tools, it’s that a lot of things work like my case: it takes as long to estimate how long it will take as it does to just *do it*.
So sometimes I know my program has like, 4 steps. They may be “chunky” and take a long time. But there may also be no “steps” smaller than those 4. So, well, I divide the progress bar into 25% intervals and let the user know they’ll move kind of slow.
We do what we can. Often that’s not a lot. A lot of devs hate making progress bars for this reason.
You have to drive to the store, buy milk, then drive back. Let’s make a loading bar. You start at 0%.
Driving to the store goes pretty smoothly but there’s normal traffic. 0%… 10%… 20%… 30%… You get there. 33% done.
You go inside… 40%… find the milk… 50%… get in line… 60%… oh wait, the lady at the front is paying in pennies. I guess still 60%. Okay she’s gone, but the guy after her had his credit card declined. I guess 62%? Oh now they need a manager. 63% maybe? Okay finally it’s done, 66%.
There’s absolutely zero traffic and you make every light on the way home. 80%, 100%.
Of course, if you knew ahead of time how long each segment would take, you could have accurately predicted your real percentage in terms of time, but there’s no way to know ahead of time.
Latest Answers