[Usability]Usability test. Nautilus idiom. (Was: Nautilus tree sidebar / location field)

[Gregory Merchan <merchan phys lsu edu>]

On Fri, Aug 02, 2002 at 08:03:06PM +0300, Tuomas Kuosmanen wrote:
> On Fri, 2002-08-02 at 16:07, Reinout van Schouwen wrote:
> > <snip>
<snip>
> But I still think the location bar is more useful, since I can just type
> Ctrl-L on the already focused nautilus window, and it focuses the entry,
> so I can just type the thing and press enter. With the applet I'd need
> to move focus to it etc.. 
> 
> But try the above, that works too, and keep the location bar hidden.

Part of this seems deserving of a usability test. In most general terms,
the question for a test to answer is:
  Which is better:
    1) a roll-out location bar as Nautilus has now, or
    2) a dialog?

I'm not sure offhand what better would mean or what kind of test would be
needed. I suspect a roll-out sheet, like MacOS X has, is probably best;
but that's purely speculation.


> > > I am wondering what is wrong with the current solution? It works really
> > > well and if you dont like the location bar just keep it hidden..?
> > 
> > There are good reasons to -at least- keep the location bar hidden by
> > default; they are discussed in bug 82107.
> 
> That I understand. Hiding it makes things cleaner, but removing it would
> just make it very hard to jump to a very "far-away" path. Browsing from
> /home/tigert/my_very/long/path/that/contains/the/files up first to root
> level and then to some dir takes a lot of clicks :-/

I wanted to address this when I called for arguments pro and contra the
navigations and view types.

Either a Smalltalk/NeXT/MOSX browser widget (that's the multiple-column thing)
or a MacOS Finder outliner view (that's the main-view tree with files and
folders) would make long jumps much easier.

I think Nautilus needs to establish an learnable idiom that is useful
for what 90% of people do 90% of the time. [numbers are for show]
I think it needs to focus on being the desktop shell first and foremost.
In part, this means that the virtual file hierarchy (real fs, vfolders, etc.)
need to be completely consistent; the already noted up/back navigation
problems are major problems, IMO. Another part is the same as the
requirements for panel menu editing; not necessarily for that purpose,
but because what one needs for that one should have for the rest. That
program launchers are .desktop files is an implementation detail that
should not seep into the desktop shell; opening the properties of one
and altering its data should be the same. If I open my home directory
and double-click on my ~/Mail folder, I want to read my mail not look
at a bunch of cryptic maildir files. If I have bundles/appdirs, I want
them to be displayed properly and behave properly. All of this is part
of what it means to have a desktop shell, as Nautilus used to be called,
instead of just a file manager.


Cheers,
Greg Merchan