Why do computer progress bars suck as much now as they did back in the ASCII days?

I’ve been spending a lot of time lately recompiling VHDL programmable logic code for a new spectrometer. The Xilinx Vivado tool that I’m using has a log file that shows the program’s progress as it does all the work. This is quite helpful, even though there’s no estimate of the total time. (Its partner program Simulink has nothing at all like this; it sucks.)
Occasionally it takes half an hour to get through one small portion of the process, but at least I know exactly which part is stuck.

2 Likes

If things are not the same length, then you simply need to account for item size in your percentage.

If they are not known in advance, then a progress bar is the wrong paradigm for what you are doing. Try a checklist or bullet-points. Don’t cram a school bus into a one-car garage.

I mean: What does it mean to say you are 30% done from an unknown number of items? That’s just silly.

2 Likes

people talking about the problem is people learning about the problem. i don’t see what the problem is.

and, as a sometimes software engineer, i completely agree with the upthread defrag correlation. show what the tasks are, and approximately how large, and let the user see the progress for themselves.

for short tasks that will slow things down, so some abstraction does have to come into play. i definitely think the newer windows copy tools are a big improvement, and they generally let you open the drop down to see what’s going on if you want. ( not with nice file size visualizations granted )

definitely agree with the first part. curious, could have install shield used user reporting to give better estimates to later users.

feels like if you could data mine the content of a package vs the state of user machines you could get good estimates.

i just think nobody’s going to pay for that as a feature, and that’s why nobody worries about it too much.

there’s a level of good enough that’s all that matters

eta. yeah. this. that’s why there are so many spinners these days, and windows updates now say things like “almost there” instead of 2 minutes left.

i do like orders of magnitude though. id give a lot for a spinner that morphed between images of a bed, a four course meal, a sandwich, and a cup of coffee.

how long do i have. ish.

5 Likes

After 20 years of working with end users - anyone from the general public to accountants and business users to the world’s foremost scientists - I have learned a very sad, almost heartbreaking thing:

They. Don’t. Care.

They generally don’t want details; put them on a hidden pane if you want to, but the vast majority don’t care. They don’t want an estimate to completion; they don’t want details as to what is going on right now. They just want a nice little bar that goes from left to right to reassure them that something is still happening; and if that is going to be slow, do a nice little spinning ball or some blinking lights or something like that to let them know that the computer is still doing something.

A very small percentage of people will like a running log or something like that; it may be worth putting it in a separate, default hidden panel or something. If you are writing for other programmers or other computer people, there is a higher percentage chance that they will like it.

But for the most part, these details will just confuse and anger your end users. They will feel like they should know what it is doing, and they won’t. They are probably already a little anxious about whatever is taking so long; the progress bar is there to reassure them that it is still going on, and that there is an end in sight.

Even if you don’t know how long something is going to take, or how many somethings you have to do… it might be better to fill the bar, then blank it and start over again than to not update until you know. That bar growing makes people happy; while they will be sad if they have to “start over”… they will at least see progress and know that the process is still working.

8 Likes

You are right, most people don’t care. They just want to know something is still happening. Unfortunately, too many times these days a process can fail and leave you with an infinitely spinning doodad that keeps you in a permanent state of expectation until you finally give up and kill the program, or entire machine.

4 Likes

Without going down too deep a rabbit hole, the majority of the installers being built by customers in my time there were *.msi based. Meaning, you had to use whatever engine framework Microsoft had built which really wasn’t that extensible in the area of the time estimates:

The other script engines didn’t provide this kind of extensibility either, but at least InstallShield could in theory have implemented it.

I don’t really recall much in the way of customers asking for better time estimates. Therefore, nothing got built. Probably the same for Microsoft as well - just didn’t get enough people asking for it to prioritize over other features.

1 Like

23 Likes

Well, I liked his video. And the ending made me laugh out loud.
I’ve been there. I’ve had to program progress bars. He’s right. The game is not worth the candle. So long as SOME progress is being made, that’s enough.

1 Like

I would agree that this is a betrayal of the user’s trust; don’t do this. (Even though it is easy…)

Solves this problem, and introduces about 30 more.

1 Like

gad

6 Likes

When Jean-Louis Gasée was making Be, the OS that almost became Mac OS 8 until Apple bought NeXT instead, he did make a note that adding animations slowed down the OS in terms of actual benchmarks, but test users said the version with the animations felt faster.

People like feedback. It reassures that the system is still working and hasn’t frozen up.

12 Likes

That is one thing that Ubuntu’s updater has done very right, in my opinion. By default, you get the simple progress bar; click “Details” and you can watch apt doing its thing.

4 Likes

But I don’t care what the computer is doing, just that it is eventually going to let me continue, and I would like to know approximately how far. A checklist with more than a small handful of items is pretty much useless and at best makes the user just estimate % done. A one line listing of the current task, ideally in a reassuringly technical but not too technical tone can also work to at least show something is going on, but doesn’t convey any real information, it is just a variant on a spinner wheel.

Well, they can be items whose size isn’t known in advance like downloading a long list of files, where the sizes aren’t known until you start the download. Also, if the tasks are heterogeneous such as a combination of disk IO, CPU, and network access then even if you know exactly the tasks the relative time may vary from computer to computer by quite a bit based on hardware or configuration. It’s also possible to have a known lists of tasks, but then to discover more tasks as you go.

All of those are reasons why progress bars are imperfect, and can be downright terrible in some situations. But often they are pretty good – even when the assumptions behind them are clearly wrong, they mostly kind of work. So just eliminating them doesn’t seem reasonable.

I don’t think they should be eliminated, just not used in a bunch of situations where there are probably better things to do.

We don’t use cards. Instead, we use a paper tape.

If you’re running a barcade or an internet café, and you don’t at least consider calling it “The Progress Bar”, then you’ve wasted your entire business.

10 Likes

I once wrote a rant about waiting after the progress bar reaches 100%. This is due to mindless rounding. Progress values should be truncated, not rounded to the nearest percentage point.

Likewise, a countdown clock shouldn’t show 0 when there’s a half second left.

5 Likes

2 Likes

I’d’ve thought this was a rather obvious consequence of the Halting Problem. Kinda disappointed the video didn’t mention it.

3 Likes