[setr]

A progress bar doesn’t need to literally report precise progress — just that milestones/checkpoints are reached. Like that 1/7 microservices has completed.

Now, you do need to consider expected timing and weigh it accordingly else you’ll run into the 1-99% takes 1 sec, and then stuck on 99% for 10 min issue… but otherwise.

And if you can’t report that level of progress, then you’ve got other issues (namely that you yourself have no idea what the hell the system(s) is up to and working on at a given moment)

[pc86]

Kind of off topic but this assumes that the ideal progress bar should be a smooth continuous movement from 0% to 100% when I don't think that's the case. If you have a 100-step process, and the first 99 take 1 second and the last one takes 10 minutes, the progress bar should be at 99% for 10 minutes because the process is 99% complete, right?

[gryn]

different devs have done through history different methods implementing this. the real answer is context depend, who's the target audience and what do they want out of that progress bar.

you can have a progress bar that show the milestones + ETA. multiple progress bar + log messages box that shows what the background is doing, or you can just have single disconnected bar that's based on a timer based on what you estimated the task would take etc.

as user: - how do you know if the UI / process is stuck then or just taking ? - how much time is there left, you got other things to do after 5 more tasks like the current one and want to estimate a rough estimate when you'll be done with this.

[taneq]

What does a human want to know when they look at a progress bar? How long (or how much longer) they need to wait, typically. So yeah, the progress value displayed should ideally be the percentage of total time.