By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,968 Members | 1,180 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,968 IT Pros & Developers. It's quick & easy.

Developer Don'ts: Nonsense Progess Bars

P: n/a
If you thought the Windows "copying files" progress bar was tupid
(as it will say "3 minutes remaining" then "6 hours" then "15
seconds" and so forth), I've got an even worse one.

I was at a client today and was implementing some changes to backup
routines and while testing a new backup set, was watching the
progress bars put up onscreen by the backup program to show how the
job was progressing.

There were two progress bars, one for the current task, and one for
the entire job. The top bar was perfectly sensible, it started at 0
and gradually grew as each task was completed, then reverted to 0
for the next task.

For the overall progress bar was the worst example of incorrect
extrapolation I've ever seen. It would start at 0, increment to 25%,
say, then jump back to 0 or 10%, then jump to 75%, then back to 25%
or whatever. The non-graphical representation would say "15 minutes
remaining" then "6 hours" then "2 minutes" then "1 day 6 hours" then
"8 minutes" then "29 days".

I am not making this up.

It really say "29 days remaining."

If your algorithm for calculating the overall progress bar is so
poor it can't tell the difference between things that should count
and things that shouldn't, then don't display anything at all.

Basic principle: an overall progress bar should never SHRINK. No
progress bar should ever move in any direction except that
indicating an increase in progress.

Second, don't extrapolate based on each task individually, but on
the average rate of all tasks so far.

Or, at least, make your calculation as intelligent as you can. If
there's waiting time while your program has to collect information
(as a backup program does in scanning files for the archive bit),
then build some reasonable estimate into your system for that. Count
the number of directories on the hard drive, or use the size of the
hard drive, or the size of the files on the hard drive, or
*something* as a basis for determining if the task at hand is
compleeting in a reasonable amount of time.

People complain that programs are user hostile and often ignore
important prompts onscreen. But I don't *blame* them for ignoring
what the program tells them if it's so stupid as to tell a user that
there's "29 days remaining" and immediately follow that by "2
minutes remaining." Why should any user pay any attention to any
messages from a program that tells the user such patently stupid
things?

If you're going to give a user a message, make sure it's both an
accurate message and one that provides information that's actually
of use to the user.

In the case of progress bars, if you can't really make an accurate
extrapolation of how long tasks are going to take, don't give the
user a time-based estimate. Instead, give them something like "4 of
26 tasks complete." That won't tell them how long it's going to
take, but it will give them a sense that things are happening, which
is the whole point of a progress bar, to give a user a visual
representation that something is going on.

If you can't do anything better than that, then just use a spinning
graphic or something, to show that the computer is working.

This is actually more important than you might think. There was a
recent iTunes upgrade with a Windows installer that had no progress
bar and no indication that the program was working. I thought that
the installer had hung after waiting for it for a few minutes. The
only reason I discovered that it was just taking a long time was
that the phone rang after I'd restarted the installer, and ended up
going in the other room.

When I came back 10 or so minutes later, the installer had actually
completec, and I realized that I'd interpreted the lack of onscreen
indicators of any action by the installer not as the pause while the
program worked in the background (I did get the appropriate mouse
cursor, but that often happens when programs hang, too), but as the
installer hanging and failing to complete. This was an error that a
better user interface would have made substantially less likely. All
it would have taken was an indication from the installer that
something was happening in the background. The easiest way to
accomplish that is to simply display each line of the installer
script as it executes. It's not terribly informative in any sense
other than to tell you that the installer actually is doing
something.

So, for Access developers, my conclusions:

1. if you use a progress bar, make it a sensible one.

2. If a progress bar would not work well in a particular situation,
then give some indication to the user that your program is working
in the background.

3. If you present a message to the user, make sure it's both
a. accurate and
b. useful

Failure to do these things will cause your users to not like or
mistrust your application.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 27 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
On Mon, 27 Feb 2006 13:21:51 -0600, "David W. Fenton"
<XX*******@dfenton.com.invalid> wrote:
If you thought the Windows "copying files" progress bar was tupid
(as it will say "3 minutes remaining" then "6 hours" then "15
seconds" and so forth), I've got an even worse one.


<snip a sensible post with which I thoroughly agree>

Many years ago, on an IBM system, I met a progress bar (actually
successive lines on a console) which ran:

2 minutes remaining ...
1 minutes remaining ...
0 minutes remaining ...
-1 minutes remaining ...

--
Stephen Poley
Feb 27 '06 #2

P: n/a
Stephen Poley <sb******************@xs4all.nl> wrote in
news:7i********************************@4ax.com:
On Mon, 27 Feb 2006 13:21:51 -0600, "David W. Fenton"
<XX*******@dfenton.com.invalid> wrote:
If you thought the Windows "copying files" progress bar was tupid
(as it will say "3 minutes remaining" then "6 hours" then "15
seconds" and so forth), I've got an even worse one.


<snip a sensible post with which I thoroughly agree>

Many years ago, on an IBM system, I met a progress bar (actually
successive lines on a console) which ran:

2 minutes remaining ...
1 minutes remaining ...
0 minutes remaining ...
-1 minutes remaining ...


Were you by chance travelling faster than the speed of light at the
time?

Oh, wait, that wouldn't have done it. . . .

I do think I wouldn't worry about users of my application who
happened to be travelling at the speed of light.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 27 '06 #3

P: n/a
This reminds me of the tale of a developer from many many years, who
worked on a mainframe and had a routine that looped through many
millions of records taking several hours to complete.
In order to indicate the progress, the developer had the cursor flash
every 10,000 records.

Some manager commented to the developer that he thought the whole
process was far too slow. So, the developer modified the routine so
that the cursor flashed very 5,000 records!
The manager reviewed the changes and guess what - he elated that the
process was 'going faster'!
Stephen Poley wrote:
On Mon, 27 Feb 2006 13:21:51 -0600, "David W. Fenton"
<XX*******@dfenton.com.invalid> wrote:
If you thought the Windows "copying files" progress bar was tupid
(as it will say "3 minutes remaining" then "6 hours" then "15
seconds" and so forth), I've got an even worse one.


<snip a sensible post with which I thoroughly agree>

Many years ago, on an IBM system, I met a progress bar (actually
successive lines on a console) which ran:

2 minutes remaining ...
1 minutes remaining ...
0 minutes remaining ...
-1 minutes remaining ...

--
Stephen Poley


Feb 28 '06 #4

P: n/a
In (I think) the 70s, a new highrise office tower went up in Chicago.
Great building. But everyone complained about how slow the elevators
were. So the engineers, architects, and owners got together. Within a
week there were no complaints about the speed of the elevators--because
they now all had mirrors in them.

Jeremy
--
Jeremy Wallace
Fund for the City of New York
http://metrix.fcny.org

Feb 28 '06 #5

P: n/a
Per Phil Latio:
Some manager commented to the developer that he thought the whole
process was far too slow. So, the developer modified the routine so
that the cursor flashed very 5,000 records!
The manager reviewed the changes and guess what - he elated that the
process was 'going faster'!


Must've been one of the same managers that rated programmers on the number of
lines of code they wrote. "K-Locs", I think...

Iterative Loops? Naaaah... we'll just clone the same twenty lines of code for
each of these fifty possibilities...
--
PeteCresswell
Feb 28 '06 #6

P: n/a
Is the Windows "copying files" a progress bar? It doesn't show what has
happened, but displays a prediction (which is almost always wrong) of what
will happen. A progress bar should not anticipate the future.

Steven
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...
Stephen Poley <sb******************@xs4all.nl> wrote in
news:7i********************************@4ax.com:
On Mon, 27 Feb 2006 13:21:51 -0600, "David W. Fenton"
<XX*******@dfenton.com.invalid> wrote:
If you thought the Windows "copying files" progress bar was tupid
(as it will say "3 minutes remaining" then "6 hours" then "15
seconds" and so forth), I've got an even worse one.


<snip a sensible post with which I thoroughly agree>

Many years ago, on an IBM system, I met a progress bar (actually
successive lines on a console) which ran:

2 minutes remaining ...
1 minutes remaining ...
0 minutes remaining ...
-1 minutes remaining ...


Were you by chance travelling faster than the speed of light at the
time?

Oh, wait, that wouldn't have done it. . . .

I do think I wouldn't worry about users of my application who
happened to be travelling at the speed of light.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Mar 1 '06 #7

P: n/a
"Steve" <st***@nospam.net> wrote in news:o0***************@fe09.lga:
Is the Windows "copying files" a progress bar? It doesn't show
what has happened, but displays a prediction (which is almost
always wrong) of what will happen. A progress bar should not
anticipate the future.


A progress bar will, by definition, predict the future, in that it
will be an extrapolation from what has already happened about how
much is left.

Now, that's assuming that the progress bar represents the amount of
time, rather than the number of tasks. A progress bar that does the
latter is not necessarily going to be very useful. What if there
were 2 tasks, and 1 of them took 1 second and the other one took 1
hour? In that case, the progress bar would go to 50% and then stay
there for an hour. That's not very useful information.

The whole point of my post is that any data you put onscreen to give
a user information about what's going on should be in a form that is
useful, comprehensible and not misleading.

In the case of the application that prompted my post, there was a
time-based progress bar and a text prompt like the Explorer copy
prompt.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 2 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.