Progress indicators

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

>>> 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.

So just like I said before, indicating progress isn't the problem here.
Defining what "progress" actually means, is. Once you have that,
displaying it is a piece of cake.

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

No, it can't easily do that with any degree of reliability, because it
has absolutely no way of knowing how this processor unavailability will
behave over the remaining course of the copy task. As the saying goes:
to every important question there's an answer that's nice, short, easy,
obvious --- and completely bogus.

This seemingly easy strategy is exactly what yields those jumpy, jerky
progress indicators you so dislike.

>>> *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. :>

Measuring time doesn't help one little bit with finding out the total
time required. Not until after progress is 100%, that is.

> 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.

Now wouldn't it be nice if that dream were true?

> Why? "Impossible" is a cop-out.

It can be. It can also be a statement of proven fact and/or hard-earned
experience.

> 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?

You're back to particulars rather than the general case again.

D Yuniskis wrote:

> ChrisQ wrote:
>> Paul E Bennett wrote:
>>
>>> In several systems I have done I have used the usual "-", "\", "|" and
>>> "/" characters spinning on the spot for tasks that would take some
>>> time. The selection of the next character in the set was keyed to the
>>> end of a specific repetitive portion of the task. This is a real
>>> indication of activity and is suitable for a user interface on a small
>>> embedded system.
>
> Yes. But, hard to ensure each "step" is roughly the same size
> (temporally). Of course, for "activity" this isn't as
> important. But, for (cumulative) "progress" it becomes moreso.

I never bothered with trying to ensure an even period of time between
updates. The real event it the changes were keyed from was the confirmed
completion of the transfer of a block of data, or the intermediate task
complete marker achieved.

> I think one of the probelsm with (existing) progress indicators
> is that the interface to the indicator has no real global
> knowledge of the entire process. Like Paul's implementation,
> it just shows "progress" in some general sense and something
> else (hopefully) "counts" these events and uses them to
> update the overall indicator.

I always prefer some real event. It does not take much code to do the
indicator and to just call it at the end of an achievement point seems to be
a simple thing to do.

>> We used that technique a lot on terminal based systems and Sun systems
>> still use it during initial boot. You can get a bargraph percentage
>> complete effect the same way with a bit of ingenuity.

I think I just got the idea from some really old DOS software. I liked the
effect and it seemed to fit a lot of the things I was doing at the time.
These days I am not so much into having to feed human users such details.
The thing about doing distributed embedded systems is the other end of the
link is another machine. Much easier to satisfy than a human.

> IIRC, some of the Sun installers spawn a task that just "runs an
> (idiot) indicator" without any ties to the "worker task". I.e.,
> you can "kill -9" the worker task and the indicator will sit
> there merrily "indicating" (activity). I'd have to dig through
> my journals to see which installer it was...

That does not sound like a very worthwhile indicator. I prefer activity
indicators to be tied to some real event in the process.

>> Seems to me that the most important thing is always to communicate.
>> Never leave the screen static, so that the user thinks the system has
>> crashed. On modern systems, pc software installs have this stuff down to
>> a fine art...

I still consider it important that the activity indicator is tied to a real
event for its update so that when the task crashes the indicator will either
not update or disappear from the screen (preferrably the latter with a
report of teh crash). Had a bar-graph indicator on some PC software that got
so far then froze. No further progress from that task and you get to wonder
why the wait. The rest of the Windows system still seemed to be running.
Never did sus out the reason for the hang.

> But PC installers subscribe to the same sort of philosophy
> that the paper Nils cited seems to address. I.e., entertain the
> user so he isn't (as) annoyed with the slow progress. And,
> they are notorious for their nonlinearity. I.e., take away
> all of the accompanying graphics and other distractions and
> you don't really have any *useful* information on actual
> progress until you are actually *done*.

Give me real information anytime.

--
************************************************** ******************
Paul E. Bennett...............<email://>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
************************************************** ******************

