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 am a contract writer and have had conversations with two potential
>clients both of whom wanted to know if I had ever documented an object
>oriented application before. I had to answer "no".
>My question is how is writing for an OOA different? When I worked in a
>corporate environment, I wrote software user manuals and from the little
>these folks have told me, I deduce that that is what they need.
You should probably have answered "probably". If you've ever documented
an application with a graphical user interface, it was *probably*
developed in an object-oriented language. C++ is the most common OO
language used to develop applications nowadays.
The primary difference in documenting an OO-based application is that
it is, by nature, event-driven rather than run sequentially or menu-driven.
That means that the software does nothing until an "event" occurs to
begin a process. An event might be keyboard input, mouse input, or soft-
ware-driven input such as a timer event or a call from another program.
This differs from sequentially-run programs (where you start the process
and it stops when it's done) and menu-driven programs (where you move
through the program via the menus) in that there is no "expected" path
through the software. The system must be ready to accept any input
"event" that happens while it is running. (Some OO software can actually
start itself when an event that it is interested in occurs. For example,
I can start Eudora, create a new mail message, and attach a file to the
message--all by dragging a file from the Windows File Manager or Explorer
and dropping it on top of the Eudora icon that sits on my desktop.)
So, when you're documenting an OO, or event-driven, application it is
much more important to be task-centric rather than function- or interface-
centric. Also, any "structure" imposed on the user in the way the
application is used mostly comes from the documentation since it's not
inherent in the application itself--although the application can
disallow certain actions until other certain actions have happened,
most commonly by dimming or hiding controls until specific criteria is
met.
Sue Gallagher
sgallagher -at- expersoft -dot- com
-- The _Guide_ is definitive.
Reality is frequently inaccurate.
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-
