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:The Edges have Finally Blurred From:"Wing, Michael J" <mjwing -at- INGR -dot- COM> Date:Fri, 7 Nov 1997 15:37:34 -0600
For those of you that wondered what some of us meant by "the edges
between programming and writing becoming blurred", I think I have a case
point. For the last month, I have been developing a document in dynamic
HTML. Anyone else working in it probably knows what I mean. It's an
excellent example of emerging technology where a Writer's technical
skills may be in more demand than their writing skills.
I am delivering an automation programming guide in HTML (not HTMLHelp)
for our object-oriented product. It will be delivered on CD but also
available (to subscribed customers) across the web. This allows
immediate updates, feed back, submission of example code and
workarounds, suggestions on areas that they would like to see covered,
and so forth.
At first I thought, "HTML, no thanks. I've had my share of tagged ASCII
(MASS11, I/Write, wordstar)." I also was wary of people wanting me to
put dancing dogs or flaming logos in the document. However, as the
project has developed, I feel like a new door is open. For example,
graphics change dynamically to show 'before' and 'after' effects of a
command. I've been able to synchronize the code descriptions (and/or
devices on GUI illustrations) with the code in separate frames.
Therefore, the customer can cut-and-past the example without capturing
explanations. Furthermore, the code does not have to be sequential
(impossible when subfunctions, event handling, and so forth is
involved).
The best part (and this is where the edges blur) is that through
VBScript, I can drive the application I'm documenting from the document.
Therefore, when I explain how to use the product's automation code to
perform a function, I now have a 'click here to execute this code'
button. When clicked, the code (actually a VBScript version of it)
drives the application. Anyway, the result is that the programming and
writing are so intertwined that I can't tell them apart.
I'd be interested in corresponding with anyone who is doing something
similar. I'd like to exchange some techniques, workarounds, and ideas.
