Circa 2001-Dec-06 17:23:15 -0800 dixit John Sullivan:
: I think the delayed progress dialog is the way to go. I think there
: are three major reasons to show the progress:
:
: (1) To show that a long operation is underway
: (2) To give the user a sense of how much longer it might take
: (3) To give the user an opportunity to cancel if it's taking too long
:
: There's also this other reason, which I think is invalid:
:
: (4) To allow the user an opportunity to cancel a destructive operation
:
: If the operation is really quick, (1) - (3) are pointless, and (4)
: is impossible. Since (4) is impossible in some cases, it is
: therefore invalid: if the operation is so dangerous that the user
: needs an opportunity to think twice about it, the software has got
: to give the user that opportunity in every case, not just in the
: cases where the operation happened to take a long time.
:
: You might argue that even if (1) through (3) are pointless if the
: operation is quick, they aren't actually harmful. I disagree with
: this -- flashing a window on screen and instantly off is jarring and
: frustrating if you were trying to read it. So delaying the
: appearance of the dialog a little bit so that the really fast cases
: don't show the dialog at all is a good design choice.
Here are some thoughts.
You shouldn't have to show progress in a dialog at all. If there's any
reason to show progress, it should be shown in the main UI window
associated with the operation (for example, in a status bar at the
bottom of the window [or wherever the user wishes to place the status
bar]). The means of cancelling the operation---i.e., reversing/undoing
it---should also be in the main UI window (e.g., a cancel button on the
tool bar [like Netscape 4.x's "stoplight" button]).
You should also make clear in the interface what "progress" means. That
is, if it's (kilo|mega)?bytes, then not only should the progress
indicator display the units somehere (as well as the numeric amount),
but the way the progress indicator "fills up" should also correlate to
the change in units. Consider using different colors to represent
"current file" and "total operation", or to represent different
statuses (e.g., the operation has hung, perhaps due to a faulty NFS
server).
Also, consider alternative means of indicating progress: Perhaps,
instead of a progress bar, if the destination folder or folders (or
device) is visible (in a window, on the desktop, etc.), a "trip" style
progress indicator, with a dotted line or arc drawn from the source to
the destination, and an icon representing the source file(s) moving
along the dotted line toward the destination (just like near the
beginning of the movie 'Casablanca', where the route from Germany
through the Mediterranean to North Africa is shown). When the icon
reaches the destination, the operation is finished.
That is (in poorly drawn ASCII):
_____
_ _ _ _ | | _ _ _ _ _
| |
/ | | \
____ |_____| ____
/ \__/__ / \ \_____
| | | |
| O | | V |
|__________| |__________|
A user could even cancel or reverse the operation by dragging the icon
"back" toward the source. (Obviously, there should be other key-,
toolbar-, or menu-driven methods of reversing the operation as well,
both during the operation and after it's complete).
[Note that i'm not necessarily advocating this particular alternative
(i just thought of it), but what i am advocating is the consideration
of alternatives to progress meters that give better user interaction
than progress meters do.]
--
jim knoble | jmknoble pobox com | http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
Attachment:
pgpp1E4MubgqH.pgp
Description: PGP signature