TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I was refering to the properly structured
understanding needed for creating task-oriented
end-user documentation on the product. (I generally
assume that end-user documentation should be as task
oriented as possible.) Here, as you point out, what
is needed is a properly structured understanding of
how essential tasks interrelate - not features.
Note: Properly done, software requirements specs are
structured the same way as end-user documentation.
P.S. Notice how I cleverly avoided use of the taboo
"DXD" term - (where X stands for a secret letter) ;-)
Tony
--- Dick Margulis <margulisd -at- comcast -dot- net> wrote:
Tony Markos wrote:
And what better way to organize the text than for the
writer to have a properly structured understanding
of the product.
Dick Margulis responds:
....What Sharon and others are saying is something
like this: The structure of a product (a tree that
starts at the whole product and then divides down into
modules, components, parts, and adjustment tolerances,
for example) may be useful for documenting the bill of
materials or the assembly instructions. However, from
the point of view of the user of the product, that
structure is not necessarily meaningful.
A document may follow a tree structure in which the
top node is "all tasks you can perform with this
product" and it
divides down into groups of tasks (accounting,
logistics, order fulfillment)and then into individual
tasks, steps, and options within steps. That may have
nothing to do with the physical or virtual
architecture of the product; it is nonetheless a
structure that is meaningful to the user. Obviously
there
are other possible structures that may be more
appropriate than this one, depending on the type of
product and the purpose of the document. This is just
one simple example.
Now suppose we start the analysis from the point
ofview of your
favorite methodology, data flow. Again, that might be
a great way to organize development documents, but I
don't think I'd want to use that approach to instruct
a user on the dashboard features or maintenance
requirements of her new car. And yet I'm certainly
going to apply a structure to the document, just not
one that corresponds to the information flow within
the car's control system.
>
> Dick
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
