Re: [Usability] Efficient navigation in nautilus

[Christian Schneider <c schneider scram de>]

> > What exactly do you mean by "navigate with the open folder". Do you
> > mean with the mouse or keyboard?
> >    
>
> I mean that if you have a folder (/foo/bar) open and need to navigate down on that
> path (to /foo/bar/baz/nilli), why on earth you should open the location dialog to
> do it? At least that was what I understood you were doing...
>  
It is one thing you should be able to do. It is usefull in a directory 
with many subdirectories or if you are just faster with the keyboard 
than the mouse. And of course you could also select a file this way.

>  
>
> > > I've always thought that moving my hand to the mouse from the
> > > keyboard is something like "mildly annoying", but to say that the cursor
> > > pad (a part of the keyboard, I presume) is too far to be usable...
> > > Words escape me :)
> > >      
> > Hehe I was just comparing to bash ... and bash is more effective here.
> >    
>
> Of course. But I don't think nautilus needs to mimic bash in its behavior.
> Use the real thing if you really want to navigate with typing the path
> (which actually sounds like a silly thing to do in graphical environment
> now that I think about it.)
>  
Why do you think this is silly? For a novice user ease of use counts, 
for a pro user speed counts.
So as we have it now the pro user can only switch to bash if he wants 
speed. If he can type in the graphical
interface he doesnīt need to switch to bash in most cases. While I 
absolutely think that gnome should be very user friendly and apealing to 
novice users we should bever forget the pro users.

>  
>
> > > > btw. I also canīt think of anyone who would need the tab key for 
> > > > switching input elements inside the dialog.
> > > >        
> > > -o/ Me!
> > >      
> > Do you really use this? Tab is ok inside a larger dialog when no mouse 
> > is at hand but when there is only an input field and cancel and ok 
> > button the keys esc and enter do a much better job.
> >    
>
> Well, as I have said, it should work the same way in every dialog to be
> consitent. You can't have such widespread keys doing different things
> in a similar context. You just can't, no matter how much it would help
> one particular use-case.
>
>  
In a dialog it would be problematic but in a panel applet I see not much 
of a problem. The Tab key is not used there.

> > btw. I have one other idea for a keyboard shortcut in nautilus. What 
> > about using something like Ctrl-t to open the userīs default terminal 
> > app with the path set to the current folder.
> >    
>
> <sarcasm>
> ...And lets adapt all the other "nifty" features from konquer!
> </sarcasm>
>
>  
I think we should not adapt features that crowd the interface. But 
keyboard shortcuts donīt crowd it. A novice user will just not know 
about the feature and it will not tamper with his experience of the 
system. The only thing is that each shortcut takes away a key. So of 
course we should not give any silly function a shortcut.

> > This is surely very
> > easy to implement and every admin will thank you ;-)
> > It would also be nice to have a shortcut in gnome-terminal to open
> > a nautilus folder for the current path.
> >    
>
> alias nw='nautilus [some options perhaps] $CWD'
> and then a little script to the nautilus-scripts directory to open
> a terminal (though this probably isn't doable yet, IIRC).
>
>  
Very nice. I have checked for the correct alias:
alias nw='nautilus $PWD&'
This one works for me. No further need for a shortcut in the terminal 
then ;-)

But the shortcut in nautilus to open a shell would still be nice.

> > We really need to find a way to end this old debate about command line 
> > vs graphical interfaces. As an admin I would like to be able to use
> > both and switch between them very easily.
> >    
>
> Keep a terminal open minimized and alt-tab there when in need. That's
> what I do (until I have mastered the ability to not use the terminal, still
> in training...).
>
>  
Thatīs also what  I do. But the problem with this is that the terminal 
does not know about your folder context.
The normal behavior is that you nvaigate with the mouse to a certain 
folder. Then there is a task where the cli is needed. Now you have to 
navigate a second time in the cli to the same location.
I donīt think the ability to work without a shell is really needed. 
There are some cases that will never be possible in a grahpical 
environment. I would rather like to have an interface that gives me the 
freedom to use both interfaces.