Re: [Usability] The New File Selector



On Tue, 2004-03-02 at 08:53 +0200, Uri David Akavia wrote:
> Hello.
> 
> I have seen the new FileSelector on Footnotes, and I fail to understand
> the logic underlying it. Specifically, I fail to understand removing the
> text box, for entering the file name. While I accept that New Users may
> hesitate to use it, one of the high points of the GNOME file selector
> for me was tab-completion, allowing me quick and efficient file
> selection.
> I understand that some of the functionality remains, similar to mozilla
> type-ahead. This is much weaker for several reasons - Lack of an ability
> to see what has been typed, difficulty in correcting it and no easy

I don't know what you are talking about here, I have the chooser right
in front of me, and I fail to see why one can't see what one is
typing...

> tab-completion (which I also used to create filters such as work*.png).

Tab completion works perfectly, although at this time it doesn't appear
to support regular expressions. I'd be interested to hear if this is
planned for later, as it is a very powerful form of expression that
imposes no UI burden.

> Could you please explain the logic of removing the text box, and the
> very usefull functionality of tab-completion with it. 

> (I understand that
> I can get a text box by pressing Ctrl-L, but that is not an adequate
> replacement for me) 

Why is that not good enough for you? Its one extra keystroke. Do you
really open so many files that the burden of Ctrl-l is too great? If you
do then there is a UI problem somewhere else, so please let me know!

> If it is possible to have a permanent textbox
> present, by means of a Gconf key, most of my objections will vanish.

I actually would like to see such an option in place myself.

> 
> To summarize - could you explain the logic of removing the textbox? Is
> it possible to return it, using a Gconf key (and if so, which key)?
> 
> Yours,
> 
> Uri David Akavia
> 
> PS
> Please CC to me, as I am not subscribed.
> 

Seth can probably explain it all quite a bit better than I can, but in
the interest of good communication, I will give it a shot.

Firstly there is a very real question of why a file chooser is needed at
all. Using the file manager to choose files is a very valid and just as
speedy operation. I guess the reason we even have one is to support
platforms and apps that insist on using one.

Now, the new chooser UI was designed to integrate well with spatial
nautilus, and as such prefers selecting visual objects in "folder
space" (as opposed to file system space) to direct manipulation of path
names. The "folder space" is supposed to be a lot smaller than the file
system, ie it includes a set of bookmarks to most frequently used places
where 99% of all relevant files are supposed to be located. Therefore
choosing a file nested only a couple levels deep (as measured in mouse
or keyboard clicks for example) in the new UI will be a lot faster than
typing a whole path out for "most" users "most" of the time. 

Ex: If you do a lot of log file editing, you have a bookmark to /var/
log/. Click on bookmark, click on sub-directory, click on file. Versus
type "/v" tab "/log/somedir" tab "somefile" enter.

However, for lots of people they either want or need a text entry, since
it is naturally a very powerful tool, so it is still there. I repeat its
not gone, it has not been removed! In nautilus, to jump to a new
location, the keystroke is Ctrl-l, and they both look and behave the
same as text entries. 

My only problem with the current setup is that in nautilus there "jump
to location" function has a menu entry which is easily discoverable just
by browsing the menus. However, the file chooser appears to have no
means for a user to discover the text entry. I can imagine people coming
to the system and simply concluding that there IS NO text entry, just
because they can't find it!

Hope the above helps, but its not the definitive answer, in case someone
wants to flame me for being wrong -- its just my analysis of the
situation.

Cheers,
Ryan




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]