Re: Task-based vs. descriptive online help?

[Chris <cud -at- arrakis -dot- es>]

I actually "designed" a reference help...  Or should I say, I had the
temerity to believe it was a good idea.  That was the help system for
FrameMaker 4.0 & 5.0.  We redesigned the doc set for FrameMaker,
and decided to do away with the Reference manual (previous versions had
a Ref man and a User's man).  So all that ref material had to go
somewhere, and Help was elected.  Was it a good idea?  I thought so.

We conceived of the doc set as follows - the User's guide might be a
grammar text, and the Help might be a dictionary.  This dictionary was
to have every noun (U/I element), verb (command), and modifier (property
setting, syntax, etc.) in the lexicon.  And so we thought the two would
compliment each other.  (Note - all this was before a mouse-over would
easily produce a tool-tip.)  (Also, now that I think of it, the concept
of noun isn't technically accurate.  In a product's lexicon, a noun
should be a data object that the product somehow processes.)

We made the help system's structure reflect (as much as possible) the
structure of the product, thinking that might have instructive value. 
We assumed ourselves experts, and made arbitrary categories to reflect
(or group together) specific interface elements that fell within
specific tasks.  And each such group had an overview that (presumably)
tied the group together.  But no *procedures* per se.  The thought was
that if a user really needs a procedure, he's in deep enough trouble
that he should not be looking to Help.  This resulted in the ability to
make fascist pronouncements such as, "If you don't know how to make a
TOC, don't look to Help for the answer...  RTFM!"  In fact, oblique
hints to that sort of information *were* in the overviews.  

To be frank, I firmly believe there's a place for task-orientation.  But
I also believe there are places where it's inappropriate.  And I believe
two versions of the same task info is usually repetitiously redundant. 
I know this flies in the face of doctrine.

Anyway, if you did a help-click on a U/I item (say, the Foo check box),
you went to the description of that item.  You could see at a glance
what larger item you were within (what dialog box, for example).  You
could also see at a glance what were the related larger items, and visit
any one of them with one click.  And you could go to the overview of
that related group with one click, to see what we thought you should be
doing in that area of the product.  If you went to the Help TOC, you
could see a list of all the *task-like* groupings we imposed on the help
system.  And if you clicked any one of these top-level entries, you
could see the sub-list of all the larger U/I elements within that
group...  and go to whichever one you wanted.  Horizontal navigation,
where appropriate, was handled via xrefs within the discussions.  So you
had top-down, bottom-up, and horizontal navigation at your disposal -
Help in 3-d!  

Great theory, but was it effective?  I thought so, in my *totally*
unbiased opinion (ha, ha).  We entered it in an STC competetion.  It was
utterly panned because, well, it wasn't task-oriented.  

Then Adobe redesigned the doc set.

Cheers              cud

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**New Dates!!** San Francisco (Apr 16-17), San Jose (Mar 29-30)
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

IPCC 01, the IEEE International Professional Communication Conference,
October 24-27, 2001 at historic La Fonda in Santa Fe, New Mexico, USA.
CALL FOR PAPERS OPEN UNTIL MARCH 15.  http://ieeepcs.org/2001/

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.