Re: [Usability]Dealing with files in Gnome

[Wesley Leggette <wleggette gate net>]

Well Mark, you've convinced me. I do remember some beginning computer
users I know trying to figure out how to move things. This pick up and 
drop idea does have potential.


...       |
> Pick Up   |+-------------+
> Drop     >|| Drop Here   |
> ...       || Drop Copies |
> ...       || Drop Links  |
> ...       ||-------------|
> ...       || Cancel Drag |
> ...       |+-------------+
> 

I'll now address the architecture shown above. Here's a redesign I did:

Before picking up anything...

...	|
Pick Up |
...	|
--------+

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	|
	|+--------------+

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". 

One thing that was mentioned was that by creating this "Pick Up and
Drop" metaphor, we are allowing the user to wait until they get to their
destination before deciding what they want to do with the files they've
selected. The "Cut, Copy, and Paste" made users decide what they wanted
to do right then. I agree. This is a good think.


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.

This mis-click thing deserves some thought because it's a potentially
serious flaw in the "Pick Up and Drop" metaphor. With "Cut, Copy, Paste"
if a user mis-clicks--and knows they've done so--they can cancel the
action before comitting the change. Our model doesn't allow that. If
they click on Move when they Meant Link, they either have to wait until
the operation is done and undo it (and hopefully there's an Undo command
in the Edit menu, but maybe not), which sucks, or they have to cancel
the operation mid-way (if it's a big move) and worry about partial moves
(for more than one file) or some corruption issue. This flaw is
critical, and it's something we should solve before deciding to adopt
Pick Up and Drop. 

However, I won't address mis-clicking further, because I don't have a
solution. But I'll talk about another option besides conditional
submenus to deal with the extra clicking of the above menus. 

Let's say we move it all into the same menu to "cut" (pun) down clicks.

Here's what my design would look like...

...	   |
Pick Up	   |
...	   |
Move Here  |
Copy Here  |
Link Here  |
...	   |
Cancel	   |	Cancel is weird because what's it canceling?
...	   |

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?

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.

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.

Well, that's my fourteen cents, anyway.

-Wesley Leggette



On Tue, 2003-04-01 at 07:58, MArk Finlay wrote:
> On Tue, 2003-04-01 at 01:25, Wesley Leggette wrote:
> > Regarding Pick up and drop, I think the semantics are no better. What
> > happens if you "pick up" one object, then another, and then drop? It
> > would defy all expectations to "drop" both of them at the new location
> > if this is simply a change in cut, copy, paste. So assuming that that it
> > would work this same way, the change in terminology is pointless. We all
> > know what cut, copy, and paste mean and it's more than logical to assume
> > our users do to.
> 
> I think that if you can dig through bug 77293 you will see that they are
> not the same. As well as that, copy and paste in a file manager is not
> something that the majority of people use. In fact I've never seen
> anyone except the most advanced users use it, and even for them it took
> getting used to.
> 
> For me this is the major reason why we can change this: it is a broken
> metaphor BUT it is not widely used enough for changing it to be a major
> problem AND for users who are used to copy and paste it will take them
> very little time to get used to it. To me it embpaces and expands the
> copy and paste idea - but is similar enough to be non-disruptive.
> 
> The major difference is that you decide what you are going to do with
> a "picked up" file when you are dropping it and not when you are
> "picking it up" which gives much greater flexability and would also go a
> long way to making nautilus's context menus more sane.
> 
> 
> >> From the bug report, a proposal:
> 
> "Remove Cut/Copy/Paste from the file operations.
> Add a Pick Up operation.
>   Using this on a file, selected files, or either in sequence
>   adds the file(s) to a list (or whatever data type)
> Add three Drop commands.
>   Drop Here.
>     The picked up file(s) is(are) moved to the drop location.
>     The list is emptied.
>   Drop Copies.
>     They are copied, and the lisfile:///home/sisob/.gnome2/panel2.d/default/launchers/blah-001a326f8b.desktopt is emptied.
>   Drop Links.
>     Links (hard, symbolic, or .desktop) are created at the
>     drop location. The list is emptied.
> Add a Cancel command.
>   The list is emptied. Nothing is done to the files.
> 
> For the UI: the Cut/Copy/Paste items are replaced with:
> 
> ...       |
> Pick Up   |+-------------+
> Drop     >|| Drop Here   |
> ...       || Drop Copies |
> ...       || Drop Links  |
> ...       ||-------------|
> ...       || Cancel Drag |
> ...       |+-------------+
> 
> 
> Preferably, the drop item is a conditional cascading menu as
> described in bug #82162. This way the user can move or copy
> files (whichever is the default) without opening the submenu.
> 
> An advantage of this is that it may also be used for keyboard
> accessible drag-and-drop. (Perhaps the accessibility keyword
> should be added.)"
> 
> >> another point from the bug:
> 
> "Here is an important differnce between the two models which has not
> been mentioned, afaik. I think it may actually be the most important
> difference and the clincher for moving to Pick Up and Drop.
> 
> With Cut/Copy/Paste, you are committed to a particular action well
> before completing it. If you have Cut and when going to paste you
> realize you actually wanted to Copy, you have to either go back
> and Paste where you Cut or you complete the action and Copy back
> to the original location.
> 
> With Pick Up/Drop, you can defer the decision until you complete
> the action.
> 
> There is also the matter of accessibility which Bill Haneman
> expresses well in:
> http://mail.gnome.org/archives/desktop-devel-list/2002-November/msg00248.html";
> 
> >> end of bug comments
> 
> Personally I don't think that this implementation is perfect, but it's a
> lot better than copy and paste and I hope that we can improve these
> ideas in the future.
> 
> > But of course there is a utility for remembering multiple cuts and
> > placing them all in the new paste spot. But users would have to be able
> > to easily remember what they have currently cut (some sort of cursor
> > tag-a-long that shows the icon's they are carrying and allows them to
> > drop all or some of them unchanged?). If this sort of behavior were
> > implemented, "pick up" and "drop" would make a lot of sense, and since
> > it's different that traditional cut and paste, the name change would be
> > appropriate.
> 
> you see - now you're thinking properly - we don't have to copy OsX or
> Windows or KDE or anyone - let's make gnome really Useful and inovative
> ;) I agree that knowing what is currently picked up is left out from the
> current proposal and that would need to be delt with.
> 
> >  And hey, we could always have a preferences toggle between
> > the two modes of operation.
> 
> Good no! /me points to havocs paper
-- 
Wesley Leggette <wleggette gate net>