[linux-elitists] Re: GNOME > you

Karsten M. Self kmself@ix.netcom.com
Mon Jan 5 18:21:29 PST 2004


on Sun, Jan 04, 2004 at 04:49:05AM +1100, Jeff Waugh (jdub@perkypants.org) wrote:
> <quote who="Jay Sulzberger">
> 
> > > Do you write novellas in your filenames? Like, seriously, what behaviour
> > > are you trying to optimise for here?
> > 
> > Here is part of the output of ls in the directory of root on this box:
> > 
> >  diff.dist-upgrade.18-20.December.2003
> >  dist-upgrade.21.November.2003
> 
> > Here is a clipping from xterm 3 on the screen before me right now:
> > 
> >  jays@knoppix:~/ALKAN$ ls
> >  op17_LePreux.mid           op31_16.mid          op39_06.mid
> 
> Surely your interaction model with these kinds of files is terminal-centric
> to start with? 

Accuse the user.  True to character.



> Perhaps not the midi files, but I'm not sure why visibility of the old
> name would assist you greatly when giving them sensible names (or
> whatever you're trying to do with them).

Um.  Like.  Creating a new name based on the old one?

...or _not_ changing a filename when you've accidentally performed the
not-entirely-inconceivable coincidental action of highlighting a file
while hitting a keyboard key.  Gee... did I just lose my filename?

I'll also note that it's GUI rather than shell environments in which I
see more conversational, or to borrow your own phrasing, Mr. Waugh,
"novella" style filenames.

The true irony is that the direction GUIs have been trying to force
users for, oh, the past decade or two is a Gelertnerian "dump the files
in a flat namespace with machine-only names, and provide useful
distillation tools to access the files themselves".  Funny thing is -- I
thought that was precisely what inode-based filesystems were.  The
overlay of directories (and directory names) and filenames, with some
added chrome in the form of symbolic and hard links, at least in
user data (as opposed to systems data where the hierarchy does provide
functional use) is as a user interface convenience.

So the GUI revolution, when complete in another few decades, will leave
us with system-semantic-only inodes, with system-semantic-only filenames
layered on top of these, and content-based metadata (with its
concomittant administration and maintenance headaches) on top of this.

Wake me up when the Golden Age arrives, and have a glass of Ovaltine
ready.


> Can you see that these kinds of interactions are not the sorts of things
> we'd optimise for, particularly in the file manager? 

Pardon?  Parsing error.

> The file manager is not there to fully replace what you do in a shell.

"Useable file renaming is not a supported feature of the GNOME file
manager".  Interesting.

Just what _would_ you consider a proper file management function?

> Were you ever seriously expecting to have a satisfying experience
> doing these kinds of things in a file manager? Highly unlikely, and
> you're using shell examples to begin with anyway. ;)



> I find this happens a lot in "CLI vs. GUI" debates. The CLI person
> says, "Aha, but how would you rename a lot of files all at once, eh?"
> [1] and the GUI person says, "well, you couldn't". But what they
> really mean is, "well, you generally wouldn't". And despite coming up
> with all kinds of reasons why it would happen, it's really very true.
> You just don't find yourself in that situation (usually). But where it
> does happen on *nix systems, you always have a shell.

Funny, but in worlds I interact with (I'm one of the odd-nut 'Nix types
in a universe largely inhabited by Winders types), there's usually a
bunch of breathless panting about how EasyEdit or some similar non-free
programming editor supports mass edits and/or renames.  As if I couldn't
do as much in shell, portably.

The needs don't go away.  They just get buried deeper within the GUI
morass.

This also calls at the whole GUI metaphor thing anyway.  Images are
great.  If you want to convey a piece of unambiguous, uniform,
information, red octogons, white wheelchairs on blue fields, boys and
girls in circles and triangles, red-bar-on-white-circle, and related
idiograms are useful.  But if I stop to ask someone for directions, I
hope they'll use words.  Outside of dot-com business model conferences,
hand-waving isn't a sufficiently dense informational medium to convey
sufficient expression.

GUI has its place.  So does CLI.  Neither's going to replace the other.
Oh, and you'll note that Microsoft's been busily extending its own shell
language (in a backwards incompatible form as usual) for the past
several major OS releases.


> So, I think that in the vast majority of file rename interactions in
> Nautilus, providing the complete filename, selected and ready to edit
> in place - with its hint of direct-manipulation - is still the most
> usable approach. 

There's a big school that really likes the "old value, new value,
commit" model of transactional filing.  GNOME seems to be fleeing this
for inexplicable reasons.  But whatever.


> Sure, an argument could be made for indirect manipulation through a
> rename dialogue box, but... Well, we have already been through this:
> 
>   http://developer.gnome.org/projects/gup/hig/1.0/usabilityprinciples.html#enable-direct-manipulation (Which links to the User Input chapter, too.)

There's moving objects in a display, and there's making irretrievable
changes to data.

What's really amusing here is the level at which actions are comitted
here.  Traditionally, in 'Nix, "rm" is the unforgiving command.  Various
coddlers will help neophytes by aliasing 'rm -i', and old farts will
insist on breaking the alias, on the basis that you'd better make
_damned_ sure you're deleting what you mean to delete.  After all,
you've got the command line to look at before hitting <enter>.

Microsoft (copying Apple, as usual), provided the trash can.  "Undo".
Safety net.  And I won't go into stories of users who were using trash
for permanent storage...until network admins decided to change retention
policies...and yes, the change was well and widely publicized.

My own first experience with the MSFT file mangler, in the early 1990s,
was sheer amazement that I could, on a shared networked drive, move or
delete files simply by dragging them.  More than once I've wanted a
confirmation for actions such as moves.  I've also got a habit of
clicking filenames, rather than icons, when attempting to open or move
them.  Curse that often.

Of course, when renaming files in a 'Nix CLI, at the very simplest
level, you've got both names in front of you.  Often with the assistance
of tab completion, X cut'n'paste, etc:

    $ mv old-name new-name

For bulk renames or operations, the trick of generating a command,
_then_ executing it after double-checking that it does what's intended,
is common.  Rick Moen's publicized one such trick -- you generate code,
then pipe it through 'bash' when it's well-formed.

There's also the interesting detail that _most_ GUI apps have some sort
of "undo" feature...but this functionality is virtually always
specifically missing from file manager apps.  CLIs typically offer this
option through the ability to recall and edit commands.
       


Peace.

-- 
Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
   At the sound of the toner, boycott Lexmark:  trade restraint via DMCA.
    http://news.com.com/2100-1023-979791.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20040105/f17aee2f/attachment.pgp 


More information about the linux-elitists mailing list