[Usability]Re: the Nautilus context menu

[Gregory Merchan <merchan phys lsu edu>]

On Wed, Nov 13, 2002 at 07:32:21PM +0000, Andrew Sobala wrote:
> This really belongs on usability-list.

The GNOME usability list is usability gnome org .

CC-ing this there and dropping desktop-devel-list gnome org .
Not <snip>-ing because the previous mail was not seen on the usability list.

> On Wed, Nov 13, 2002 at 11:48:08AM -0600, Gregory Merchan wrote:
> > On Wed, Nov 13, 2002 at 05:37:07AM -0500, Alexander Larsson wrote:
> > > The new nautilus has a feature where external plugins can insert menu 
> > > items in the context menu for files. This is quite powerful and lets us 
> > > extend Nautilus with new functionality from other apps (e.g. file-roller 
> > > can add a "create an archive from selected files"). 
> > > 
> > > However, it is also very easy to misuse this functionality to add stuff 
> > > to the menu entry that may not be suited. The context menu is a limited 
> > > resouce, and its already quite long. Several people disagreed with
> > > adding context menu components, arguing that the menu was already too
> > > long. 
> > <snip>
> > 
> > The menu could be made shorter.
> > 
> > 1) Dependent on Bug #82162, Open and Open With can be one item.
> > 
> >    Even without that, Open can be removed and instead the first
> >    item on the Open With menu can be the default item.
> >    This would not be bad because:
> >    a) Open is already afforded by (double-)clicking the icon.
> >    b) There'd be a way to know what is the default opener.
> > 
> 
> Yes
> 
> > 2) Scripts can probably be removed in favor of limited menu editing.
> 
> Not sure what you mean here; probably yes :-)

I had menu editing on OS/2. In the settings view for an object would
be a "Menu" tab. In version 3, this only afforded adding to one item's
menu. Only the main popup menu and the Open submenu could have additions.
Additions always appeared in the same place; there was no rearranging of
items. Standard items could not (iirc) be removed. The activate-able
items were programs that would accept the file name as an argument.
It also allowed for adding submenus, either plain ones or conditionally
cascading ones. (For which see bug #82162)


> > 3) Cut/Copy/Paste and Duplicate/Make Link can be replaced by two item.
> >    The replacements would be Pick Up and Drop, with a submenu for Drop
> >    allowing a choice of what to drop including: the object itself,
> >    a copy of the object, a link to the object. Again dependent on
> >    Bug #82162, one of those items can be made the default so that
> >    the user need not open the submenu.
> > 
> 
> This has been debated extensively in bugzilla, . . .

Bug #77293 - Reported by me.

>                                          . . . a good argument against
> being that people who use computers have learnt the Copy/Paste paradigm.

And against that is how much Cut/Copy/Paste of files differs from the
same action on other things.


> Pick up and Drop are a little more like real-life objects, but:
> 
> a) files are _not_ real-life objects, and file management assumes
> knowledge of filesystems etc. anyway;

Actually, they are "real-life objects". Besides the trivial nail file,
there are the files which people often place in filing cabinets. While
file and filesystem are defined a certain way at the OS level (and
then, not so for all OSes), almost all graphical interfaces exploit their
likeness to tangible files.


> b) it's inconsistent with the rest of GNOME, and every (?) other
> operating system out there.

As said before, Cut/Copy/Paste on files is inconsistent with the same action
on other things.

MacOS, to my knowledge, does not provide Cut/Copy/Paste of files; I think
it only allow mouse-based DnD or tranfers by dialogs.

Pick Up and Drop were present on OS/2 versions 2 through 4, at least.


> It doesn't seem worth alienating skilled computer users in an effort to
> make file management seem as simple as pie - which it isn't.

At this point, you've lost me. A series of questions:
  What do you think file management is?
  Why would I want to do it?
  Why do we have programs called file managers if they aren't
    actually managing the files?
  Why should the complexity of the underlying system be exposed 
    in the GUI?


> The bug's probably still open somewhere.
> 
> > 4) Rename used to be afforded by clicking on the label. What happend to
> >    this? Bring this back and get rid of the Rename... menu item. There
> >    is already another menu item that allows renaming - Properties.
> > 
> 
> IIRC, it was removed because it's a usability bug. Simply clicking on an
> item made the label editable when you didn't want it to be, and the
> label would refuse to become editable if you actually did.

That sounds like the bug was in the implementation, not the design.
I'm not able to find a bug report with the decision; though I did find
related bug reports.


> > 5) All of the icon items can be removed to the properties.
> 
> ?

The icon items are:
  Remove Custom Icon
  Stretch Icon
  Restore Icon's Original Size

I don't use icon stretching at all, and I doubt that more than 5% of people
would. It seems to me like a demo feature or something to make up for
deficiencies elsewhere, like lack of a sticky-notes program. I'd say just
remove the feature, but that's surely create havoc. So, instead, I'll say
it's not important enough to be on the popup menu; put it in the property
view.


> > The menus, without #82162 fixed, would be:
> > +------------------+
> > | Open With       >| -------------- +---------------+
> > +------------------+                | <the default> |
> > | Pick Up          |                +---------------+
> > | Drop            >| - +--------+   | <other        |
> > +------------------+   | Here   |   |   openers>    |
> > | Move to Trash    |   | Copy   |   |               |
> > | Delete           |   | Link   |   +---------------+
> > +------------------+   +--------+
> > | Properties       |   | Cancel |
> > +------------------+   +--------+
> > 
> 
> Presumably "Cancel" is if you don't want to "hold" whatever you "picked
> up" any more. Really, this has the same problem as cut/paste. If you
> "pick up" something, and then go and do something else, where does the
> file go? Answer: it hasn't gone anywhere. So "Cancel" is just a
> non-functional menu item :-)

You're the first person to mention that to me and I hadn't noticed the
error myself. Indeed, it makes sense that if you've picked something
up from one place it is no longer there. But not even DnD shows this!
Something is rotten here.

In OS/2, the last item on the Drop menu is actually "Cancel Drag".
Maybe that's better.

One thing that Pick Up and Drop (as implemented on OS/2) does which
Cut/Copy/Paste (on any system) does not is that it shows an image
next to the cursor like it would for mouse-dragging.

Here is an important difference between Cut/Copy/Paste and Pick Up/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.


> > With #82162 fixed:
> > 1) s/Open With/Open/
> > 2) The Open item could be activated without showing the submenu.
> > 3) <the default> would not need to be moved to the top as it
> >    would be indicated by a some icon next to it.
> > 4) Drop could be activated without showing the submenu.
> >    (I don't know which drop should be the default.)
> > 
> > 
> > Cheers,
> > Greg Merchan
> 
> -- 
> Andrew
> 
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GS/M d--(-) s: a17 C++(+++) UL+ P++ L+++ E--- W+>++ N(-) o? K? w--(---)
> !O M V-
> PS+ PE Y+ PGP+>++++ t@ 5-- X- R tv-@ b++++ DI+++ D>---- G- e- h! r--- y?
> ------END GEEK CODE BLOCK------
> 


Cheers,
Greg Merchan