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/ -- nautilus-list mailing list nautilus-list@gnome.org http://mail.gnome.org/mailman/listinfo/nautilus-list