Re: [Usability] The New File Selector

[Uri David Akavia <uridavid netvision net il>]

I am using GTK 2.3.6

On Sat, 2004-03-06 at 20:25, Ryan McDougall wrote:
> 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...
> 

Only if you press Ctrl-L

> > 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.
> 

Tab completion has two major failings as it is now
first - dots aren't parsed. Type ../ in a directory and you don't get
subdirectories.
two - the files aren't updated. Which means that for every time you want
to use tab-completion you have to press Ctrl-L, type, and retype.
Previously, I could just skim directories until I found the file I was
looking for.

> > 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!
> 

As I stated, the files aren't updated so it isn't one extra keystroke.
Second, I do open a lot of files, and I got used to using only the
keyboard in a quick and rapid manner.

> > 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.
> 

Using the file manager isn't as rapid. Let's assume I have an
application open - opening the file selector and selecting the file is
quicker than opening a browser, going to the right directory and
selecting the file.
Second - in GNOME 2.4 (I don't know about 2.6), opening a file that
doesn't have an application assigned was one hell of a PITA. Even if
this has been fixed, it is far quicker to choose open from within the
application, and choose the file, than open the Browser, go to the
directory, right-click on the file, select another application.
Third - assuming I already have an application open, why on earth should
I have to open another one (Browser) in order to reach another file?

> 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.
> 

The problem with this is twofold. I'm not certain I have bookmarks, or
that I can have a small amount of bookmarks to cover the files I open.
Second - using bookmarks forces me to use the mouse.

> 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. 
> 

It has a version is weaker in functionality. 
Since we both agree that there should be a Gconf key for permanent
placement of the text box, my hope is that if it is implemented, the
text box will have the same functionality as the previous file selector.

So, let me see if I understand correctly - the basic reason of partly
removing the previous functionality is that Nautilus has moved to the a
Spatial mode? Since the developers have provided an option for a
non-Spatial browser, I believe that it would be logical to provide a
non-Spatial file selector.

Don't get me wrong, I think that the new file selector has a lot of
advantages regarding the old one. I just think it has a lot of
disadvantages in regards to the old one, and I wanted to make my voice
heard before the final release.

Yours,

Uri David Akavia