[yokohummer7]

> I often would use the mouse cursor to 'mark' the position of the loading bar (we really are spoiled for speed these days).

This is just me, oh my gosh. I thought I was the only one who did that. But now I come to think about it, it can't be true.

It has been a really long time since I used that technique last time...

[johnchristopher]

What ? I still do that at least once a week/month.

Last time it was for the linux dropbox updater, last week.

I am also a fan of using another window so I can use the mouse and still have a marker to monitor progress.

[Swenrekcah]

I do this all the time too, but unfortunately many processes today only go around in circls instead of showing the actual progress.

[woodrowbarlow]

to be fair, "actual progress" is almost always a misnomer anyway.

[wongarsu]

When I implement progress bars I most often implement "pessimistic progress", so "considering all timeouts, worst case we are 46.5% (of the time) to some result", with an update every few hundreed milliseconds. As possible mix in data from completed subtasks.

Nobody ever complains if the process suddenly speeds up because progress was made before the timeout, as long as your initial estimate wasn't absurd (looks at Windows Explorer). Even a naive progress bar counting down the 60s timeout is more informative and satisfying to watch than an endless spinner.

[delinka]

Absurd initial estimate? All of the estimates tend to be absurd.

Done in 30s ... I mean 15min ... ah, 10s ... 1hr 7min ...

Oh, come _on_ ...

[Nition]

Windows 95/98 used to occasionally do some particularly insane estimates. I took this screenshot many years ago of copying a tiny NetHack install between drives: https://i.imgur.com/q7tc9R1.png

[mkd1964]

We used to call these "Microsoft Minutes"...

[DoubleCribble]

I find the Progress bar is usually about as accurate as the Time Remaining calculation. Both are better than nothing but more of a fiction than reality.

[inlined]

True! I know some of the people involved in the windows update bar. Since cpu and dusk are so different across devices it’s hard to know actual time it will take. Instead teams divided their packages into theoretical weights and the progress bar showed the percent of total “weights”. That’s why it can be choppy is packages with few subdivisions have little to interpolate.

[derefr]

With a process that happens on regular intervals like a Windows Update, I always wondered why the system doesn't store metrics on how long the process has historically taken on previous runs, and then just uses a weighted average of historical times as a time-based total estimate, converted into a divisor for work-based progress estimates (i.e. if previous runs took 60 minutes on average, then progress at 25% would say "45 minutes remaining", then if it suddenly jumped to 50% would immediately say "30 minutes remaining." Even if they're choppy, those time estimates would actually be correct if you sampled and averaged them.)

[snupples]

Not sure if anyone's mentioned this yet, but the old original Mac OSX boot screen had a progress bar that was based on the exact length of the previous boot time.

[delinka]

Progress indicators that moving perfectly and steadily are probably time based, but I'd have thought they've always been work based. Example: you know you have to copy 20GB across the network; update the progress bar with 'percent of data complete' periodically (on a timer, in the byte copying loop, whatever.)

I've seen dual progress bars: one for "overall progress" (each one of five tasks fills this bar 20%) and one for the current task (maybe downloading, maybe unpacking, maybe copying, maybe waiting for hardware to reply...)

[nitrogen]

I've written progress bars that combine all of the above. Each sub-task had a weight though, and adaptive interpolation was used to animate the progress bar between chunky updates from less granular tasks based on how far they usually increment over which time interval.

[ohaideredevs]

We pushed "progress bar" data to the client via SignalR once x% of a slow moving process were complete.

[yokohummer7]

I guess what has changed is me, not the computing environment. When I was young, I easily grew impatient when things were going slow. Nowadays I still kinda feel nervous, but not to the point to warrant such bookkeeping methods.

[koolba]

My urge to measure everything has only grown with age. I don't chalk it up to nervousness though. I'd say it's driven by curiosity and and a desire to forecast.

[TomMarius]

Today everything goes so fast that it's faster to kill and restart if it's not visibly moving, IMHO

[bump-ladel]

A couple of weeks ago, I marked the (no)progress bar on a macOS update with a piece of surgical tape.

[james-skemp]

Thank you for posting a physical marker; I was afraid I was the only person that's done so.

I've been known to use Post-its and the frame of my monitor as a marker. Both are much easier with how prevalent dual-monitors are these days.

[darkpuma]

Shit, I think I last used it last week! In my GUI wrapper for rsync while transferring some large files. It took about 45 minutes for one of the files.