I was sort of late in discovering where, for instance, the CD converting progress bar got hidden in the Music app…
Now I discover something a bit odd: The latest security update download started out with a fully loaded progress bar (software update has never downloaded updates in the background for me)
It is a bit odd to see a 2 gb file indicate by the blue bar that it has fully downloaded when there is no activity or sign that it has and no indication it wants to proceed
There was a time when a progress bar tried to indicate how far a process had gone towards completion. Then like so much of the interface, it stopped, almost as if Apple had moved on from say, representational art to surrealism. Now the progress bar is a virtue signal that say “I’m trying to do better, I really am” but no one believes it or pays much attention. All you know is that when it goes away, the process has a 50% chance of having completed, and an equal chance of having failed.
Mind you, even that is rather better than the truly perverse progress bar/graphs shown whilst CCC 6 does its thing. Now that is wild!
1 Like
To be fair, progress bars were always massively inaccurate, so just saying “a task is in progress” is roughly as informative as a “a task has 32 minutes, no 2 minutes, no 14 minutes, no 12 minutes, no 3 minutes to finish.”
The problem is that progress bars have to predict the future and just because something is happening at a certain rate doesn’t mean it will continue to do so.
1 Like
I guess for things like software updates progress bars are somewhat useless and on Mac usually in the users favor in the sense that a 30 min predicted install process usually only takes a third or quarter of that time anyways.
On the other issue originally posted, I found that the inactive Apple icon in the main information bar during file conversion just led me to believe there was no activity …
Sure they were inaccurate, but at least you knew something was happening.
And here I thought it was just Apple.
I always had fun explaining to my clients why this would happen, and encouraged them to appreciate the entertainment value.
I don’t really care how accurate progress bars in absolute terms. I do care that there is progress.
Users need to know that they are not being ignored.
Progress bars can not predict anything, only indicate activity. Humans use changes in indicators to understand current activity. This understanding then can be used to estimate the future.
2 Likes
In regards to predicting… not to belabor matters…
It was always my understanding, or assumption based on observation, that the progress indicating system was not predicting the future but actually calculating the system read and write speed and then adjusting the progress “predictor” appropriately based upon the task at hand.
I have often seen a file transfer initiate i.e. predict a 2 hour estimate and then change the general estimate shortly there after
Progress-bar APIs usually give apps the ability to set the scale of the bar (minimum and maximum values) and to set a value. The actual value it is set to depends on the app itself. For Apple’s API, see: Progress indicators - Status - Components - Human Interface Guidelines - Design - Apple Developer
That having been said, there is no perfect way to operate a progress bar for non-trivial operations.
-
For something simple, like processing a long list of data, you can just set the maximum value to the number of data items and set the position to your place in the data (or the number of items that have been completed). Which will be pretty good, assuming it takes about the same amount of time for each item.
-
For something like a file download, you’ve got the problem that you don’t know what the data rate is going to be. You can set the bar to the number of bytes left to transfer, but that doesn’t give a time estimate. You can compute the data-rate-so-far by dividing the amount received by the time elapsed and then divide the amount of data remaining by that value. But it will quickly become inaccurate if the data-rate has any significant speed-ups or slow-downs.
I’ve seen some implementations that base the time estimate on a running-average (e.g. of data received in the last 5s instead of over the course of the entire download), but that just substitutes one problem for another. If the data rate varies a lot, you’ll see estimates that thrash around all over the place.
-
For application installers, I think it makes more sense for a progress meter to represent a count of files unpacked/installed. Either just a count of files, or scaled by relative file sizes (e.g. so a 1K file doesn’t advance the meter as much as a 100K file).
The problem here is that the installer app usually only gets a chance to update the progress meter between files. So if a single large file takes a long time, the meter won’t move until that file completes, and then the meter will jump forward a lot. And we’ve all seen this.
It could (in theory) be solved by using a file-copy API that provides periodic callbacks, which can be used to update the progress meter, but such APIs are not common. (e.g. Apple’s copyItem() function doesn’t - it returns the success/fail status after the copy completes, and nothing else.)
3 Likes
I don’t remember which system it was, but at one point it was fairly common for the progress bar to hit the end and keep going off the side of the display.
Now that would have probably been more accurate and understandable to the user, in several different ways.
Of course it’s often a challenging—if not impossible—task to reliable estimate how long an operation will take. People get way too bogged down on this.
If you can’t give a decent time estimate, at least you can usually give some kind of idea of how far through the task you are. Setting the maximum value to the number of items to process and the position to your current place in the list will work very well for most purposes—it may not show how many minutes there are to go, but at least you can see progress being made.
For operations like a recursive directory copy, where you don’t even know how many files you have to copy (let alone their size) until you’ve scanned through all directories—and where, if the directory is on a networked drive, even the directory scan may be time-costly—then, yes, a progress bar becomes very, very challenging.
1 Like
And, even despite inaccuracy, progress bars are preferable to spinning cogs or whatever, because we’ve all seen those spinners stall forever. At least with the progress bar you can see some…progress