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.
Subject:Re[2]: Messages. . .and new thread From:lpraderio <lpraderi -at- CLIFF -dot- WHOI -dot- EDU> Date:Fri, 28 May 1993 11:20:01 EDT
I believe that in a process-oriented document, writers should give the user one
clear, easy way to get from point A to B even if the features in the software
give you 2 or 3 different ways to issue a command. Adding lots of "you can
also..." just layers too much junk (no matter how correct) on top of one task.
Laura Praderio
Woods Hole Oceanographic Institution
lpraderio -at- whoi -dot- edu
-------------------------------
Now I'd like to add a new topic to the fire. I'm interested in finding
out how other writers have made the transition from writing feature-oriented
software documentation to process-oriented documentation. When an
application is extremely complex and there are multiple ways to accomplish
the same task, it can be difficult to work in every feature that
is related to a particular process. Is it our "duty" to use every single
feature that is documented in a reference manual in a corresponding
process-oriented users manual, especially when some of the functionality
is redundant and would cause confusing lateral offshoots in an otherwise
linear and iterative process flow? (redesigning the product is not an option)
Thanks in advance for your input.
Lisa Kaytes
(lisa -at- warren -dot- mentorg -dot- com)
