Re: [Usability] The New File Selector



On Sat, 2004-04-03 at 20:31 +0200, Uri David Akavia wrote:

> I still don't see how the new spatial model replaces the need for me to
> find files via the file selector, which was easy in the previous
> version.

I don't think it'll replace the need to use the file selector, but I
hope file selector usage goes down since its a redundant concept.

> I also have several problems with the new spatial model - I can't add a
> toolbar or location bar, without switching to non-spatial mode. This

The lack of location bar is kind of part of the spatial concept, the
window *is* the location. We want to hide the file system dependant
parts, and make the illusion that folders are actual spatial places. Its
not perfect, I'm just giving you the reasoning behind the decision. The
location can be accessed quickly with the File->Open Location or Ctrl-l.

> seems to defeat the purpose of the new model - I'll never get used to it
> if I stay with the browser model. I think that the Location bar should
> be optional, in Nautilus, as well as the file selector.

There is an gconf option to allow browser mode to be always default, and
a GUI option is said to be in the works. A nice solution might be a
"Apple style Drawer" widget that pops up al la Safari.

> 
> > 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. 
> > 
> Good, but ../somefile definitely does not work (../directory does work).
> I have not been able to select a file via the location bar. If it is
> possible, please instruct me how to do so.

It appears you can access file that way, I just did it with gEdit by
specifying the file ../file with GTK+ 2.4.0. The file becomes
highlighted in the chooser dialogue, you just have to press enter to
choose it.

My nautilus is 2.5.91.

> 
> > 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.
> > 
> I keep a lot of files (articles downloaded) on my computer. These
> articles are kept in different directories, depending on their subject
> (or the subject I was researching when I downloaded them).
> If I'm looking at a certain article in full-screen mode, I am not
> enthusiastic about going to miniminze the file (or switch desktops),
> open the browser, descend 3-6 levels to find the next file I am
> searching for, close all the windows I opened and open the relevant
> file.

Yeah, right now things aren't great for using nautilus instead of the
file chooser, but if we design nautilus properly, it wont be more work.
I rarely use the file chooser, but I sometimes use it.

Also, I think you may be used to having too many directory levels from
past organizational habits. Paring down the nesting may speed things up
a bit. Personally, nothing I regularly use has more than two or three
levels of nesting. The only deep nesting I have is on my music, but
thats ok since I use rhythmbox to organize that.

> Under the previous file selector, I would simply hit Ctrl-O,
> ../../New1<tab>/New2<tab>/file<tab> Enter and open the new file.

My chooser testing (ok, playing) works pretty similar to the above,
except instead of <tab> i was pressing arrow keys.

Ctrl-O ../../New1<right arrow>/New2<right arrow>/file<right arrow> Enter
Enter

One more enter than yours?

> 
> > 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.
> > 
> 
> As I stated, I use it to tranverse the filesystem. Having a bookmark for
> each article I access would overflow in a rather small amount of time. 

Yeah, thats not what they should be used for. A bookmark for Documents,
but not each directory.

> 
> > 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
> > 
> No it isn't.
> File Chooser
> -----------
> Clicking the File Chooser button (Or hitting Ctrl-O)
> Clicking up directory (once or twice, if at all necessary, I'm likely to
> open  a file in the same directory)
> Choosing a file among a list
> Opening the file
> 
> Nautilus
> --------
> Starting from the root file system, moving to the new location (thus
> repeating all the movements necessary to arrive to the present locaion,
> or a common ancestor)
> Choosing the file
> Opening it

This may have more to do with how you use your desktop. This is how it'd
work on my desktop:

Nautilus
--------
Click on one of the several shortcuts on the desktop
Clicking down one or two directories (closing parent folders as we go
via middle click)
Choose a file among a list
Opening the file
Optionally close the current folder if I wont use it again, or leave it
open to make things quicker for other file management tasks later.

My nautilus looks more like your File Chooser. I think you are just used
to using nautilus sub-optimally.

> 
> The File Chooser is faster, much faster when tab-completion is enabled
> by default, including the file name.

If used properly, I don't see yet how that is the case. Just because you
use things in a way thats slower, doesn't mean that its intrinsically
slower.

> 
> Personally, I didn't use Nautilus that much for opening files that
> weren't easily reachable from my desktop (a lot of files sit in a dos
> partition, common to Windows and Linux on my computer). When I had to
> reach a file far away from the desktop (let's say I wanted to open
> /usr/src/Some_package/doc/README.txt) I would be more likely to use a
> terminal or a file selector (from an open application) rather than use

Me too, but its not that often that I have to get to those things. One
thing to keep in mind is that nautilus can get you there just as quickly
as a terminal via the Ctrl-l feature. The only problem is that Ctr-l
uses the nautilus viewer, not the mime associated application.

> Nautilus. Two things seem to change that in GNOME 2.6 - One, the new
> file selector is as easy as Nautilus (not very, for me, or so it seems)
> Two, the new computer icon makes it easier to reach files farther away.

Like I said before, I can use it just as quickly. Do you need to adjust
learnt behaviours to get back to your previous productivity? I'm opened
to adjusting what we have currently, but as of yet I'm not convinced.

> 
> > This is a bug with mime-types, and nautilus handling there of, and not a
> > reason to design a bad chooser.
> > 
> This is still a bug with current GNOME2.6. Why should it be ignored when
> designing a good chooser?
> 
> > > 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
> 
> The reasons "that's the way it has always been", "this is the way it
> happens in other systesms so people using more than just GNOME2.6 can
> transfer skills" are valid reasons in my book.

For how long is it OK to hold on to things for tradition sake? Should we
still make rotary phones because someone might be used to it? At some
point things have to progress, maybe not now, but soon I think.

> 
> > 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.
> > 
> 
> I've explained my problems with the new UI. I've also tried spatial
> Nautilus. I still maintain that this is far more clutter than the old
> UI.

Fair enough, but I think you can regain your productivity with the new
GNOME with a little retraining. Its up to you if you think its worth it.
*I* think its a better system than windows or KDE.

> 
> > What is a non-spatial file chooser? I doubt very much anyone is
> > interested in maintaining two different kinds of file choosers.
> > 
> 
> I believe that our differences are more philosophical than practical.

Probably. ;)

> A non-spatial file chooser? One that has the location bar enabled by
> default (after switching an option), and allows you to use

Thats possible, but a case would have to made to the developers, and
argued. There are issues caused by variable UIs however.

> tab-completion to select files. (It can be updated when you press enter,
> this doesn't matter much)

Do you mean update the chooser dialogue's path when a completion is
made? There are arguments for and against doing that. What if you
complete to the wrong place, and then you get lost? Its not a problem
for you or I, but it could be a problem for others.

> Let's see what we seem to agree
> Location should parse ../ and regex corretly.
> The location bar should have an option for always on.

It currently parses "../" correctly, but doesn't do "~/" yet.

> 
> What we don't seem to agree on - the location bar should allow you to
> select the file as well.

It does. Its pretty handy, so I think I agree with you there too.
Although I think it should use the mime associated app, not the nautilus
viewer.

> 
> Adding all these three functions will provide me (and others) with a
> non-spatial file browser. Is there any reason not to enable this, other
> than "It doesn't mesh with the new vision for GNOME?"

Well, not meshing with a vision is a good reason for design choices,
since vision is design. Some visions are better than others, but imagine
if everything was designed by committee...

Also, this is not a democracy, its a meritocracy; so having a position
is different from arguing it persuasively. If you think you have a
strong case, then state it as a formal proposal to Usability, Seth, and
gtk-devel.

> 
> Yours,
> 
> Uri David Akavia

Cheers,
Ryan




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