Re: [Usability]Dealing with files in Gnome

[Wesley Leggette <wleggette gate net>]

On Thu, 2003-04-03 at 10:23, MArk Finlay wrote:
> > After picking up one or more highlighted things...
> > (There could also be the "bag of tricks" idea I presented before)
> > 
> > ...	|
> > Pick Up	|+--+
> > Drop   >|| Move Here	|
> > ...	|| Copy Here	|
> > 	|| Link Here	|
> > 	||--|
> > 	|| Cancel	|
> > 	|+--+
> One thing I was thinking of is that it makes no sense to have a drop
> item in the context menu for a file. Are you dropping onto or into that
> file? No, you only ever drop into a folder.

That's a really good point. So the "drop" submenu (or just the items if
we don't use submenus) will appear only when clicking on whitespace or
on a folder? That should be easy to do, right?

> 
> So one Idea would be to have a pick up item in the context menu for
> files and a Drop context menu item/items in the context menu for
> folders(and in the nautilus menus because they are related to the
> current folder, right?)

On the nautilus menu (the edit menu?), that's a good point. So pressing
"drop here" in the edit menu would be like right clicking on whitespace
and pressing "drop here" in that context menu. And pressing "pick up" in
the edit menu would pick up any selected items.

We should also have a "pick up" item in context menus for folders (to
pick up the folder) and while we're at it, we might as well eliminate
the pick up item from the whitespace context menu. But, what should we
do when multiple files are selected.

> 
> 
> > I think it might be stronger to say "Move", "Copy", and "Paste". In
> > essence, this is what users are doing, and I think this makes it
> > clearer. Note that In this model, since these options are all the
> > options are still under the "Drop" menu item, so it's still clear that
> > the user is "dropping". 
> Mmmm, I really think that mixing the two terminologies would be super
> confusing. The fact is that the Pick up and Drop terminology needs no
> explaining really so I see no benefit in using the "familiar" terms Copy
> and Paste.

Yes, I suppose you're right. When you pick things up, you're not really
"moving" them, per se. You're just "picking up" and then "droping". So
this is the current design?

...          |
Pick Up      |
...          |
Drop Here    |
Drop Copies  |
Drop Links   |
...          |
Cancel Drag  |
...          |

Should we still come up with some other alturnative for "cancel drag"? I
think someone else suggested "Cancel Pick Up", but is that too many
characters?


> 
> 
> > So my only complaint at this point is that by putting the actual drop
> > actions in a submenu, we're making the user do more work (from a
> > click-counting point of view). This has been addressed with the idea of
> > "conditional submenus. That's a perfectly valid solution, albeit a bit
> > confusing. 
> 
> > I will present further options below. But first, I want to
> > bring up the now increased consequences of a mis-click.
> 
> Hopefully we'll get undo in nautius in the future. Should solve this
> problem. Also, by it's nature Pick up and Drop forces users to be more
> careful. And there is no chance of them deleting files so the only risk
> is that they might be inconvenienced, and this is removed by undo.

Out of curiosity, do you know how an undo would work? Is it just
remembering the last few options, or are there some sort of file system
components also? Files in ext2 don't actually have to be moved around
internally, just relinked to new folders, right? But what about
cross-volume moving and copying? Do you know who's working on this?


> 
> 
> > Let's say we move it all into the same menu to "cut" (pun) down clicks.
> 
> Don't forget that when you use context menus, submenus are activated by 
> mouseover not by clicks. But even still, the HIG says that context menus
> should not have sub menus so we should try and avoid it.
> 
> 
> > Here's the quoted design...
> > 
> > ...	   |
> > Pick Up	   |
> > ...        |
> > Drop Here  |
> > Drop Copies|
> > Drop Links |
> > ...	   |
> > Cancel Drag|	This is better, but where'd "drag" come from?
> > ...        |	Will users get it?
> 
> Yeah, this one looks pretty good. The drag item is interesting. See my
> comment on the bug - Drag and Drop and Pick up and Drop are very closely
> related which is anothe major benefit.
> 
> > So we've got these two options. Notice the problem with the "Cancel" and
> > "Cancel Drag" options. Of course, "Cancel Drag" is the better option,
> > but may be strange to users where this term comes from and they may not
> > make the connection. I myself am assuming it comes from icon dragging,
> > which is actually probably a user's prefered movement and copying option
> > in the first place (and of course, often the most inconvenient). But is
> > that eloquent enough? I don't know.
> 
> I'd prefer "Cancel Pick Up" as it is very obviously liked to the pick up
> item above. I think it would take very little experimentation by a user
> to see that when they pick up a file the cursor changes to show them
> that, and when they click cancel drag, it changes back.
> 
> 
> > We can mix these two designs together. Look at the results below...
> > 
> > ...	   |
> > Pick Up	   |
> > ...	   |
> > Move Here  |
> > Copy Here  |
> > Link Here  | 
> > ...	   |
> > Drop All   |
> > ...        |
> > 
> > Of course, in this model you must recognize that "dropping" is
> > equivalent to putting your "picked up" files back where they were
> > untouched. Actually doing something to the files is represented by the
> > three action items.
> 
> That's interesting. But uses a totally different meaning of drop as
> cancelling the operation instead of finishing it. Will need to think
> about that. Doesn't mac use pick up and drop? Could be confusing for
> those users if we have a very similar implementation but with a
> different meaning of drop.
-- 
Wesley Leggette <wleggette gate net>