Andrew Smallshaw wrote:
> On 2009-10-30, ChrisQ <> wrote:
>> Seems to me that the most important thing is always to communicate.
>> Never leave the screen static, so that the user thinks the system has
>> crashed. On modern systems, pc software installs have this stuff down to
>> a fine art...
>
> In my experience most Windows installers get this hopelessly wrong.
> There are ahs to be some kind of estimation made for the time taken
> by different phases - for example, one phase may be CPU bound,
> another disk or network bound. Since the balance between the
> performance of different components can't be anticipated it is
> impossible to say how much time each phases takes. Also some phases

But, I am suggesting that this is a consequence of the
"progress indicator" being an afterthought. The developer(s)
were focused on making sure the right files got copied,
registry settings, etc. and the idea that they would have to
communicate their progress to the user was something they
shoehorned in, after-the-fact.

I'm sure that same developer was under the impression that
the "install" is a one-time event (no doubt they had
never heard of the Grand Unified Solution: "reinstall
windows"! ;-). And, they probably also thought it
would be a much quicker process than it actually turned
out to be!

Had they had the user foremost in their mind when they
were working on this, they would have figured out how
to put enough scaffolding in place to drape a suitable
indicator over! And, how to make that indicator as
accurate as possible.

(N.B. unlike applications/tasks that run often, the
installer can't benefit from "past experience" so it
has a harder task before it)

> don't seem to be counted at all. How many installs have you seen
> where the progress bar moves quite quickly but takes an eternity
> to initally shift from 0%, or at the other end move from 99% or
> even 100% to completion?

Or, hang at "100%" (um, ok, we're 100% done... how much *more*
than 100 do we need to go??)

I am always amused at applications that have a "pause" feature.
Watching the estimated time remaining on many of these while
*in* pause shows you how little thought went in to the
progress indicator estimation algorithm. E.g., if there were
X seconds left at the instant the PAUSE was initiated,
should't the "time remaining" *stay* fixed at X seconds
for the duration of the pause?? (yet many estimators
ignore the fact that this is a deliberate pause and,
instead, look at the "total elapsed time", divide it by
the "finished work" and project this "average time per
unit work" out for the remaining portion of the task -- so,
the estimated time remaining keeps *increasing*!)

> My preference would be for textual descriptions of activity: e.g.
> a simple message like "Parsing archive header" for a phases
> expected to be fairly brief, or for a longer phases something with
> a further indication of progress: "Processed 2 out of 2721524
> thingies..." Of course, that can be misleading too: if thingy
> processing takes an hour it may be tempting to think the job is
> almost done when it is completed, when in reality you may only be
> 10% of the way through.

(sigh) I regret having to keep falling back to desktop examples
but that's probably the one thing we can all "relate" to (since
I suspect our individual application domains differ significantly).

I think the windows folks *try* to keep the user from getting *too*
bored/frustrated -- by breaking the install into lots of steps
so the user has the illusion (?) of progress being made. Note that
this is also true of the windows startup (i.e., how many different
times/ways does it say "Starting Windows"??)

But, for the most part, augmenting the display with descriptive text
won't help the average user understand how much progress is actually
being made:
OK, so you've parsed the archive header. Great! What *else*
do you have to do? Was parsing the header a *significant*
achievement/milestone? Or, was that a trivial task and
the really *hard* (i.e., time consuming) stuff still lies
ahead? What should I watch for to know that we are really
"getting somewhere"??

Unless the user is intimately familiar with the activities
that are involved (like digging a hole in the yard), more
descriptive information will only help if the process crashes
and the user is observant enough to tell the customer support
folks: "The last thing it said was..."

