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

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

>     Avoid backward metaphors such as popup menus as opposed to
>     dropdown menus

Susan wrote this, not I, but I think it might be a reference to the
inconsistency between metaphors in various places.  For instance, the
main Nautilus window has pull-down menus located at the *top* of the
screen that offer additional functionality and commands.  There are
also lots of buttons up there that fundamentally change how what's
underneath works (like the "view as icons" menu).  The tree sidebar,
on the other hand, has tabs down at the *bottom* which fundamentally
change how what's above works.  As mentioned, people had trouble
noticing these tabs, and once they were pointed out, had several
different sorts of trouble using them.

Personally, I find the pop-up menus in the "View as..." style to be
significantly less noticable than pull-down menus.  (I've actually
submitted bug reports on control panel saying, "this functionality
should be added") despite it being accessible via one of these menus.

In this specific case, I see no reason why the "View as..." pop-up
menu shouldn't be integrated into the "View" pull-down menu.

I think the sidebar notion is really cool, and I find the Tree and
Help especially useful (and I use Bookmarks and Search in a similar
way in Mozilla all the time).  However, the best improvement to the UI
I could think of would be to find a better way to present these
features.  I think I suggested in my notes to eliminate the default
sidebar, which just gives you info about the dir or file you're
currently looking at.  It could be replaced by a line of text at the
bottom of the screen.  The buttons that occasionally appear there
could be replaced by an optional dialog that asks you what app you
want to use, *after* you've already indicated you want to open a given
file.

People found the tree display incredibly useful, but as I mentioned,
had trouble discovering it, and had even more trouble returning to the
default sidebar.

> Dragging any file to the desktop should work in Nautilus. Do we know
> why it didn't work for the user test subjects?

We've since upgraded our system to PR3, and it seems to be working
fine now.  This was caused by an AFS interaction bug, reported as
#4968.  We were able to employ a workaround for subsequent tests.
(I'm not sure if all the AFS-related problems have been fixed,
though.)

> Nautilus does have a Duplicate menu item in the File menu. I guess
> no users looked there? It seems likely that the users looking for
> Copy under the Edit menu are familiar with Windows. Is there any
> evidence to suggest that users not familiar with Windows would
> expect a Copy command in the Edit menu, but not expect a Duplicate
> command in the File menu?

Most users did, in fact, expect to see the Copy command (for files) in
the Edit menu.  When they saw only "Copy text", as I recall they
generally checked the File menu next.  In general, I've observed that
menu rearrangements like this actually have relatively little impact
on usability, though it is very satisfying to have things in
intuitively obvious places.  Most people seem to find the "File" and
"Edit" menus to both be relatively intuitive places to find the
command that copies files.  Though as you point out, Windows users are
biased toward the Edit menu.  Personally, I share that bias, despite
being a full-time Linux user of many years.  

The funamental impediment to successful copying using the pull-down
menus was the fact that the File/Duplicate menu item was greyed out.
This was because users had double-clicked on the file.  This had the
effect of putting the display into "View as text" mode.  See bug
#3272.

We then had to restrain ourselves while we watched people come up with
all sorts of tortured and creative ways around this bug, including
using the Tree, drag-and-drop between multiple windows, opening in
Emacs and saving, using the command line, and just plain giving up.

I guess that's what we get for testing with pre-release software.  9)
But it was quite useful anyway, both in evaluating the parts of the
system that *were* working as designed, and in finding that sort of
bug which novices have a knack for stumbling over as soon as they
touch the mouse, but which developers never seem to encounter.  8)

Yours in usability,

Beland

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