Re: SV: (no subject)

[Peter Schachte <schachte cs mu OZ AU>]

On Fri, Nov 17, 2000 at 04:06:03AM -0500, Liam Quin wrote:
> The documentation would have to be written with the idea that the
> computer is at fault for being too difficult to use, too.

I don't think any help system with better-named menu items, and text written
with the orientation that the user is right, and better indexing, is going to
do much to help users until two things happen:


    1)  Applications should be designed by first deciding what mental model
	users should have of the application, and only then designing the
	human interface.  No amount of explaining can fix the problem if the
	program's interface was designed to fit the programmer's model of the
	application (or worse, the programmer's convenience), rather than the
	user's.  NB:  the Windows model isn't necessary the right one!

    2)  The documentation should begin with a discussion of the mental model
	users should have when using the program.  This should be kept very
	short and intuitive, with lots of hyperlinks into more complete
	discussions of details elsewhere in the document.  There are many
	reasons that the program's model, even if ideal, should be explained
	explicitly:

	 o  The user may have used another program that uses a different
	    (worse) model which he may be expecting.

	 o  The program may choose to use a slightly non-intuitive model or
	    extend the natural model in some subtle ways because it makes
	    operation more efficient or convenient for the user.

	 o  There may be several different but equally intuitive models, and
	    the documentation should tell the user what choices the
	    implementors made.

	 o  It may not be possible or tractable to implement the model the user
	    would like, so a less comfortable interface may be necessary.  In
	    such cases, the user deserves a candid explanation.

The problem of poorly indexed help systems probably often arises because the
programmer thinks of things differently than the user does.  Users will often
be able to figure out how to do what they want, or at least how to look it up
in the documentation, if they understand the model of the program and it
matches their mental model reasonably closely.  For example, if the user
understands that the model of the editor they are using is that changes take
effect immediately and there is an undo system (rather than changes take
effect only when explicitly saved), then they won't be confused by the lack of
a "save" menu item.  Another example is the GIMP.  I've had some limited
success in using it, but most often I just get frustrated by it.  I have the
distinct impression that it is a wonderful program that I could use
effectively if I just understood the mental model behind it.  I've never used
photoshop.  I've used plenty of pixmap and vector editors, but the GIMP model
is rather different from either.  I suspect that the mental model could be
explained in a few pages of reading, but I couldn't find them in the manual,
and I don't want to read the whole manual to infer the model.

-- 
Peter Schachte <schachte cs mu OZ AU>  He that waiteth for all men to be
http://www.cs.mu.oz.au/~schachte/      satisfied with his plan, let him seek
Phone:  +61 3 8344 9166                eternal life, for he shall need it.
Fax:    +61 3 9348 1184                    -- Mark Twain