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/
