Progress indicators

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

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.

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

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.

Give me real information anytime.

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

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)

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*!)

(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!

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.

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

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)

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

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

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

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!)

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.

Simplest thing to do is just put up this instead

Share and enjoy...

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

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

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

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.