It's sort of like a "low fuel" indicator on a car dashboard.
Sure, it draws the user's attention to the fuel gauge (in
case he had been oblivious of the fact that he was running
low on fuel). But, does it tell the user anything that
will *truly* help him? I.e., how far can I drive before the
car simply *stalls*? Should I pull off the highway at *this*
exit and risk finding a gas station nearby -- even though
there are no signs on the highway that deliberately indicate
the presence of "services" at this exit? Or, should I
gamble that there will be another exit up ahead that
*might* have fuel available??

Granted, there (currently) are no ways of conveying any
*more* information to the user. But, then again, years ago
there wasn't a "low fuel" indicator, either!

Paul E Bennett wrote:
> D Yuniskis wrote:
>
>> ChrisQ wrote:
>>> Paul E Bennett wrote:
>>>
>>>> In several systems I have done I have used the usual "-", "\", "|" and
>>>> "/" characters spinning on the spot for tasks that would take some
>>>> time. The selection of the next character in the set was keyed to the
>>>> end of a specific repetitive portion of the task. This is a real
>>>> indication of activity and is suitable for a user interface on a small
>>>> embedded system.
>> Yes. But, hard to ensure each "step" is roughly the same size
>> (temporally). Of course, for "activity" this isn't as
>> important. But, for (cumulative) "progress" it becomes moreso.
>
> I never bothered with trying to ensure an even period of time between

Of course! You're just making an "activity indicator" not a
"progress indicator". You just need to ensure that you get around
to tickling it "often enough" that there are no extraordinary
pauses that the user could mistake as a "crash".

You could, however, have used these calls to "update_indicator()"
to, instead, take a snapshot of the system time and write it to
a (diagnostic) log file. And, either used that to reflect
where you *think* you are in the overall process (step M of N)
or simply count the number of such steps and pretend they
were equal.

I.e., this is the sort of approach I think most progress indicators
take -- "after-the-fact". I think they put "markers" in the
process (whether it is an "installer" or any other lengthy
task) and then use those to advance a simple *counter* where
the "terminal count" is a value that is filled in pseudo-manually.

> updates. The real event it the changes were keyed from was the confirmed
> completion of the transfer of a block of data, or the intermediate task
> complete marker achieved.

Understood. You're not just indicating the passage of *time*.

>> I think one of the problems with (existing) progress indicators
>> is that the interface to the indicator has no real global
>> knowledge of the entire process. Like Paul's implementation,
>> it just shows "progress" in some general sense and something
>> else (hopefully) "counts" these events and uses them to
>> update the overall indicator.
>
> I always prefer some real event. It does not take much code to do the
> indicator and to just call it at the end of an achievement point seems to be
> a simple thing to do.

Exactly. Much easier than trying to accurately reflect *where*
in the process you are.

I think there is a threshold beyond which folks want more
hand-holding. Or, *need* it (psychologically to ease the stress
brought about by uncertainty)

>>> We used that technique a lot on terminal based systems and Sun systems
>>> still use it during initial boot. You can get a bargraph percentage
>>> complete effect the same way with a bit of ingenuity.
>
> I think I just got the idea from some really old DOS software. I liked the
> effect and it seemed to fit a lot of the things I was doing at the time.
> These days I am not so much into having to feed human users such details.
> The thing about doing distributed embedded systems is the other end of the
> link is another machine. Much easier to satisfy than a human.

And, you can get more information *from* that other end if you
so desire! I instrument all of my servers and agents so that
their clients can obtain useful performance metrics from
them (instead of having to instrument themselves).

>> IIRC, some of the Sun installers spawn a task that just "runs an
>> (idiot) indicator" without any ties to the "worker task". I.e.,
>> you can "kill -9" the worker task and the indicator will sit
>> there merrily "indicating" (activity). I'd have to dig through
>> my journals to see which installer it was...
>
> That does not sound like a very worthwhile indicator. I prefer activity
> indicators to be tied to some real event in the process.

Exactly. It was actually counterproductive. The first time
the installer crashed (or maybe I kill(1)-ed it?) and the
indicator remained on the display, I was thoroughly confused:
"I thought the installer process had terminated? Why is 'it'
still 'spinning'??"

