2 ms·

Writing a progress bar is basically still impossible. If you are doing a single slow thing like rendering or uploading etc then you can make a progress bar. Bu

Writing a progress bar is basically still impossible. If you are doing a single slow thing like rendering or uploading etc then you can make a progress bar. But if you are making something that has multiple phases and you want to use a single progress bar then that isn't goingt to progress nicely from 0 to 100 it's just impossible. You'll either have to make an overall progress bar for the different phases, or just indicate that this is phase 4/5 and the progress of that phase is 82%. This solves the jumpy progress bar issue, but doesn't solve the underlying issue of actually showing an estimate of time remaining. You have no idea whether phase 5/5 is going to take 1 second or 1 minute. When a progress bar stops at 99% it's just because some final task that was expected to not take very long, did. E.g. it could be deleting a file at the end of some install process, and that for some reason blocks. There is obviously no way of knowing the actual time that will take without trying it, at which point it's too late for the progress bar to adjust of course. So: we'll have general artificial intelligence on smartwatches, before we have smooth multi-phase progress indication (because that's never).

moring 4y ago
> There is obviously no way of knowing the actual time that will take without trying (...) How is that obvious? Deleting a file doesn't just block for no reason. The OS (usually) or disk hardware (rarely) are the ones that decide to block it, and they have the information needed to know how long it will take. What actually happens is that the advantages of showing a correct progress bar simply don't justify the complexity needed for it, and a decision to show a crappy incorrect progress bar is made.
- alkonaut 4y ago
  Let's take another example. E.g. if you have a progress bar for doing a set of 5 git operations you don't know whether the 3rd might start some housekeeping. For some tools (such as git) it might be possible to force this automatic housekeeping off in order to make a predicable progress bar. But in others it might not be. In some tools you may be able to predict if it will happen, and in others maybe not. Another example (from the real world this time): I make a progress bar for an iterative optimization of an design in a program. The number of iterations until the design completes can't be reliably estimated. It's not completely underterministic of course, but the complexity of making that estimation isn't just high, it's likely to be so high that it approaches the complexity of the optimization itself.
  - moring 4y ago
    Your second paragraph is basically what I meant: The complexity is just too high. This is especially true when downloading data from the internet is involved. But the first example, git housekeeping, depends only on information readily available locally. git could just give this information to any calling program that needs it, but my guess is that nobody thinks that progress bars are worth it. Actually, in today's world, I'd be happy if progress bars (or even indefinite loading indicators) would even show me when the process has crashed and won't ever finish, but they'll happily show "progress" that will never finish.
dylan604 4y ago
>Writing a progress bar is basically still impossible. So then why try it? I would much rather see some sort of update like when you run "yum update" and it spits out 3/15, 11/15, etc. You don't have to show all of the lines scrolling, but you could do similar to a "\r" instead of a "\n" in the progress window with an update that is very intuitive. You know how many steps you must take to accomplish the user's request. I don't need to see how long each step is taking per se, but if you showed me the total number of steps and show each one ticking off would be much more useful than the typical blue bar race.
- jstarfish 4y ago
  Your alternative was already attempted with Windows 98. During startup, the console would display the modules after it loaded them. People attributed failure to load the next module as a failure of the last one visible. This ended with mup.sys being blamed for every failure.
  - dylan604 4y ago
    I don't know the specifics to mup.sys you mentioned or Win98 at all, but isn't this pretty much the same for every OS/application debugging? The message can't be updated to the screen until the process has completed. I thought it typical debugging knowledge that you look at the processing after what ever the last completed message was. It's kind of common sense when you actually think about the logging process.
  - midoridensha 4y ago
    >During startup, the console would display the modules after it loaded them. People attributed failure to load the next module as a failure of the last one visible. Then why didn't they print a message before loading a module? This is really simple stuff, and would immediately show the problem. This is pretty normal in printing to logfiles in software: print messages both before and after an action is taken, so if it gets stuck in the action, you see that it never succeeded though it was started.

moring 4y ago

> There is obviously no way of knowing the actual time that will take without trying (...) How is that obvious? Deleting a file doesn't just block for no reason. The OS (usually) or disk hardware (rarely) are the ones that decide to block it, and they have the information needed to know how long it will take. What actually happens is that the advantages of showing a correct progress bar simply don't justify the complexity needed for it, and a decision to show a crappy incorrect progress bar is made.

alkonaut 4y ago
Let's take another example. E.g. if you have a progress bar for doing a set of 5 git operations you don't know whether the 3rd might start some housekeeping. For some tools (such as git) it might be possible to force this automatic housekeeping off in order to make a predicable progress bar. But in others it might not be. In some tools you may be able to predict if it will happen, and in others maybe not. Another example (from the real world this time): I make a progress bar for an iterative optimization of an design in a program. The number of iterations until the design completes can't be reliably estimated. It's not completely underterministic of course, but the complexity of making that estimation isn't just high, it's likely to be so high that it approaches the complexity of the optimization itself.
- moring 4y ago
  Your second paragraph is basically what I meant: The complexity is just too high. This is especially true when downloading data from the internet is involved. But the first example, git housekeeping, depends only on information readily available locally. git could just give this information to any calling program that needs it, but my guess is that nobody thinks that progress bars are worth it. Actually, in today's world, I'd be happy if progress bars (or even indefinite loading indicators) would even show me when the process has crashed and won't ever finish, but they'll happily show "progress" that will never finish.

dylan604 4y ago

>Writing a progress bar is basically still impossible. So then why try it? I would much rather see some sort of update like when you run "yum update" and it spits out 3/15, 11/15, etc. You don't have to show all of the lines scrolling, but you could do similar to a "\r" instead of a "\n" in the progress window with an update that is very intuitive. You know how many steps you must take to accomplish the user's request. I don't need to see how long each step is taking per se, but if you showed me the total number of steps and show each one ticking off would be much more useful than the typical blue bar race.

jstarfish 4y ago
Your alternative was already attempted with Windows 98. During startup, the console would display the modules after it loaded them. People attributed failure to load the next module as a failure of the last one visible. This ended with mup.sys being blamed for every failure.
- dylan604 4y ago
  I don't know the specifics to mup.sys you mentioned or Win98 at all, but isn't this pretty much the same for every OS/application debugging? The message can't be updated to the screen until the process has completed. I thought it typical debugging knowledge that you look at the processing after what ever the last completed message was. It's kind of common sense when you actually think about the logging process.
- midoridensha 4y ago
  >During startup, the console would display the modules after it loaded them. People attributed failure to load the next module as a failure of the last one visible. Then why didn't they print a message before loading a module? This is really simple stuff, and would immediately show the problem. This is pretty normal in printing to logfiles in software: print messages both before and after an action is taken, so if it gets stuck in the action, you see that it never succeeded though it was started.