Re: Progress indicators

Hans-Bernhard Bröker wrote:
D Yuniskis wrote:
Hans-Bernhard Bröker wrote:
D Yuniskis wrote:

I've asked this question many times over the years (in many places)
and still haven't come up with a satisfactory answer.

That may very well be so because there _is_ no such thing as a satisfactory answer to that question.

I disagree. At least in some instances, there are *perfectly*
satisfactory approaches.

Your question didn't really strike me as one searching for special-case answers. It was almost obsessively generic.

The "generic" aspect of the question has to do with identifying
those things that the user considers "useful information" upon
which to base a progress indicator's design.

E.g., I contend that the user is *only* interested in "time"
(in the generic answer). he cares not how many bytes have
been transfered, how many records have been sorted, how
much travel an articulated mechanism travels, etc. Sure,
it might be interesting to some users but most users
are only looking at that information as an analog to getting
real information about the related *time*.

E.g., copying a file between two local media can be "monitored" in a
way that most users would tolerate even in those cases where the
processor load varies substantially during the activity.

That's mostly because processor load has nothing to do with it, of

That depends on the characteristics of the two media involved!
And, what the "other activity" makes for demands on the
processor -- as well as how the OS schedules those respective
activities.

E.g., try copying a file from A to B (on some medium being
EXCLUSIVELY used by that copy task) while you are trying to
encode an MPEG video. I.e., the MPEG task is typically
CPU bound (not I/O bound) yet it's abuse of the processor
spills over into the run time required for the copy task.

However, the copy task can easily update its time estimate
to reflect this "processor unavailability".

If you start thinnking of the sorts of things that an
*embedded* device is likely to be called upon to do,
you'll find these "desktop" analogies poor examples.

course. Wait until some other activity begins hogging one of the media involved, and see if that indicator can still be considered perfect.

Even in that case, the copy task could come up with a more realistic
(accurate) indication. If it *doesn't*, it is because there has been
very little effort placed on conveying *accurate* and *useful*
information to the user (e.g., clinging to "bytes moved" as a
metric instead of "time spent")

What's the "best" way to convey to a user the "progress" made on
completing a task?

You'll know the answer to that once you've defined "progress" in a usable manner, i.e. one that is quantitative, objective and measurable.

*I* consider progress to be a measure of the time spent vs. the
total time required.

That's not a usable definition, because it's not measurable, at least not within generally affordable effort.

Why not? I can measure time to all sorts of precision for very
little cost. :>

The problem is folks haven't put the effort into quantifying how
their code works. It's an afterthought instead of something
that is planned from the beginning.

Also, remember that this *is* c.a.e and you have a "device"
that does very few *particular* things and could *chose*
to track how it has done those things in the past.

Returning to the file copy example, that task should be able,
given simply the *size* of the file to be copied, to come up
with a bounded estimate on the time required *bfore* it even
open()'s the file. In the simplest case, it could track
"average transfer rate" every time it is invoked and note
the minimum and maximum rates encountered (presumably, the
maximum would occur when data was nicely laid out on the medium
while the minimum rate would occur for poorly fragmented files
in which lots of seeks were necessary). The *first* estimate
that the task displays to the user should have a pretty good
accuracy even before the task begins. (i.e., the user
should be able to decide *if* he wants to perform the copy
just by examining the "time commitment" indicated)

All kinds of factors influence the estimated completion time. Some of those factors will change as the process chugs along, others would take longer to measure than the process itself does.

Again, there is no need for this. If you watch (yourself) every
time you do "something", you should be able to quantify your
performance. After all, you are going to be doing this sort of
thing for the rest of your electronic life!

E.g., I *know* copying files off my thumb drive takes
much longer on *this* machine than on my development
machine -- simply because this machine only has USB1.1
ports. Surely "copy" could tune itself (with all the
CPU resources available on these desktop boxes!)
and give me better information than it does...

parts that were configured to be skipped will jump the progress meter,

If you are *skipping* something, then you should have known that
and reflected that cost saving in your initial task estimation.

That would only work if someone managed to create and fine-tune an accurate model of the whole process' time use that takes into account all but the most insignificant factors affecting it. That's generally impossible.

Why? "Impossible" is a cop-out. It might be something you
aren't inspired to "solve" but, if that was your stated
*job*, I'm sure you would come up with a reliable way of
doing it!

I've got a robotic actuator that has to move a high speed
cutting tool around a large "cutting arena" following a path
set forth by the operator (and unknown to the "machine"
until that point of time).

The *application* is responsible for moving the actuator.
*It* decides how quickly the motors are operated. *It*
decides how quickly the actuator can be accelerated to
a given "linear" speed and how quickly it can decelerate
or brake that actuator. It knows that a diagonal with
a 3" displacement along one axis and 4" along the other
represents *exacly* 5" of motion. Etc. It knows where
along the path the actuator might have to return to its
"staging area" to have the cutting head changed. And how
long it takes *it* to change from cutting head #13 to #85.
And then to return back to the place where the new
cutting head must be employed.

