> 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.
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?)
> 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.
> 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.
> 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.
--
.--= [ MArk Finlay - sisob ] =--.
[ Gnome User's Board : www.gnomesupport.org/forums ]
[ Public Key: http://evolvedoo.sf.net/sisobatericomdotnet.asc ]
Attachment:
signature.asc
Description: This is a digitally signed message part