Re: Programming Languages for Technical Communication

["Wing, Michael J" <mjwing -at- INGR -dot- COM>]

Mark;

I agree with much of what you say.  I also am a prognosticator that the
edges between writing duties and programming skills are blurring.  The
attitude of, "I'm a Writer and I only write" has always bothered me.
Developing skills beyond writing does not erase a person's writing
skills any more than learning to skate removes the ability to ride a
bike.  But attaining non-writing skills does position them well for the
future.  And, I agree that the future is promising for a writer who can
write but also can manage information, program interactive documents,
automate sections of their work, and so forth.

A few years ago I did not see how programming skills were merging with
writing duties.  It was nice to understand programming concepts but they
did not directly apply to my work.  However, the past couple of years
have expanded my duties and skills in both directions.  For example. I
have had to merge the skills to do the following:

-- I am working in dynamic HTML.  Almost half of each document is
VBScript and hidden from the user.  It automates the document itself.
For example, I have images that the user can click that show before and
after effects.  Clicking the image changes the image.  I have
interactive fields in which the user can enter or select data , and, as
a result, drive and customize the application.  Some text/images/tables
are hidden and exposed dynamically depending on whether the user holds
the mouse over a certain area, makes a selection, scrolls, and so forth.
The table of contents also synchronizes with the current position in the
open document (applicable TOC entry highlights as mouse moves to a new
section in the document)

--  I have also imbedded windows from our applications directly into the
DHTML document.  As the user receives instructions on how to customize
the application, the imbedded window opens and displays the results.  To
do this, I've had to pick up on a lot of programming.

-- I have written VB scripts that allow Developers to create help
topics.  Because there are thousands of automation
objects/methods/properties to document and only one Technical Writer
documenting these objects, I created a program that allows the Developer
to fill out a GUI.  The program then takes the selections and
information from the GUI and creates a topic.  It also performs most of
the linking.  The developer then fills out the formatted topic.

-- I use VB programs to configure help files based on the product and
variation of that product.  The topics are selected from a topic library
(which allows single souring of topics) based on the configuration of
the product.

-- I have completely automated the assigning and testing of help
context-sensitivity, automated the preparation of source files for
translation, and automated conversion between file types.

Mike

Michael Wing (mailto:mjwing -at- ingr -dot- com)
Principal Technical Writer
Intergraph Corporation; Huntsville, Alabama
http://www.ingr.com/iss/products/mapping/
(205) 730-7250


> Kris Olberg writes:
>
> >My take is that we're at the high point (or low point, depending on
> your
> >perspective) of a cycle in which good tools for information delivery
> are
> >requiring writers who are also semi-literate to literate programmers.
> >Looking to the past as an indicator of what the future holds, tools
> that
> >require medium to heavy programming skills will lose. Examples:
>
> This misses the point. I am not arguing that you need programming
> skills to
> create tools to create information products. I am arguing that
> information
> products themselves are now aquiring behavior; the ability to respond
> to
> user input and stored information about the user and to customize
> information for that user. This means that information products are
> becoming
> programs (rather than just data) and that writing and programming are
> equally necessary skills in creating them. Unlike the trend to WYSIWYG
> in
> data manipulation tools, atempts to create visual programming tools
> have met
> with no significant success, except for UI building. Programming logic
> is
> still written in text editors and there is no reason to suppose it
> will not
> contine to be. Even if visual programming tools were to take over,
> however,
> the skills of programming -- designing appropriate application logic
> and
> data structures -- would still be required.
>
> >>Creating a new document will be a matter of
> >>selecting, customizing,  and ordering existing material from well
> managed
> >>sources. This again mean programming.
>
>
        <snip>
> ---
> Mark Baker
> Manager, Corporate Communications
>