Re: To Dialog or Not To Dialog (#161027)

Subject: Re: To Dialog or Not To Dialog (#161027)
From: scot <scot -at- HCI -dot- COM -dot- AU>
Date: Thu, 4 Apr 1996 17:56:30 +1000

>I'm not going to argue that point with you because I agree. However, where
>starting point lies on the continuum of experience is quite important and
>vary depending upon the intended audience for your documentation and the target
>user for the product.

I won't ague THIS point either, except I think your assessment of a
corporate environment is incorrect -- and covers up for the basic
irresponsibility of the company's end-user environment if this training
and/or information is not supplied (see below; if -I- did so, it's forcing
-my- clients to pay for the deficiencies of -their- clients, and generally,
my clients don't like that).

>For holistic learners (those who learn easily in new contexts and have broad
>experience to aid them), assuming a higher level of knowledge is fine. For
>serialistic learners, you need to give them more details about the environment
>into which they are about to venture, or they will toss out your manual as soon
>as they find instructions that include foreign interface elements.

>The point? Make assumptions based on what your audience knows, not on what you
>believe they SHOULD know.

Well, that's all very well, but I have an obligation to our clients to keep
costs reasonable too. Most often, I cannot justify including general "how to
use windows" sections in manuals because it drives the costs up - and nearly
EVERY time I have suggested a basic introduction to the Use of Windows, the
client has insisted it be taken out.

Aditionally to that point, why should my clients (lets say its some business
application) pay for the deficiencies of _their_ client organisations if
these don't want to make basic manuals or training available to their users?
If they (my clients) don't see themselves fulfilling that role, I don't see
I should be insistent about it.

So; the -General- assumptions I make, unless I have some specific
information that shows me otherwise**, are - they use a Windows computer,
therefore they are familiar with the basic operation of that system, or at
least the information they need to find out how to do this is available, in
some form, to them (there _is_ adequate online help that installs by default
with Win 95). I've seen manuals that have procedures littered with stuff like;

'Select the value you want from the list by clicking on the little
down-pointing arrow to the right of the field. A list pops down and you can
scroll through the list with the scroll bars on the right of the list.
Select the item you want by clicking on it with the mouse'

.. etc. Obviously (to me) this is wrong -- for a start it ignores
alternative ways that you might be able to get the value you want (with the
keyboard, or by typting it in directly), and its just flotsam that gets in
the way of the procedure anyway. And, how to use a 'combo box', is something
already covered in the Windows documentation. I always include pointers to
the existing documentation. If the user doesn't know, they have an avenue
they can use to find out. Its just as inconvenient as flipping to an
introductory chapter in the manual anyway!

BTW, if there -are- 'foreign interface elements' (ie not Windows-standard)
in the program, I will explain their use. Sometimes, too, you have to tell
users that certain functions (eg Edit) are available by double-clicking on
an item, etc, but generally I don't find it neccessary to explain every
basic Windows function.

If I took your statement about "Make assumptions based on what your audience
knows, not on what you believe they SHOULD know." literally (ie at the very
lowest common denominator), we'd all have to be including the "Meet the
mouse" tutorial in our doco. If they're serial learners, then they should be
learning 'serially' by looking at that tutorial before they even advance
past chapter 1 of ANY manual, and I will tell them so at the beginning of
the bulk of the manuals I write (well, project manage nowadays).


Crikey, it's at the wrong end of the message, mate. ;)

cheers, scot.

** for example, online help for a PDA-based application used by Railway
Maintenance staff in the field. Of course, the assumption is that they don't
ANYTHING about computers, the manual is locked in a drawer back at their
regional HQ, and they retained enough of the basic training to remember you
use the machine by tapping the screen with the special Pen (and that's ALL
they retained). Oh, and that also, that it was likely that they are from a
NESB (Non English Speaking Background), and their English language skills
are very basic.

PS. Obviously for completely proprietry programs that run on say, Mainframes
or in character-mode Unix terminals, or on totally dementedly-programmed
Windows applications -- and I have seen a few -- where the interface is not
standardised, it must be explained in detail.
#include HCI Consulting, Sydney, AU
#include std.disclaimer.

Previous by Author: Re: To Dialog or Not To Dialog (#117530)
Next by Author: Re: to dialog or not to dialog
Previous by Thread: Re: To Dialog or Not To Dialog (#161027)
Next by Thread: Converting Word 2 help files to Word 6 help files

What this post helpful? Share it with friends and colleagues:

Sponsored Ads

Sponsored Ads