Hierarchy of task-based material

[Tim Altom <taltom -at- IQUEST -dot- NET>]

A poster (I forget who...sorry) asked awhile back about a 75-page manual and
how it should be organized. I tossed out the opinion at the time that it
should probably be done hierarchically, as did some others on the list.

As I was scanning some back issues of the Journal, though, I came across an
article that made me rethink that position. It's from the first quarter of
1991 "Alphabetic Software Manuals". In it, David Dobrin develops the idea of
using an old idea, that of the "lookup" manual that was so common in the
early UNIX days. Those who used DOS machines for several years will remember
the "command list" lookup manual that came with DOS. It was immensely useful
for advanced users, but worthless for newbies.

And that's Dobrin's point. If the poster with the 75-pager is aiming at a
sophisticated, trained audience, then perhaps he/she could consider doing a
manual that's entirely task-list based. Such a work starts with a list of
keywords, organizes them into sensible sections, then assigns levels of
needed expansion to each keyword. Write text for each keyword, and voila'!
Instant manual.

This only works for users who are essentially up to speed, though. Does
anybody out there do manuals like this, having thought through the issues?
And what does the original poster think?

Tim Altom
Vice President, Simply Written, Inc.
317.899.5882 (voice) 317.899.5987 (fax)
FrameMaker support  ForeHelp support

Makers of DuoFrame, giving you online help and paper
documentation from a single parent FrameMaker document.

http://www.simplywritten.com/simply

                  TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send administrative commands
         ALL other questions or problems concerning the list
       should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-