What happened to proper progress bars?

On Sat, 15 Jun 2019 20:56:41 +0100, mechanic wrote:

On Sat, 15 Jun 2019 18:33:29 +0100, Commander Kinsey wrote:

On Sat, 15 Jun 2019 18:26:15 +0100, Mark Lloyd wrote:

On 6/14/19 5:47 PM, Commander Kinsey wrote:

[snip]

That would be inaccurate. It can

and often does

still display the silly sparkly thing
even though it's crashed.

The indicator is a simpler process with no (disk or network) I/O
and so much less likely to crash.

So the indicator is telling us that the indicator is functioning.

Well that's a comfort at least!

My car's ABS warning light indicates there's a fault with the ABS fault detection circuitry. It really ****es off the mechanic.

On Sat, 15 Jun 2019 20:35:01 +0100, Paul wrote:

Commander Kinsey wrote:

The one you get when doing a search in windows explorer is terrible, it
goes very fast from the start then gets slower and slower, with 90% of
the progress taking place in the last 5% of the bar. Surely it must
know how much it has to search through?!?

Do you think they're Kreskin ?

You'd have to scan the file system twice, to get an estimate.
That means running FindNextFile through the entire tree,
to get a "fresh" file list and estimate of "how may files
it takes to make 100%".

The OS knows how many files are on my disk.

A logarithmic progress bar makes
perfect sense, as far as these things go. Even though
I hate that green bar when I see it, I have to admire
the logic of what it does. It's a pretty clever solution
for hiding the ignorance underneath.

No, it moves fast then slows down. What's it trying to do? Make the user think it's nearly done when it isn't?

You really have to start using your thinking cap,
if you expect to understand why things are the way
they are.

If you wrote your own software, you'd be aware of
"how many ways there are to fail" when making progress
bars.

One of my favorites, was using "one printed period on the
screen, for every one thousand items processed". It's
easy to write a few lines of code to do that. So
what aberrant conditions does it produce.

* In one case, the dots "went off the side of the
screen" and after 79 dots, you couldn't see any
more dots. Doh!

* In a second case, so many dots are produced, the
25x80 text-only terminal, the command you executed
has scrolled off the screen, and the Terminal is
now filled with dots. You walk by the computer and
think "what the hell was I doing?". Because the
command has disappeared off the Terminal, because of
all the dots, now you don't know. Since the shell in
that era had no "History" option, you couldn't actually
check later and see what generated all those dots.
You've earned yourself another "Doh!".

You seem to be fixated on all the failures.

Once you try and do one of your own, you'll
quickly see what a challenge it is.

Step one, find out how much stuff there is to do (this will take a fraction of the time of actually doing the process). Step two, show this as a percentage as you go along. Plenty software does actually get it right.

On Sun, 16 Jun 2019 00:05:50 -0000 (UTC), Boris
wrote:

Eric Stevens wrote in
:

On Fri, 14 Jun 2019 18:50:17 -0400, nospam
wrote:

In article , Eric Stevens
wrote:


Its to encourage the bored user to be aware that the program has not
actually stopped.

for an indeterminate progress bar, there's no way to know if the
underlying process has crashed or not, other than it taking an
unusually long time...

in fact, i had that happen just the other day with 1903.

As it happened I installed 1903 just yesterday and remember those
progress bars (I think). I did not rely on the twinkling to tell me it
was still working but watched the 'performance' tab of Task Manager.

Same here. The progress bar was not a good indication of whether or not
something had stalled. I watched 'ethernet' tab for the download, and the
'hard drive' and 'performance' tab for the installation. My hard drive light
also flickered, but only when accessing the hard drive (of course). The
whole thing was absolutely agonizing to attend.

On another machine at another home (not used much), I couldn't wait the 3-
plus hours for the install. I came back three days later, and the thing was
starring at me asking if it should restart. I said yes, and came back the
next day to a completed install.

4.5 hours, several reboots and the need for me make a decision part
way through the installation. (Do it now or wait until the next time
you shut down?).

And 24 hours later I encountered another update requiring a reboot!
--

Regards,

Eric Stevens

On Sat, 15 Jun 2019 14:09:56 -0400, nospam
wrote:

In article , Mark Lloyd
wrote:

for an indeterminate progress bar, there's no way to know if the
underlying process has crashed or not, other than it taking an
unusually long time...

in fact, i had that happen just the other day with 1903.

The indication could be done more honestly, from the SAME process

that won't help and is not a good idea.

a progress bar should be on a separate thread, usually the main thread
to draw ui elements, with worker threads doing whatever the actual task
is and sending update messages to the progress bar as needed.

or at
least in communication with it.

normally it is, but if the lengthy task crashes and never sends a done
message, then the progress bar will stall or keep spinning, depending
on what type it is.

better software has a watchdog timer to detect if something is taking
an unusually long time, then shut down the stuck task and alert the
user that something went wrong. unfortunately, most software does not
do that.

Driver detective does that when installing new drivers seem to take
too long. It always complains about the installation of Nvidia
drivers.
--

Regards,

Eric Stevens

Commander Kinsey wrote:


Step one, find out how much stuff there is to do (this will take a
fraction of the time of actually doing the process). Step two, show
this as a percentage as you go along. Plenty software does actually get
it right.

CHKDSK

