Progress indicators...

Main Page | Report this Page

Computers Forum Index » Computer Architecture - Embedded » Progress indicators...

Page 1 of 2 Goto page 1, 2 Next

Progress indicators...

Author

Message

D Yuniskis...

Posted: Fri Oct 30, 2009 1:44 am

Guest

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?

It seems like most indicators convey "work done" -- where
work is usually defined as bytes moved, etc.

Or, they are calibrated in completely bogus, nonlinear
units (e.g., progress indicators that chug along merrily
at a seemingly constant rate, then *jump* ahead... then
*stall* -- even though the "process" is obviously
continuing at the same "speed" as before, etc.).

Does it make sense to use different means for different
tasks?

Or, do users tend to think of tasks in terms of the amount
of *time* required ("Who cares if X bytes have been transfered
and that represents 12.673% of the total... how much of this
is *finished* vs. how much REMAINS??")

This isn't as trivial as it may seem on the surface.

The first real issue is "what do users EXPECT from progress
indicators"?
- to see that the system is "still working" (on their task)
- to gauge how much has been accomplished?
- to see how much remains?
- to see how much *time* has expired?
- to see how much time (likely) remains?
etc.

Once that is determined, I think it is a lot easier to
sort out *how* to convey this to the user -- especially
in those cases where the quality of the estimate varies
over time.

I suspect we (?) would all agree that existing implementations
usually leave a lot to be desired...

Thx,
--don

larwe...

Posted: Fri Oct 30, 2009 1:44 am

Guest

On Oct 29, 5:44 pm, D Yuniskis <not.going.to... at (no spam) seen.com> wrote:

Quote:

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

No progress indicator ever devised has been as aesthetically pleasing,
functionally perfect and culturally significant as the original
Microsoft-app Macintosh installer from the late 1980s featuring the
dinosaur eating a man. "When the dinosaur finishes eating the man, the
program installation will be complete!"

Nils...

Posted: Fri Oct 30, 2009 1:52 am

Guest

D Yuniskis wrote:

Quote:

There has been a bit of academic research on that topic. This paper is a
good start:

http://www.chrisharrison.net/projects/progressbars/ProgBarHarrison.pdf

Cheers,
Nils

Hans-Bernhard Bröker...

Posted: Fri Oct 30, 2009 2:57 am

Guest

D Yuniskis wrote:

Quote:

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.

Quote:

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.

Quote:

That's actually far from "obvious". Their makers may just have a
concept of "progress" that you didn't grasp yet. Or there may be
variation in how long individual work packets actually take, depending on:

parts that were configured to be skipped will jump the progress meter,
parts needing unexpectedly slow resources will make it crawl,
waiting for answers from far away can stall progress virtually forever

Quote:

The first real issue is "what do users EXPECT from progress
indicators"?

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

Quote:

- to gauge how much has been accomplished?
- to see how much remains?

Usually only the ratio of accomplished/total is of interest. The
exceptions from that rule are:

* show accomplished steps if each step involves interaction with the
user (think: old-time program installation off a 20-high stack of floppy
disks)

* show total or remaining steps if the total can move around (new work
being discovered, or steps found that can be skipped, as the process
proceeds).

Quote:

- to see how much *time* has expired?

No.

Quote:

- to see how much time (likely) remains?

Whenever that time is above the get-a-cup-of-coffee barrier, absolutely.

Jon Kirwan...

Posted: Fri Oct 30, 2009 5:15 am

Guest

On Thu, 29 Oct 2009 14:44:33 -0700, Don wrote:

Quote:

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?

It seems like most indicators convey "work done" -- where
work is usually defined as bytes moved, etc.

Or, they are calibrated in completely bogus, nonlinear
units (e.g., progress indicators that chug along merrily
at a seemingly constant rate, then *jump* ahead... then
*stall* -- even though the "process" is obviously
continuing at the same "speed" as before, etc.).

Does it make sense to use different means for different
tasks?

Or, do users tend to think of tasks in terms of the amount
of *time* required ("Who cares if X bytes have been transfered
and that represents 12.673% of the total... how much of this
is *finished* vs. how much REMAINS??")

This isn't as trivial as it may seem on the surface.

The first real issue is "what do users EXPECT from progress
indicators"?
- to see that the system is "still working" (on their task)
- to gauge how much has been accomplished?
- to see how much remains?
- to see how much *time* has expired?
- to see how much time (likely) remains?
etc.

Once that is determined, I think it is a lot easier to
sort out *how* to convey this to the user -- especially
in those cases where the quality of the estimate varies
over time.

I suspect we (?) would all agree that existing implementations
usually leave a lot to be desired...

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

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

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

Jon

D Yuniskis...

Posted: Fri Oct 30, 2009 5:15 am

Guest

Hans-Bernhard Bröker wrote:

Quote:

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. 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. I think such
tasks are characterized by an easy measure of the effort that
will be required to complete the task (e.g., bytes moved),
an easily updated estimate of the rate at which this activity
is currently progressing (e.g., as a function of CPU load average
and/or disk activity) *AND* the implicit knowledge that the
expended effort is a monotonically increasing fraction of the
total effort required. (contrast this with copying the
contents of a <generic_program's> stdout to a file)

Quote:

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. When it comes to software, I think that
is the only thing that users perceive. I.e., its not like
shoveling snow off your driveway where you can see how much
snow has been removed and decide to "call it quits" prematurely
(i.e., "That's a large enough portion for me to get my car
out; I'll do the rest later")

Quote:

Or, they are calibrated in completely bogus, nonlinear
units (e.g., progress indicators that chug along merrily
at a seemingly constant rate, then *jump* ahead... then
*stall* -- even though the "process" is obviously
continuing at the same "speed" as before, etc.).

That's actually far from "obvious". Their makers may just have a
concept of "progress" that you didn't grasp yet. Or there may be
variation in how long individual work packets actually take, depending on:

It is obvious if you can perceive that the "computer" (using
the term loosely as this is c.a.e) is still "working"... yet
"progress" doesn't SEEM to be happening. E.g., a user watching
a progress indicator that reflects the progress in sorting a
VERY LARGE list... the work required may vary dynamically
depending on where the algorithm is in the list (and the
nature of the algorithm as well as how it is instrumented).
So, it might generate the first two entries quickly -- yet have
to do more work to generate the *next* two entries, etc.

Quote:

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.
Just because that might be "hard" to do, doesn't mean you shouldn't
do it. (I tend to err in favor of the user in my designs)

Quote:

parts needing unexpectedly slow resources will make it crawl,

But, you can update your estimate at that time to reflect this.
My question then addresses: how do you convey to the user
this new estimate and your progress thus far *relative* to
this new estimate?

E.g., if you are copying bytes over an FTP connection, you
*know* (in most cases) how many bytes need to be copied.
If you elect to express progress as a graph of "bytes copied"
vs. "total bytes", then your progress indicator is just
"programmer friendly" and not *user* friendly. I.e., the user
doesn't care if you have transfered 894323 out of 896075 bytes.
He wants to know when you will be *finished* (since, in most
cases, having 99.97345% of the file is effectively the same
as having 0% of the file).

This is the nature of my question.

Quote:

waiting for answers from far away can stall progress virtually forever

Yes, so how do you convey that to the user? Just stall your
progress bar at X%? That doesn't tell the user anything other
than (at most) "progress has stalled".

Quote:

The first real issue is "what do users EXPECT from progress
indicators"?

- 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. Too often
"activity indicators" are just there to entertain the user and
don't actually reflect what is happeneing in the code. E.g.,
set cursor to "hourglass", do the task, set cursor back to
"pointer".

If the animation of the cursor (in your example) *is* tied to
the codes progress, you have to consider how that animation can
be affected by other things happening in the machine so that
it is not updated properly (i.e., if it isn't being updated
properly, then it isn't reflecting the actual progress).

Quote:

- to gauge how much has been accomplished?
- to see how much remains?

Usually only the ratio of accomplished/total is of interest. The
exceptions from that rule are:

* show accomplished steps if each step involves interaction with the
user (think: old-time program installation off a 20-high stack of floppy
disks)

* show total or remaining steps if the total can move around (new work
being discovered, or steps found that can be skipped, as the process
proceeds).

- to see how much *time* has expired?

No.

- to see how much time (likely) remains?

Whenever that time is above the get-a-cup-of-coffee barrier, absolutely.

I claim that all the user really cares about it an estimate (which
need not be in absolute terms) of the time remaining. If you
restrict the display to something as one-dimensional as a typical
"progress bar", then the "completed" portion of the bar should
reflect the time the user has *invested* and the "remaining"
portion should reflect the estimate of the time left.

(I see no other way to convey all of this information in a single
metric -- we can discuss multiple indicators, too...)

This leads to very counterintuitive displays. :<

D Yuniskis...

Posted: Fri Oct 30, 2009 5:15 am

Guest

Nils wrote:

Quote:

D Yuniskis wrote:

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/projects/progressbars/ProgBarHarrison.pdf

Thanks, Nils, this was an interesting read -- worth adding to
my literature collection.

But, it seemed like it (the "experiment"/study) was trying to
come up with a way to "least annoy" the user. I'm trying to figure
out how to *best INFORM* the user.

I've prototyped different strategies and can't say that I find
any of them appealing. The most interesting is the traditional
progress bar but continuously adjusted to truly reflect the
percentage of (estimated) work that is complete. The visual
characteristics, however, are highly disturbing (especially to
Joe Average User) despite being the most informative.

This leads me to believe you have to abandon a graphic/relative
presentation if you don't want to annoy/alarm the user. (else
you end up with the same crappy behavior that current progress
indicators exhibit).

larwe...

Posted: Fri Oct 30, 2009 7:53 pm

Guest

On Oct 30, 2:41 pm, D Yuniskis <not.going.to... at (no spam) seen.com> wrote:

Quote:

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

Jim Stewart...

Posted: Fri Oct 30, 2009 9:59 pm

Guest

D Yuniskis wrote:

Quote:

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

D Yuniskis...

Posted: Fri Oct 30, 2009 10:41 pm

Guest

Jim Stewart wrote:

Quote:

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

Quote:

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.

Paul E Bennett...

Posted: Fri Oct 30, 2009 11:25 pm

Guest

D Yuniskis wrote:

Quote:

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://Paul_E.Bennett at (no spam) topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

ChrisQ...

Posted: Fri Oct 30, 2009 11:39 pm

Guest

Paul E Bennett wrote:

Quote:

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

Hans-Bernhard Bröker...

Posted: Sat Oct 31, 2009 1:50 am

Guest

D Yuniskis wrote:

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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

Quote:

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.

Quote:

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

Andrew Smallshaw...

Posted: Sat Oct 31, 2009 5:08 pm

Guest

On 2009-10-30, ChrisQ <meru at (no spam) devnull.com> wrote:

Quote:

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
andrews at (no spam) sdf.lonestar.org

Hans-Bernhard Bröker...

Posted: Sun Nov 01, 2009 1:33 am

Guest

D Yuniskis wrote:

Quote:

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.

Quote:

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.

Quote:

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

Quote:

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?

Quote:

Why? "Impossible" is a cop-out.

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

Quote:

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.

Page 1 of 2 Goto page 1, 2 Next

All times are GMT The time now is Sat Nov 28, 2009 6:50 pm Computers Forum Index