Re: [Nautilus-list] Progress Bar on Move

[John Sullivan <sullivan spies com>]

on 12/6/01 10:39 AM, Martin Wehner at mwehner tfh-berlin de wrote:

> On Thu, 2001-12-06 at 18:31, Govind S. Salinas wrote:
> 
>> Hi, another user here, why not do it like red-carpet does it suring
>> downloads and have both.  A this-file progress and a total-Mb progress.
> 
> This would be neat, I agree.
> 
> I would be interested in opinions about showing the progress bar for
> very fast operations. One might argue that the progress dialog should be
> shown for every operation - to provide feedback and give the user the
> opportunity to cancel the (possibly destructive) operation. Or would it
> be ok to have a progress that comes up only if the operation takes
> longer than a certain amount of time? This seemed to be the original
> intend of the authors (on move at least). Should this be handled
> differently for the various operation classes (move/copy/delete/trash)?
> I'm running a version with a delayed (0.5sec) progress dialog now (for
> all operations) - And I like it. It feels like sane behaviour for me.
> But I'm kinda preoccupied because I invested the time to make it happen.
> 
> I'd appreciate any feedback on this issue,
> 
> Martin


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.

John