Re: [Usability] File operations dialog redesign

[Matthew Paul Thomas <mpt myrealbox com>]

Hi Paweł

On Apr 26, 2008, at 2:52 PM, Paweł Paprota wrote:
> ...
> I've assigned bug #518410 [1] because I'm willing to work on the code
> side of this issue. However, unfortunately I'm no UI designer... I've
> tried to come up with some initial UI proposal for review but failed.
> It would be great if someone could help me with the redesign.

I've published a proposed design on the Gnome wiki.
<http://live.gnome.org/Nautilus/ProgressWindow> Comments welcome.

> Current [2] "File operations" dialog has several issues mentioned in
> the bug comments. There are also some outstanding regressions that
> probably need to be addressed [3].

The new window is cool in that it stacks multiple tasks into the same
window, reducing the number of windows on screen.

However, as you say, the presentation is a bit clumsy. For example, I
can see why the designer might have made the Stop button icon-only
instead of text -- because if there's more than one task happening, the
word "Stop" would be repeated in the window, and repeating text in a
window is usually a sign that the designer's done something wrong. In
this case, though, ~98% of the time there will be only one task
happening at a time, so the repetition won't happen. So the cost of
occasionally being repetitive is outweighed by the benefit of always
providing an easily clickable and clearly labelled "Stop" button.

> Also I managed to identify some issues:
>
> 1. If we put the stock icon-label cancel button - what about keyboard
> shortcuts when there is more than one file operation in the dialog?

The stock Cancel button is actually wrong, in that it sets "C" as the
keyboard equivalent rather than Esc. (I wish someone would fix that!)

Besides that, though, you shouldn't label a button "Cancel" unless it
actually cancels the operation. GIO doesn't do this; it leaves behind
whatever partial results it had achieved before you clicked the button.
Therefore the button should be labelled "Stop".

I think it's reasonable for Esc to stop the first operation, with Tab
required to get to the rest. You could try to set a different letter as
the access key for each "Stop" button, but it would look ugly, and it
still wouldn't work for more than four tasks.

> 2. Where do we put additional information about the operation?

In an expandable section, so that the window is still compact by default.

> 3. Should pause functionality also be provided where suitable?

What are the use cases for pausing an operation?

If the answer is "to stop the disk from churning when trying to do two
things on the same disk at the same time", that's probably something
GIO should handle automatically, rather than requiring manual
intervention. (The rules could be: (1) during pre-flighting, all tasks
involving the same disk(s) are paused; (2) any task that involves
increasing disk space -- such as emptying the trash, or overwriting a
larger item with a smaller one -- causes another task to pause, if that
other task needs the disk space it will provide; (3) except for rule 2,
any new task pauses to wait for any older task that involves the same
files or folders; and (4) except for rules 2 and 3, bigger tasks pause
to wait for smaller tasks involving the same disk.)

> I welcome all feedback on this issue and am willing to work closely
> with usability folks to get it resolved in 2.24 timeframe.
> ...

Thanks for working on this, and thanks for asking for design help.

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/