I think it falls in the category of "try not to let the user
get bored or nervous -- but don't actually give him any
useful information!" The paper Nils cited is insightful in
that there is no attempt made to provide better information
to the user but, rather, to *placate* the user in the most
effective way...

>>> Seems to me that the most important thing is always to communicate.
>>> Never leave the screen static, so that the user thinks the system has
>>> crashed. On modern systems, pc software installs have this stuff down to
>>> a fine art...
>
> I still consider it important that the activity indicator is tied to a real
> event for its update so that when the task crashes the indicator will either
> not update or disappear from the screen (preferrably the latter with a

Yup. Sort of like making a watchdog routine *smart* (instead of
just "please tickle this address")

> report of teh crash). Had a bar-graph indicator on some PC software that got
> so far then froze. No further progress from that task and you get to wonder
> why the wait. The rest of the Windows system still seemed to be running.
> Never did sus out the reason for the hang.

This is made worse by the fact that the indicator is not
linear. I.e., if the indicator is going to hang for some
period of time, *tell* me this *or* come up with a better
indicator.

It's sort of like emitting a message "expect 23 shift/reduce
conflicts" in a makefile just prior to it invoking yacc...
the message tells the user not to fret over the message
that then appears (assuming the message *is* as indicated!)

>> But PC installers subscribe to the same sort of philosophy
>> that the paper Nils cited seems to address. I.e., entertain the
>> user so he isn't (as) annoyed with the slow progress. And,
>> they are notorious for their nonlinearity. I.e., take away
>> all of the accompanying graphics and other distractions and
>> you don't really have any *useful* information on actual
>> progress until you are actually *done*.
>
> Give me real information anytime.

Besides elapsed time/time remaining (i.e., work done/work remaining),
I don't think most users can appreciate any more specific information.
You can set up a black-box to catch your logging and later get
that from the user (as a diagnostic). But, if the process
"appears to hang" once, chances are it will "appear to hang"
the next time, too! (if it is a real hang *or* if it is not
a real hang but, rather, just a "slow point" in the activity's
progress).

I get annoyed that my Windows server pauses for a considerable
time while it is booting. Have I forgotten to plug the network
cable in? Is it "timing out" waiting for a reply from my name
server? Or, is one of my disks not spinning up properly (hard
to hear over the fan noise)? Or, is something getting ready to
crash?

Unfortunately, Windows doesn't tell me what it is doing so I
can't reassure myself that "all is well" but must, instead,
wait and hope.

By contrast, booting one of my *BSD boxes is a very verbose
activity. I can see why it may be "stuck" if it *does* get
stuck. I feel more "in the loop" and, thus, more comfortable
working with those machines.

I think newer devices are getting sophisticated enough
that you can't simply ignore the user anymore. When your
tasks were fast/simple (relatively speaking), the user rarely
had to wait. And, if there was a wait, the user *accepted*
it because processors weren't as capable -- the mere fact
that he could have an electronic address book in his
shirt pocket made those inconveniences tolerable. :>

But, as devices become more capable, they tend to do more and
the possibility/probability of the user being inconvenienced
by the device increases.

E.g., I have a design that periodically has to "vacuum"
its database(s). This can be time consuming. This can
interfere with the normal operation of the device. If I
just "do my thing" and force the user to wait "as long as
it takes (but no longer!)", the user will quickly become
annoyed with the product. I can put a faster processor
in, add more memory, etc. All of these add to the cost of the
product, increase its complexity, decrease its reliability,
etc.

Or, I can tell the user to change his usage habits to
allow me to do things at more convenient times (which
is contrary to my user philosophy). Or, for the user
to do things that are more convenient for *me*! (which
is even more despicable!)

Or, I can provide the user with *good* feedback about
the length of time the task will take so he isn't
left in suspense. Perhaps allowing him to defer that
maintenance operation at the expense of some run-time
performance, etc.

