[Usability] Selection & Edit actions, a Nautilus bug and general comments

[Jurgen Botz <jurgen botz org>]

In Nautilus at least as recently as the 1.0.4 version that shipped with RH 7.2,
there exists the following behavior which I consider a bug:

Right-click on a file icon and chose "rename".  The text of the filename is now
selected and editable.  Go to the "Edit" menu... we have the following 
choices:
"Cut File", "Copy File", "Paste Text", "Clear Text".

Huh?  How do I copy the text of the filename?  Why would I want to copy the 
whole file when I'm engaged in the act of editing its name?

I remember the discussion about not making the text of filenames editable
by merely clicking on it because that happened to easily by accident and
was confusing.  Makes sense.  But when we have text selected the Edit menu
should offer the full range of possible actions on the selection... I don't
see any reason for the current behavior.

I do like the fact that the items of the edit menu reflect the type they
are operating on, but that's not an excuse for not operating on the type
the user is currently working with, and when renaming a file that's the
text.

In a direct manipulation GUI the user always has the context of an object they
are operating on.  The context can exist within a hierarchy, i.e. a file is
selected, but the operation is not on the whole file but only on a component
of it; the name.  The UI needs to make that context explicit and in the case
of renaming a file Nautilus does this by changing the way the text looks
when going from a file selection to a rename.  That works in this case, but
there is a more general case for which we should provide a UI model and 
guideline.

I was just giving some feedback to a friend who is the author of a very nice 
GUI firewall builder (called "fwbuilder", find it on sourceforge) and I ran
into a similar problem.  Fwbuilder has an object-tree window and a window
in which it displays a tabbed set of attribute editing dialogs for the 
selected object.  Because objects can be copied, pasted, dragged and dropped,
there is a similar problem about what the edit menu applies to... does it
copy the whole currently active object or does it apply to the selected
text in the attribute field I'm currently typing into?

Objects in the object tree are selected by clicking and use standard Gtk
highlighting to indicate their selection.  You could just say that so long
as there is no text selection (including no insertion point, which is a 
null selection) the Edit menu applies to the object, but once you've
clicked in a field it applies to the text.  You can make that a little
clearer by changing the Edit menu items to reflect the type, as Nautilus
does.  But there is still some ambiguity... an insertion point is not
always obvious and the user may not even look at the menu if they are using
the keyboard (i.e. ctrl-C/ctrl-V).

The answer to this is a tri-state selection for objects...

1) Object not selected
2) Object as a whole selected (i.e. normal Gtk highlight)
3) Object selected, but active part is some component not whole object
   (let's say instead of highlight we use outline in highlight color)
4) Clicking on an object in state 3 returns it to state 2, deactivating
   any text selection/insertion point

This resolves the ambiguity and should feel quite natural.  It is widely
applicable, as a hierarchy of objects or objects/attributes can be found in
nearly any application.  It should therefor be supported explicitly with code
in the libraries, standardized in the UI guidelines, and strictly followed in
major Gnome applications such as Nautilus.

***  The important thing here is that the "Edit" actions should always
***  be applicable to any type the user can directly manipulate, and it
***  should always be clear on what they will operate.

I think that part of what made the Mac so popular even in its early primitive
days was that it had this uniform set of Edit operations that could be applied
to whatever object the user was working with.  Certainly this has always 
been a core UI design principle of the Mac.  Not letting a user copy or
paste text merely because its a trivial amount of text and exists only as
an attribute of some higher-level object is a violation of this principle.

:j

-- 
Jürgen Botz                       | While differing widely in the various
jurgen botz org                   | little bits we know, in our infinite
                                  | ignorance we are all equal. -Karl Popper