Progress indicators

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

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

On Oct 29, 5:44*pm, D Yuniskis <not.going.to...@seen.com> wrote:

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

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.

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

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

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

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

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

Nils wrote:
> 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/project...arHarrison.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).

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

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

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

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

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

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

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

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

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

>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

On Thu, 29 Oct 2009 21:07:16 -0700, D Yuniskis
<> wrote:

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

Is the user annoyed of the progress indicator or annoyed by slowness
of the process itself ?

Reducing the bloatness and better design will decease the slowness,
which also will reduce the annoyance (of the indicator).

Some absolute time indicator would be most useful, since the user can
then decide if he/she will remain seated and wait for the result or
fetch a cup of coffee or go outside to smoke a cigarette.

Paul

Paul Keinanen wrote:
> On Thu, 29 Oct 2009 21:07:16 -0700, D Yuniskis
> <> wrote:
>
>> 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.
>
> Is the user annoyed of the progress indicator or annoyed by slowness
> of the process itself ?

I am not speaking in "specifics" but, rather, "generalities".
My question is intended to address *how* information is
conveyed to the user and *what* the user expects from that
information.

E.g., I suspect he cares very little about how many "bytes are
transfered". Or, how many database records have been processed.
I'm *guessing* what he really wants to know is:
- is this thing still working on my task?
- when will it be done?

The former question gives him reassurance that the process
hasn't crashed or become *stuck* for some reason (it seems
many devices provide very little feedback as to what they
are *actually* doing at any given time).

The latter allows him to decide when he can expect to
get on with what he *wants* to do (since I doubt "waiting" is
something that he *wants* to do! :> )

> Reducing the bloatness and better design will decease the slowness,
> which also will reduce the annoyance (of the indicator).
>
> Some absolute time indicator would be most useful, since the user can
> then decide if he/she will remain seated and wait for the result or
> fetch a cup of coffee or go outside to smoke a cigarette.

<frown> Remember, this is c.a.e. The "thing" that he might
be waiting for could very well be something he is *carrying*
with him. (I mention this to make sure we don't focus on
"desktop PC"-type applications of progress indicators)

Paul Keinanen wrote:
> Some absolute time indicator would be most useful, since the user can
> then decide if he/she will remain seated and wait for the result or
> fetch a cup of coffee or go outside to smoke a cigarette.

http://xkcd.com/612/