Re: [Usability] The new file chooser

[Sean Middleditch <elanthis awesomeplay com>]

On Mon, 2004-09-20 at 19:12 +0200, rkaa netcom no wrote:
> Sitat Havoc Pennington <hp redhat com>:
> 

> > When you paste, the chooser would jump to what was pasted, and ctrl+L
> > would open containing what was pasted.
> >
> > "next" file would normally just mean pressing down arrow due to sort
> > order, so a typical sequence would be ctrl+o to open, ctrl+v to paste
> > filename, down arrow, Enter.
> >
> > Havoc
> >
> 
> I'm not getting through to you... and this is all taking the wrong direction.
> 
> A paste should never jump. Typeahead should jump. Typeahead should trigger on
> key input of a character / character sequence. Keyboard navigation is a
> poweruser tool. Distrincly different from mouse-navigation. You scroll, select,
> drag, drop, copy, paste with a mouse. To introduce a "paste ahead" feature
> sounds extremely confusing. It would be an abstract in the GUI, and the user
> would never know when and where it worked, and how.

Why?  That argument makes no sense.  Why shouldn't a paste select the
file the pasted path identifies?  Is that not the _exact_ reason you
pasted the path?  To select it?  What other possible reason could you
have for pasting the path into the selector?

And this doesn't have much to do with keyboard navigation.  There is no
reason middle-click couldn't work with this system either.  And there is
no need to use a keyboard to make slight adjustments to the file name -
the folder will be displayed as usual, and you can select the file by
name.  In fact, that's _less_ keyboard work than having to paste it into
a text entry and then type in the modification.

> 
> To further stress that its unusable also in a "psudo text" widget:
> A paste can be a whole email. What should the filepicker "jump" to then?

Nothing.  It is an invalid URl.  The same as if you tried to paste a
whole e-mail into KDE's or Windows' file choosers - you either get an
error or you get a whole lot of garbage in the input field that the file
chooser probably shouldn't have let you enter anyway.

> 
> I don't think it's a path anyone would want to go down. IMO a paste should
> definately NOT jump. A paste should just paste -  into something you can see.
> Keep it simple.

OK.  Paste could open the path entry window.  Exact same behaviour as
before, except now you have to hit an extra button to get from the path
entry window back to the main chooser window.

> 
> Invisible widgets that "somehow" accept and act on their pastes, would be most
> unexpected. "Can I paste into nothing?"

You can already cut-and-paste non-textual data.  Don't think of it as
pasting a string of text, think of it as pasting a URL object.  Just
like you can drag-n-drop a link from a browser and get a text string of
the URL out of it.

> 
> To introduce "different kind of pastes" would be very confusing. More confusing
> than having to choose between visible elements.  A visible element will always
> feel more "real" to relate to.
> 
> But the bottom line remains: Why should I be forced to use *the keyboard* in
> order to paste with *the mouse*? Once the GUI is established, that is NOT a
> good interface.

You aren't.  Several different people have said that several times.

> 
> I want to paste a location/filename/path, be able to edit it if needed, click an
> OK or OPEN button - in as few operations as possible. It should all be doable
> with mouse only.

Good luck editing the path using the mouse only if you are forced to
operate on the URL as a string.  ;-)

> 
> 
> R.K.Aa
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability
> 
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.