why loading bars jump around instead of smoothly increasing percent?

132 viewsOtherTechnology

3%. 5%. 34%! 97%! 97… 98…

In: Technology

24 Answers

Anonymous 0 Comments

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 are viewing 1 out of 24 answers, click here to view all answers.