Re: [Nautilus-list] Nautilus user testing at MIT

["John Sullivan" <sullivan eazel com>]

on 1/4/01 9:11 AM, Blad, John Erling at john erling blad aftenposten no
wrote:

>>> Here's the scenario.  We ask the testers to find a document, open it,
>>> make
>>> a change, and save it.
>>> 
>>> They find the document.  They open it, but they open it in the Nautilus
>>> window and then make the change and then try to save, but since they
>>> aren't
>>> in an edit window, of course, they can't.
>> 
>> Part of the problem here was that the old text viewer let you change the
>> text but had no way to save changes. This was an obvious flaw in the text
>> viewer. The new text viewer does not have this flaw, so this problem
> should
>> be greatly reduced.
>> 
>> Of course, some people will still expect to be able to make changes in the
>> text viewers, and be surprised/frustrated when they can't. But at least
> the
>> UI won't mislead them into thinking that they can.
> 
> So they can't change the text, but why do they try to do that? Is there
> anything
> that can be done to stop that *before* they try? Learning by doing something
> wrong and then to have to redo the operation is not very clever.. and which
> one
> do the user blame? The application? Him/her -self? The programmer?

I don't think we are disagreeing here, but I'm not quite sure. In the
version that the users were tested on, they could change the text in a text
document viewed in Nautilus by typing or deleting, which was a bug because
no changes could be saved. This has since been corrected so that you can't
change the text by typing or deleting. Therefore we are "stopping them
before they try" and not forcing them to do something wrong and then redo
the operation.


>>> Eventually the dither around
>>> and
>>> find an editor.  Today, they found it in the left panel of the Nautilus
>>> window (hadn't knoticed that before), but it isn't obvious.  The
>>> Windows/Mac intuition is that if you double click on a text document, it
>>> opens in an editor.
>> 
>> I can't help but gripe about this misuse of the word "intuition". It's
> true
>> that Nautilus does not behave exactly like Windows or Mac in that by
> default
>> you view documents in Nautilus and have to take a different step to open
>> them in external applications. But this has nothing to do with
> "intuition",
>> unless you cheapen "intuition" to mean simply "expectation based on using
>> somewhat similar programs in the past". If you follow that route, then you
>> start calling everything new "non-intuitive" because it's not exactly like
>> its predecessors.
> 
> At least this is two different problems, one is how you make something
> intuitive
> for someone that is used to an other environment, the next is how you make
> something intuitive in this environment. More generally I gess most users
> make
> some kind of schemata for "computers" and more spesific ones for Macs,
> Windoze,
> KDE and Gnome. As so many people migrates from Windoze you can't simply
> dismiss
> the users knowledge from this particular environment.

I agree that we can't ignore past practice and people's experience. I was
just trying to point out the trap of using "intuitive" to mean "the same as
what was done in the past". When that kind of thinking is embedded, it makes
all changes seem bad. For example, dragging disks to the trash to eject them
has long been considered a UI design mistake on the Macintosh. But Mac users
are used to it, so you could say that other platforms that don't do this are
"unintuitive" for Mac users. I think this terminology causes more harm than
good.


John