And, it knows all of these things BEFORE IT EVEN STARTS
WORKING ON THE PROBLEM!

Why can't it predict -- to a high degree of accuracy -- the
total trip time for the actuator to execute this trajectory?

So what you get instead is the crude old "let's assume that the ratio of <arbitrary work units> per second achieved this far into the process will stay constant until completion" technique. And that fails spectacularly if the process consists of more than one type of work, so you can't make do with a single <arbitrary work unit>.

But that's because you were lazy and attempted to model all
work with a single factor. That's like deciding to use
addition for all arithmetic operations -- even when it
is NOT the operation required! Then, when someone complains
that the result of "14 / 9" was incorrect (23?), you just
shrugged your shoulders.

Because using addition to model division is a foolish design
choice. If you were *tasked* with quantifying the time for
a particular activity, you would undoubtedly NOT opt for
a "one size (factor) fits all" model.

parts needing unexpectedly slow resources will make it crawl,

But, you can update your estimate at that time to reflect this.

No, you can't, because generally you _don't_know_ why a given part of the work takes as long as it does. So you can't update the estimate meaningfully with any reliability.

Why don't you? Because you *chose* not to make this information
available to "clients" in your application. It wasn't important
to the "problem" (subproblem) you were trying to address. And,
when you tried to squeeze in a progress indicator AFTER THE
FACT, it was way too much work to reinstrument the software
to provide the information that you would *need*.

E.g., I implement all of my drivers as processes. As such,
they continue to "exist" and "operate" even after the
open/read/write/close has returned to its caller. As a
result, those drivers can provide more information to clients
and prospective clients.

So, for example, I can "ask" my audio (out) driver what its
backlog is (i.e., how much data is queued waiting to be
"played") or what its actual throughput is *and* what it
sees *my* "writing rate" to be. Based on those metrics,
I can elect to deepen buffers to *guarantee* that the
buffers don't underrun, etc.

By the same token, I can ask a "disk" driver what sort of backlog
of scheduled activities (deferred writes, etc.) it has queued
and, from that, determine how long it is likely to take for
this set of bytes to get moved onto the actual media
(I wouldn't even have to make this calculation myself; I
could just ask the driver to do that prediction *for* me)

Because having these metrics available helps me ensure I
meet all of my deadlines. They also can help me provide better
estimates to the user.

You don't have to go to this extreme to get the same sort
of useful data. You just need to decide that it is important
top you (and your users!)

- to see that the system is "still working" (on their task)

That would be the job of an activity indicator (rotating hourglass or whatever), not a progress indicator.

The progress indicator can serve the same purpose.

Not usefully.

You're assuming you know what the indicator is and the nature
of the task itself. E.g., Apple (?) uses a barberpole progress
bar on some products. The length of the bar reflects the
progress made. The fact that it is still "rotating" can
indicate that there is still activity occuring.

MS uses a "segmented" progress bar. This allows the user
to see small changes in the length of that bar more easily.
I.e., a new segment "suddenly" appears. Those segments
could flash to indicate activity, etc.

I don't consider any of these *good* choices. But, they
clearly show that *one* indicator can serve multiple
purposes.

Note how many FTP clients will present progress to
the user in multiple forms:
- bytes transferred (out of total)
- elapsed time / time remaining
- % complete
- instantaneous transfer rate

Here, the approach is to provide lots of information
instead of *good* information. I.e., it relies on the user
to notice the transfer is stalled, consult the "work
(byte) remaining" to determine how close to finished
the process is, and to project their own "likely"
time of completion.

Obviously, programs realize users are interested in
their progress. But, they don't seem to have invested
much serious effort in providing *good* answers.
"3 + 5 = 6... more or less"
.

Relevant Pages

  • Re: Progress indicators
    ... "progress indicator" being an afterthought. ... bored/frustrated -- by breaking the install into lots of steps ... It's sort of like a "low fuel" indicator on a car dashboard. ...
    (comp.arch.embedded)
  • Re: Progress indicators
    ... for "progress" it becomes moreso. ... is that the interface to the indicator has no real global ... my journals to see which installer it was... ... a real hang but, rather, just a "slow point" in the activity's ...
    (comp.arch.embedded)
  • Re: Dangerous driving complaint and response.
    ... It's not even as if the cabbie made progress, ... have caught him at the next junction. ... yada yada yada ..... ... the driver basically bullies his way through ...
    (uk.rec.cycling)
  • Re: [PATCH] sym53c500_cs PCMCIA SCSI driver (round 3 - the charm?)
    ... what circumstances might a PCMCIA driver see a CS_EVENT_CARD_RESET? ... progress at that point, or we don't care. ... reset, or card removal event. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: How do YOU react to being cut up?
    ... you have to block the junction to make progress. ... The original discussion we were having, was when I was describing a bus driver who had blocked a junction, despite knowing that there were road works a few hundred yards along his intended exit. ... waiting on my left to enter the roundabout and turn left. ... defending them, only explaining" ...
    (uk.rec.driving)