My experience has been that if the user feels part of
the process -- and not a slave to it -- he will tolerate a
lot of things that he would resent if they were unilaterally
"imposed" on him.

In article <hcisdv$j7m$>, says...
> Andrew Smallshaw wrote:
> > On 2009-10-30, ChrisQ <> wrote:
> >> Seems to me that the most important thing is always to communicate.
> >> Never leave the screen static, so that the user thinks the system has
> >> crashed. On modern systems, pc software installs have this stuff down to
> >> a fine art...
> >
> > In my experience most Windows installers get this hopelessly wrong.
> > There are ahs to be some kind of estimation made for the time taken
> > by different phases - for example, one phase may be CPU bound,
> > another disk or network bound. Since the balance between the
> > performance of different components can't be anticipated it is
> > impossible to say how much time each phases takes. Also some phases
>
> But, I am suggesting that this is a consequence of the
> "progress indicator" being an afterthought. The developer(s)
> were focused on making sure the right files got copied,
> registry settings, etc. and the idea that they would have to
> communicate their progress to the user was something they
> shoehorned in, after-the-fact.
>

Simplest thing to do is just put up this instead

<http://www.pcserviceselectronics.co.uk/cartoon.htm#loading>

Share and enjoy...

--
Paul Carpenter |
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

Jim Stewart <> wrote:
> I'd be happy as a clam if I could just see
> an hourglass when the machine is compute-bound.
> Virtually no Windows apps give you an accurate
> indication and it's one of my major gripes.

On my Linux machines I have little scrolling graphs in the system tray for
CPU load and network bandwidth, which are handy for indicating whether I'm
CPU bound, network bound, or quiet waiting for some network event to happen.
I can see them at a glance without having to do anything (for example, I'm
typing this in an SSH session and seeing blips for the network traffic
caused by my keystrokes).

Windows Task Manager will give you a little systray icon, but only providing
4 bits of state (quartiles of the current CPU load). Perhaps there are some
apps that will show data as a time vs load graph in the tray?

Theo

On Thu, 29 Oct 2009 22:52:21 +0100, Nils <>
wrote:

>D Yuniskis wrote:
>> Hi,
>>
>> I've asked this question many times over the years (in
>> many places) and still haven't come up with a satisfactory
>> answer.
>>
>> What's the "best" way to convey to a user the "progress"
>> made on completing a task?
>
>There has been a bit of academic research on that topic. This paper is a
>good start:
>
> http://www.chrisharrison.net/project...arHarrison.pdf
>
>Cheers,
> Nils


Look at CopyHandler for a program that gives good progress feedback.
percentage of task completed. Overall average speed. Average speed
over last 30 seconds. Estimated time to completion. One gets an
immediate feel and enough info to see if progress is as expected, how
long it is going to take etc.

Regards
Anton Erasmus

Theo Markettos wrote:
> Jim Stewart <> wrote:
>> I'd be happy as a clam if I could just see
>> an hourglass when the machine is compute-bound.
>> Virtually no Windows apps give you an accurate
>> indication and it's one of my major gripes.
>
> On my Linux machines I have little scrolling graphs in the system tray for
> CPU load and network bandwidth, which are handy for indicating whether I'm
> CPU bound, network bound, or quiet waiting for some network event to happen.
> I can see them at a glance without having to do anything (for example, I'm
> typing this in an SSH session and seeing blips for the network traffic
> caused by my keystrokes).
>
> Windows Task Manager will give you a little systray icon, but only providing
> 4 bits of state (quartiles of the current CPU load). Perhaps there are some
> apps that will show data as a time vs load graph in the tray?

Process Explorer does this. FAIK it may be a configurable (tray)
display as well.

But, these are just activity indicators (inactivity nonindicators?)
and don't help you with understnading where a particular process
is in its progress towards its goal.