Progress indicators

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?

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.

I end up opening task manager > performance
while running most of my cad programs just
to see WTF is going on....

Jim Stewart 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?
>
> 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.

I think that windows offloads (?) things like animated
hourglasses to the "OS" (?). E.g., I suspect the
application can HALT and the hourglass will keep chugging
along (Disclaimer: I don't write windows aps so I
have no idea about the API).

But, that just tells you "thinking". It doesn't tell
you how *much* thinkning it has to do.

(Again, this is c.a.e so try to think of these indicators
as they apply to "devices" and not "desktop apps". What
would you do if your cell phone put up a progress bar
that *stalled* randomly, etc.?)

> I end up opening task manager > performance
> while running most of my cad programs just
> to see WTF is going on....

I use "Process Explorer" to try to get a finer-grained
view of what's happenning. And top(1) on my Eunices.

D Yuniskis wrote:

> I think that windows offloads (?) things like animated
> hourglasses to the "OS" (?). E.g., I suspect the
> application can HALT and the hourglass will keep chugging
> along (Disclaimer: I don't write windows aps so I
> have no idea about the API).
>
> But, that just tells you "thinking". It doesn't tell
> you how *much* thinkning it has to do.
>
> (Again, this is c.a.e so try to think of these indicators
> as they apply to "devices" and not "desktop apps". What
> would you do if your cell phone put up a progress bar
> that *stalled* randomly, etc.?)
>
>> I end up opening task manager > performance
>> while running most of my cad programs just
>> to see WTF is going on....
>
> I use "Process Explorer" to try to get a finer-grained
> view of what's happenning. And top(1) on my Eunices.

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.

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

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

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.

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

Regards,

Chris

On Oct 30, 2:41*pm, D Yuniskis <not.going.to...@seen.com> wrote:

> (Again, this is c.a.e so try to think of these indicators
> as they apply to "devices" and not "desktop apps". *What
> would you do if your cell phone put up a progress bar
> that *stalled* randomly, etc.?)

Mine does. When sending an SMS from iPhone, there's a progress bar
that (in my crappy coverage area) always slows down as it reaches the
end because it's calibrated for a "typical" time to deliver the
message to the tower.

When sending an SMS from earlier (and maybe current) Nokia phones, you
just get a barberpole - not quite a progress bar!

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.

> 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
course. Wait until some other activity begins hogging one of the media
involved, and see if that indicator can still be considered perfect.

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

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.

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

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

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

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

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

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

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

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

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

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"

Jon Kirwan wrote:

> Too much here, too much to share/exchange to find common ground, and
> too much I'm not entirely sure of anyway. Instead, your comments
> 'rang a small bell' in mind

Naw, that was the clothes dryer -- your laundry is done! ;-)

> and I'll try and provide a small part of
> that reverberation to see if it stimulates anything.
>
> You talked about 'indicators' and that reminded me of "tasks" on some
> gantt chart and my own learning process (always ongoing, of course)
> with respect to communicating with clients about projects. But the
> real issue is more than mere communication and I wanted to highlight
> that fact. It's also about controlling yourself.

Hmmm... as applies to my question, who is "yourself"?
The developer sorting out how to do things so that the
user can best be informed of its progress? Or, the
*user* disciplining himself as to what to expect from
the device?

[given this uncertainty, my comments that follow may appear
to be coming from two different directions :< ]

> Unless a project is something I've done completely before, or
> sufficiently similar to something I've done completely before, there
> will be potentially significant elements of uncertainty in assigning
> time. It is, in fact, these new facets with any good project that
> makes it interesting to do. If I didn't learn anything doing a
> project, then it's probably less enjoyable than projects where I'm
> faced with a new element or two to puzzle out. That's part of what
> makes me like doing a project. On the other hand, if there are too

Of course! The first time you do something, it is *fun*
(i.e., an adventure, new experiences, etc.).

The second time it is *interesting* (you can call upon your
initial experience and "fix" what you learned from that
approach).

The third time approaches "perfection" (not really, but you are
far enough up on the curve that it is rapidly becoming
asymptotic) and it becomes more of "something to get done"...

Speaking in terms of my *question*, though, I have a couple of
simple mantras for user interfaces:
- don't ask the user questions
- never forget what the user tells you
- think intelligently about your past experiences and how you
can learn to make the *user's* experience better (here, "your
experiences" are the experiences of the *software* at run time)
(there are more but these are the "biggies")

> many of these or if only a few but ones requiring a very significant
> commitment to new learning, then the client should probably select
> someone else. And if I'm not entirely sure, myself, I should inform
> the client as soon as I know that it is too much, too fast and that
> they should find someone else, pronto.
>
> It's pretty much given that if I have done a project twice before, the
> third time and beyond I pretty much know what it will take and about

Yup, as above.

Projecting this comment onto the progress indicator issue,
I think that most "tasks" can easily "learn" their own time
characteristics (again, I consider time to be the bottom
line on user interaction). After all, that is *all* that task will
do from now to the time it is "erased".

> how long. In those cases, the only interesting thing occurs when a
> client wants it in half the time in which I think I can do it. When

*Or*, when something that you rely upon proves to be unreliable!
E.g., when your emulator's power supply goes south and you are
faced with the task of debugging without the emulator (possible
but it changes your productivity) or spending unplanned time
troubleshooting the power supply. :>

While I say this tongue-in-cheek, it brings up another good
point wrt progress indicators and tasks tracking their
own "progress rates"...

