Re: [Usability] File operations dialog redesign
- From: "Mike Rooney" <mrooney+nautilus gmail com>
- To: "nautilus-list List" <nautilus-list gnome org>
- Subject: Re: [Usability] File operations dialog redesign
- Date: Tue, 10 Jun 2008 06:42:17 -0700
On Tue, Jun 10, 2008 at 5:31 AM, Bogdan Butnaru <bogdanb gmail com> wrote:
>
> I would find this option useful occasionally, but I'm afraid it's
> quite hard to do it intuitively. Imagine that I started a move of 50GB
> of files between two partitions. After 25GB are copied, I press
> "cancel". Under your proposal, this would start a backwards move of
> 25GB, which will take a long time. But a user expects things to stop
> when they press cancel, so they'd get confused.
>
But we already discussed how those are two completely different
operations. I cannot agree, at all, that a "Cancel" button should
"Stop" in the terms we have discussed, and I can't imagine anyone else
would either. I suppose you could argue it might confuse users,
although with the two together I am not sure. Anyway, your next point
addresses the issue is a better way.
> I wonder if it wouldn't be better to have a single "stop" button that,
> when pressed, gives the user the half-dozen or so options we've been
> discussing. (Or, perhaps better, a simple "stop" button with some
> clear semantic and a "more" button with the options.)
>
> The options available would include:
> "stop: leave already moved files in place, but stop moving the others"
> "revert [or cancel]: copy already-moved files back to destination
> (will take about #m#s)" (We know how long it took us one way, so we
> should know rather well how long it'll take to put them back.)
> "pause: temporarily stop moving files, but don't abort the operation
> (you can resume it later)
> "low priority: allow other file operations finish first"
> "high priority: pause other file operations until this one is finished"
>
First, a qualm: the last one doesn't even make sense. Why should
"pause OTHER file operations until THIS one is finished" be an option
under "Stop" for a file transfer? It is almost the exact opposite of
Stopping. That is incredibly unintuitive.
In general, I think it would be better to split into two buttons: Stop and Wait.
When you press the stop button, it asks if you want to just stop or
revert the already made changes.
When you press wait, it asks if it should pause, or set to low priority.
This is because we shouldn't hide functionality where you wouldn't
expect it to be. If you put the pause options in Stop, someone who
wants to just delay or slow down their transfer isn't going to realize
Stop gives them an option to do that. However putting the low priority
option in Pause I think makes sense because Pause is what you are
going to click if you want something else to finish faster, so this
will accomplish that goal also.
Where the High priority would go, I don't know. That probably requires
another button which I don't think is great. Perhaps it doesn't need
to exist at all. You could accomplish the same thing by setting the
others to low priority and I wonder how many there would truly be
(seeing as there isn't one for each file (I don't think), just one for
each "action" or group of files doing a similar operation). A user
isn't likely to stat 20 other file operations if they already did or
are going to start a really high priority transfer; pausing 1 other is
honestly the biggest use case I imagine, and anything around 4 others
should be easy with this system as well. Supporting this for 20 would
be nice but it requires (I think) an extra button.
--
Mike Rooney
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]