At least in the early days of Mac OS X, the progress bar displayed at bootup was quite clever. At every boot, the system would record how long it took to get to the login screen, and at the next boot, the progress bar was animated to take exactly that long, regardless of what was actually happening in the background.
I also recall reading about this and liking it. :)
I remember it upsetting at least some people, because it also does the thing where if it gets to 95% of its estimate and isn’t done yet, it stays there until it is, no matter how long that takes…
I still think it’s the right strategy for a lot of things.
Or could it show something like a line graph instead of a progress bar, the previous boot percentage vs time and the current boot percentage vs time, if this boot is quicker we end before the last point on the previous line, if we are going slower the graph widens and our line continues past the previous line.
That’s a brilliant cheat. I was trying to think of a better scheme but couldn’t. The one flaw I could see happening is it hangs after they install new applications. Could reduce the impact of that by adding an error margin in estimate as pilkch says that only happens when new apps or updates come in. Then, it might be perceived as finishing early instead of freezing at 90+%. At the least, they get visual sense of progress being made.
I agree that that’s a reasonable measure, but it doesn’t really solve the problem, because the underlying problem is to allow users to feel calm and in control and maybe even make plans (“coffee now or later?”), while not being too heavyweight a UI… There are a number of choices around how to present and explain the steps that haven’t been reached yet, but I don’t think there are any that don’t place a high demand on the user to either memorize how this whole thing goes, or make sense of a cluttered display.
Interesting that you mention that the goal is to estimate time remaining. I’ve thought that many progress bars, especially those on mobile devices, are not meant to show how long something will take but that something is still happening. This probably stems more from the history of how computers behaved back in the early 2000’s as well as how mobile devices behaved back in 2007-2011. I clearly remember many apps just hanging and locking up. Even today, we still see applications on macOS beachballing. To the user, they are unsure if the app is supposed to hang like this because it’s thinking or if the app is stuck and can’t move forward anymore. Perhaps this is more of a distinction between indefinite progress indicators and actual progress bars.
At least in the early days of Mac OS X, the progress bar displayed at bootup was quite clever. At every boot, the system would record how long it took to get to the login screen, and at the next boot, the progress bar was animated to take exactly that long, regardless of what was actually happening in the background.
I also recall reading about this and liking it. :)
I remember it upsetting at least some people, because it also does the thing where if it gets to 95% of its estimate and isn’t done yet, it stays there until it is, no matter how long that takes…
I still think it’s the right strategy for a lot of things.
It could be pessimistic, adding 10-20% say.
Or could it show something like a line graph instead of a progress bar, the previous boot percentage vs time and the current boot percentage vs time, if this boot is quicker we end before the last point on the previous line, if we are going slower the graph widens and our line continues past the previous line.
That’s a brilliant cheat. I was trying to think of a better scheme but couldn’t. The one flaw I could see happening is it hangs after they install new applications. Could reduce the impact of that by adding an error margin in estimate as pilkch says that only happens when new apps or updates come in. Then, it might be perceived as finishing early instead of freezing at 90+%. At the least, they get visual sense of progress being made.
[Comment removed by author]
I agree that that’s a reasonable measure, but it doesn’t really solve the problem, because the underlying problem is to allow users to feel calm and in control and maybe even make plans (“coffee now or later?”), while not being too heavyweight a UI… There are a number of choices around how to present and explain the steps that haven’t been reached yet, but I don’t think there are any that don’t place a high demand on the user to either memorize how this whole thing goes, or make sense of a cluttered display.
[Comment removed by author]
Yes, that’s fair enough.
Interesting that you mention that the goal is to estimate time remaining. I’ve thought that many progress bars, especially those on mobile devices, are not meant to show how long something will take but that something is still happening. This probably stems more from the history of how computers behaved back in the early 2000’s as well as how mobile devices behaved back in 2007-2011. I clearly remember many apps just hanging and locking up. Even today, we still see applications on macOS beachballing. To the user, they are unsure if the app is supposed to hang like this because it’s thinking or if the app is stuck and can’t move forward anymore. Perhaps this is more of a distinction between indefinite progress indicators and actual progress bars.
Halting problem? :)