I recently was wiping some hard drives (prior to disposal).
On one machine, the "write rate" was abysmal -- only about
5MB/s. I'm sure that this figure was accurate. And, therefore,
the estinmated completion time was *also* accurate. But, the
actual computed rate was just not what I would expect from
the machine (2.6G Athlon w/ ATA100). Instead of simply
accepting this *accurate* progress indicator, I realized there
had to be something wrong with the machine to give such terrible
performance!

I.e., a task that knows what its performance *should* be
can provide the system and/or user with insights as to
when things aren't working right -- though being able to
diagnose what the actual probelsm is may be considerably
more difficult.

> I'm pushing hard on a difficult schedule to keep it does get somewhat
> "interesting." Other than that, projects with opportunities for
> solving new problems or learning some new areas are also interesting
> and, similarly, also difficult to nail down some of the effort/time
> because of those very same uncertainties -- whether they be because
> I'm compressing schedules and just aren't sure by how much or because
> these novelties are difficult to nail down until __after__ I've done
> them once or twice.
>
> I try to follow a few guides -- though it's always a battle to do as
> well as I'd like to.

Learn to live without sleep! :>

> One is to haul forward to the earliest possible moment anything that
> is truly a deal-breaker issue. If there is something central to the
> project for which I don't know the answers and where that uncertainty
> is relatively large, it's important to pull those to the beginning of
> the project and find out what the lay of the land is. It may very

Yes. Note the article that Nils cited makes similar suggestions.

> well be the case that the problem dissolves quickly and becomes known
> enough that I can reset it back into the project plan where I'd rather
> have it. So I nail that down and put it to bed. Or else, at least,
> the client finds out early on that either I am not the right person or
> else that the issue is large enough that we need to make a decision
> about it. Pulling these things to the front gives the client the
> better chance to make important decisions as early as possible and
> before committing undue significant resources into it. They can

Exactly. I can recall the first time I "got clever" and tried
to copy a disk's contents to another machine over the network.
At the time, I was running a 10Base2 network and the drive
was only 4G. Previously, I had been *tickled* with how easy
and fast it was to move things between machines -- compared
to SneakerNet. Suddenly, the effect of scale was staring me
in the face -- a 4G "file" takes quite a while to transfer
at ~1MB/sec! Seeing the initial time estimate (which *I* could
done on the back of a napkin had I thought of doing so!)
allowed me to quickly decide that this was NOT the way to go!
(instead, I simply unmounted the drive and hand carried it to
the destination machine so I could copy it directly -- at
bus speeds instead of network speeds)

> decide to get out early, if the ante gets too rich for their blood.
>
> Another is that I kind of invert the meaning of milestones. There was
> a time when, as an employee, I provided the better I was able for an
> 8-hour shift and then went home. If a schedule was slipping, well...
> it was slipping. We simply had to re-adjust the charts to reflect the
> developing reality. I put in my time and that was that. (If they
> wanted to pay for more, that was their business, I suppose.) As a
> consultant, though, it's not like that at all. The milestones are
> rock hard. They don't move. I do the best I can in setting them and
> allowing 2 standard deviations of risked time as a margin of error in
> setting how long they will take. But once I set them down, they don't
> go anywhere unless I have absolutely no choice in the matter. What I

Yes, but projecting this onto the "progress indicator" issue, there
isnt any real way that a task can *insist* on meeting its deadlines
(unless it *knows* those estimates are accurate and can influence
the scheduling of resources in the system, etc.)

> do instead is use the progress towards the next milestone control my
> time. If I'm running early, I might supply less hours per day or
> week, shorten the project schedule, or roll some hours forward as
> padding for some of those more uncertain areas. If I'm running late,
> I work harder, later, longer. Instead of 30-40 hours/week, I might
> work 80. And I push the hardest as soon as I'm seeing the problem,
> supplying as many hours as I can manage right away. And if the whole
> thing still doesn't crack by the time the milestone presents itself,
> then and only then do I slip it. But by that time, I'm sinking in
> everything I can get away with, already.
>
> In short, I use milestones to control my applied time. I don't assume
> they are perfectly (or even well) set nor do I allow myself to imagine
> the idea that setting schedule is simply something I'm not good at and
> need to get better at. Yes, I'm always trying to get better at that.
> But when a project is in hand, that isn't the time. I then use the
> milestones to control my personal schedule and will move everything
> else out of the way, if needed.
>
> The milestone controls me.
>
> The rest seems to be vapor to me. A project is, ultimately, either
> satisfactorily done or not. All I can do is focus on putting one foot
> in front of another towards that end. Others who need to worry about
> larger team project issues need only know one thing from me -- that I
> will stick by my own established objectives, come hell or high water,
> and let them slip only when there is no other option. And even then I
> will continue to struggle against shortening up later items to make
> the time back and get back onto the milestones I've got ahead of me.
> So I give them the better they can hope for in their planning --
> milestones they can bank on unless no human level of effort on my part
> could have achieved it.
>
> I don't think there is a holy grail here. You can only control
> yourself. You cannot control physics, you cannot control others, you
> cannot control accidents, you cannot say what the right solution to
> new problems may finally resolve into, etc. But you can control
> yourself. It's the one thing you have that you do control better than
> anything else. So I let milestones impact me at that point. In the
> end, that is the best way to also communicate with clients. They get
> something they can basically bank on. And that allows them to do
> better in other aspects they are concerned about and greatly reduces
> the need for complex, hard-to-manage-and-communicate, real-time
> charting of progress. Keeps things real simple and simple is good.

A task, of course, can do nothing other than "its best" (even if
it is poorly implemented!). OTOH, the huge advantage it has is
that it is 100% repeatable. It *will* work the same way each
time. So, it should be much easier to measure and rely on.

> Jon

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

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.

--
Andrew Smallshaw