Checking linkages takes 0.1 microseconds.

Checking SID takes 1.1 microseconds.

Checking Extended Attributes takes 0.5 microseconds,
except when there are a bunch of small files next to
each other, where it seems to slow down.

The head of the hard drive, has a variable stroke
distance it has to move. The seek could take as
little as 1 millisecond to as long as 15 milliseconds
to complete, before the next "item" can be processed.
AHCI allows out of order completion (tagged queuing)
and the hard drive is allowed to complete the
requests, out-of-order. You issue commands
1-2-3-4 and the drive can do them 1-4-2-3.

Now, show your closed form expression for computing
the "total time" of a run...

Simple, innit...

*******

If the disk checking GUI simply printed the same
numbers the command line used, the "information quality"
would be higher. But the "boss" says they can't do that,
because that isn't compliant with "Fluent Design".
The boss will say "we need a new look, a fresh
look, it should look whizzy". Or as Steve Jobs
would have said "it should be magical". But
it can't really be magical.

Imagine you're the bus company. You make
a bus schedule. It implies you know how
long it takes the bus to go from the Mall at
one end, to the Downtown final stop. But,
at 8AM in the morning, sometimes the bus
is 10 minutes late, sometimes 20 minute late.
The traffic is lighter on Fridays, and lighter
still during summer holidays. So if we
were making a "progress indicator" for a
bus trip, how would we solve that ? If
you're sitting in the control room at
the bus company, do you know exactly how
late that bus will be ? Because if you did
know that, you could make the bus start
that many minutes earlier so it arrives
on time. For my bus company here, that
just isn't happening.

Non-deterministic things are non-deterministic.

Paul

On Sun, 16 Jun 2019 02:55:34 -0400, Paul wrote:

Imagine you're the bus company. You make a bus schedule. It
implies you know how long it takes the bus to go from the Mall at
one end, to the Downtown final stop. But, at 8AM in the morning,
sometimes the bus is 10 minutes late, sometimes 20 minute late.
The traffic is lighter on Fridays, and lighter still during
summer holidays. So if we were making a "progress indicator" for
a bus trip, how would we solve that ? If you're sitting in the
control room at the bus company, do you know exactly how late
that bus will be ? Because if you did know that, you could make
the bus start that many minutes earlier so it arrives on time.
For my bus company here, that just isn't happening.

Non-deterministic things are non-deterministic.

There must be a PhD in there somewhere - checks oh there is, and
plenty of real world implementations in various transport utilities,
see (for OpenSource (TM) ideas and working solutions)
https://github.com/OneBusAway/onebusaway/wiki

On Sun, 16 Jun 2019 07:55:34 +0100, Paul wrote:

Commander Kinsey wrote:


Step one, find out how much stuff there is to do (this will take a
fraction of the time of actually doing the process). Step two, show
this as a percentage as you go along. Plenty software does actually get
it right.

CHKDSK

Checking linkages takes 0.1 microseconds.

Checking SID takes 1.1 microseconds.

Checking Extended Attributes takes 0.5 microseconds,
except when there are a bunch of small files next to
each other, where it seems to slow down.

The head of the hard drive, has a variable stroke
distance it has to move. The seek could take as
little as 1 millisecond to as long as 15 milliseconds
to complete, before the next "item" can be processed.
AHCI allows out of order completion (tagged queuing)
and the hard drive is allowed to complete the
requests, out-of-order. You issue commands
1-2-3-4 and the drive can do them 1-4-2-3.

Now, show your closed form expression for computing
the "total time" of a run...

Simple, innit...

Actually, chkdsk is one of the few things which reports very accurately indeed. It's checking thousands of files, on average it knows how long each one will take.

*******

If the disk checking GUI simply printed the same
numbers the command line used, the "information quality"
would be higher. But the "boss" says they can't do that,
because that isn't compliant with "Fluent Design".
The boss will say "we need a new look, a fresh
look, it should look whizzy". Or as Steve Jobs
would have said "it should be magical". But
it can't really be magical.

Imagine you're the bus company. You make
a bus schedule. It implies you know how
long it takes the bus to go from the Mall at
one end, to the Downtown final stop. But,
at 8AM in the morning, sometimes the bus
is 10 minutes late, sometimes 20 minute late.
The traffic is lighter on Fridays, and lighter
still during summer holidays. So if we
were making a "progress indicator" for a
bus trip, how would we solve that ? If
you're sitting in the control room at
the bus company, do you know exactly how
late that bus will be ? Because if you did
know that, you could make the bus start
that many minutes earlier so it arrives
on time. For my bus company here, that
just isn't happening.

Non-deterministic things are non-deterministic.

Paul

You'd need a satnav report from the bus, or which stop it's got to, then you can easily say how far it's got. Which you always have on a computer system doing something on disk.

On 6/15/19 12:25 PM, nospam wrote:

[snip]

Also there's the "lie zone" (when the progress indicator says 100% but
the process isn't done). This can last a long time.

I remember the one on Internet Explorer (the moving papers going between
folders to indicate a transfer). I've even unplugged the internet
connection and it still keeps going (an indication it's not really
indicating anything).

that indicates a bug.


A VERY common bug.

--
Mark Lloyd
http://notstupid.us/

"All great ideas are dangerous." -- Oscar Wilde