Re: [Nautilus-list] Results of MIT usability testing

["Christopher D. Beland" <beland MIT EDU>]

I realize this won't be changed for 1.0, but I'll address the issue
for the benefit of later design...


So I began the discussion by pointing out that users were expecting
that double-clicking on a file would bring up an external editor
rather than an inline viewer. 

I think I'll elaborate on that point a bit.  

I've personally noticed that when I'm hunting for an image or text
file in a directory, it's annoying to double click on the file, have
it replace the directory in the inline viewer, figure out it's the
wrong one, and then have to click "Back" and wait for the directory to
reload.  It's annoying not only because of performance problems that
will be corrected in later versions - Nautilus is slow to draw the
directory and slow to open files, but the external editors/viewers
start and draw quickly - but also because it's easier to figure out if
I've found the right one if I'm looking at the contents of the file
and the thumbnails of the other files at the same time (especially
with image files).  I might also want to look at more than one file at
once.

But the "open each item in a separate window" option isn't the right
solution because then when I double-click on a directory, I get a new
window that I don't want, instead of changing directories like it
should (assuming I didn't want this option on in the first place,
which some people actually do).

Putting files in the tree sidebar is not a good solution because it
gets too cluttered and is somewhat confusing.  (I've turned this
option off.)

I would argue that the usability tests show that the "Open with..."
buttons in the sidebar are a bad solution.  Users want and need the
tree sidebar in that space, and have trouble clearing that out of the
way to uncover the "Open with..." buttons.  I think it would be better
to keep the tree up all the time and move the functionality the
buttons offer elsewhere, rather than come up with some better way of
communicating to the user that it's possible to switch back and forth.

So the solution we ended up with was allowing the user to configure,
on a type-by-type basis, the desired behavior.  It was pointed out
that it would be horrible if the user had to choose defaults for
various MIME types (even a limited set) the very first time they use
Nautilis, before they could use the software.  (I agree.)

Now, the user can always right-click on a file and open the file
in any of N internal viewers and M external editors, but many users
will not realize that this is possible, especially new users.  The
file menu also contains all of these options if the user wants to do
something unusual.

So the real question is, what should happen when the user
double-clicks on a *file*?  I see four possibilities:

 1. View inline (current policy)
 2. Open in external editor
 3. Open in new Nautilus window
 4. Ask the user what to do 

Option 3 would just require splitting the "Open each item in a
separate window" item into two settings, one for files and one for
directories.  If it were not enabled for files, 1, 2, or 4 would
happen instead.

I would argue that the right answer actually depends on the file type,
and that usability testing can establish what the expectation is for
the most commonly encountered types, like plaintext, HTML, PDF,
PostScript, image, and audio files.  It might also depend on whether
the user level is set at Beginner, Intermediate or Advanced.  

Some examples...

For a Beginner, it makes sense to just go ahead and open an HTML file
inline.  We might assume these users would be unlikely to want to edit
this type of file.  An Expert, on the other hand, could be presented
with a dialog like this (with appropriate interlocks) for a wide
variety of file types:


  ( ) Show this file in built-in viewer  ( ) in new window
  ( ) Show this file in Mozilla
  ( ) Show this file in Netscape
  ( ) Show this file in Other...
  ( ) Edit this file in Emacs
  ( ) Edit this file in Other... 

  ( ) Don't ask me this again for HTML files


With some file types, there may be only one known handler (internal or
external), and so at least for Beginners and Intermediate users,
there's no need to ask what to do.

For users that want non-default behavior, accumulating information
about their preferences in an incremental manner is less intrusive and
bothersome than trying to do it all up front.  It's also less
confusing because the user has the context of "I'm opening a file" in
mind, and can more easily deduce what the dialog is asking.

> I just remembered that there was a nasty problem with the old Text
> viewer where it would let you delete/change text, though there was
> no way to save these changes. I think this bug may have been present
> in the version of Nautilus used for the user tests, though I'm not
> sure.

It was, in fact.

Actually, operation #1 (open inline) would be more useful if Nautilus
had built-in editing capability, in addition to built-in viewers.
(Hmm...I'm imagining a Bonoboized Emacs.  Eeep! 8)  Though that would
still not completely solve problems like "is this user trying to view
this file as HTML or edit it as text?" and "does the user want to
stare at this image all day, do they want to poke around the other
images in the directory at the same time, or do they want to add 'All
your base' to it in the GIMP?"


Usably but verbosely yours,

Beland

===============================================================
Christopher Beland - http://web.mit.edu/beland/www/contact.html
MIT STS/Course 6 (EECS)   -   MIT Athena User Interface Project              
===============================================================