Re: [Usability] The New File Selector

[Ryan McDougall <ryan mcdougall telusplanet net>]

Thanks for replying Uri, your mail highlights a lot of common
misconceptions about usability. Often people learn how to become
proficient with a broken UI, and when someone tries to change the UI and
improve it, many users are upset that things don't work the same. They
then conclude that because their productivity has gone down, the new UI
must be broken. However, once the users "retrain" themselves to how the
new UI is supposed to work, instead of fighting it, they find that they
are indeed better off than before. You would be surprised the tortuous
interface designs people have become accustomed to, and indeed relish!

Please try out the spatial mode when 2.6 comes out, and try to think in
tune with the UI, and if that doesn't work out come back with your more
informed criticisms.

On Tue, 2004-03-09 at 22:48 +0200, Uri David Akavia wrote:
> 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.
> > > 
[snip]
> > 
> > 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.

There are still plenty of bugs in the file selector, but the completion
"../somefile" appears to work. Even if it doesn't work now, the fact
that it partially works means it will be supported in the release
version. 

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

The file chooser isn't for file browsing, thats what the file manager is
for. If you can't find the file your looking for without browsing for
it, then the desktop has bigger problems than Ctrl-l. You'll note that
with spatial nautilus and new file system indexing apps like medusa or
storage, that "browsing" is an activity that will hopefully disappear
all together.

Please let me know what files that you access that are buried deep
enough that they are hard to find.

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

It is worth debating whether the text box should update the file view
with every completion, you might want to file a bug on it. This is not
how nautilus works, since there is no file view to update, so there
would be an inconsistency with nautilus.

What kind of files are you frequently opening? Any frequently accessed
files should be placed in the bookmark menu, and thus would not require
Ctrl-l at all. I'm curious as to how your using the file chooser.

[snip]

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

File Chooser			Nautilus
------------			--------
Clicking File Chooser button	Clicking Nautilus
Choosing a file	among a list	Choosing a file among a list
Opening the file		Opening the file

Seems pretty close to me. Both the chooser and nautilus behave almost
exactly the same (by design). The only difference is the chooser has a
bookmark menu which nautilus lacks by default, however in browse mode
its still there.

> 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 is a bug with mime-types, and nautilus handling there of, and not a
reason to design a bad chooser.

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

I don't agree, do you have anything to support your claim?

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

What one would be trying to do by eliminating the file chooser all
together is reduce the complexity or cruft of the UI by removing a
duplicated feature. There is no reason for the existence of a file
chooser other than "thats the way its always been". While using nautilus
to open all files appears to you to just add one more window to the
clutter (which shouldn't be a problem if the window manager is doing its
job properly), if you were to change your behaviour beyond what you have
learnt to do over years coping with with a bad UI, you might find that
the new design, with your new behaviour, is simpler.

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

As above, I'd like to know what files you are looking for -- but If you
have lots of file scattered all over then the problem is with the
organization (or lack thereof) of the file system, not the file chooser.

As for bookmarking forcing you to use the mouse -- it doesn't, period.

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

I while the Ctrl-l may not be easily discoverable, I don't agree that it
is less functional, as stated above. The reason the file chooser has
been designed this way is that it has a better UI that integrates well
with the future direction of GNOME, including spatial nautilus, which is
merely at the vanguard of the changes.

What is a non-spatial file chooser? I doubt very much anyone is
interested in maintaining two different kinds of file choosers.

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

You are always welcome to have your voice heard around me, but
realistically speaking, I don't see what you've stated above as
influencing the file chooser; just as its unlikely that my comments have
convinced you that the file chooser has a very good design.

> 
> Yours,
> 
> Uri David Akavia

Cheers,
Ryan