Re: Programming Languages for Technical Communication

[Kris Olberg <kjolberg -at- IX -dot- NETCOM -dot- COM>]

-----Original Message-----
From: Mark Baker <mbaker -at- OMNIMARK -dot- COM>
Subject: Programming Languages for Technical Communication


>It is surely clear by now that the days of the static information product
>are numbered. While there will always be some static documents, interactive
>individualized information products offer productivity gains so compelling
>that customer will soon demand nothing less. It will no longer be enough to
>deliver static information, we will have to deliver information with
>behavior. And behavior means programming.


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:

- Word and WordPerfect. While Word became an excellent WYSIWYG word
processing tool that virtually eliminated the need to interpret "codes" or
"tags," WordPerfect refused to let go of them. We all know who won that
battle. (This doesn't mean WordPerfect is dead; they've learned a huge
lesson and may be able to redeem themselves.)

- HTML editors. As this medium evolves, the need to hand code or even
"tweak" HTML lessens. Witness the popularity of MS FrontPage and NetObjects
Fusion, both of which--and especially the latter--don't encourage
hand-coding or tweaking of the HTML they generate.

>Even the static documents we do produce will increasingly be the product of
>well integrated corporate information sets, not the individual labors of a
>writer and a word processor. Creating a new document will be a matter of
>selecting, customizing,  and ordering existing material from well managed
>sources. This again mean programming.


Yes. But tools evolve, and products that reduce the complexity of the task
will win the war.


>Writers who cannot program content management and information delivery
>applications will soon find themselves either out of a job or playing a
>reduced role.


Writers who cannot write have a more serious deficit, don't they?

>So what languages should you learn to keep up with the trend toward
>interactivity and individualization? Java, Java Script, XML, and Cascading
>Style Sheets have some uses on the client side of the Web, but the real
...[snip]

>server side programming language. The most common are C, C++, and PERL. The
>most powerful and easiest to learn and use is OmniMark, which was designed
>from the ground up for text manipulation and content management. (The
>learning edition is available for free download at http://www.omnimark.com)


Ah ... a biased opinion have you? Well, good luck with your product. You'd
should hope that OmniMark's strategists took some history classes and
learned something. (Who said, "The only thing we learned from history is
that we don't learn anything from history"?)


>Some will no doubt argue that creating these applications is a job for
>programmers, not writers, and to a certain extent it is. But this overlooks
>just how much we as writers have always had to know about the graphic
>design, layout, and printing trades in order to keep control over our work
>and get the results we want. Interactive and individualized information
[snip]

No, graphic design, layout, and printing are the reasons why technical
writers have not advanced to the same level as business analysts or
programmers. We've spent way too much time sweating those issues and not
nearly enough time understanding the needs of our readers.

When we collectively realize that, we'll be on our way to identifying the
real skills that define the "technical writer."

>Mark Baker
>Manager, Corporate Communications
>OmniMark Technologies Corporation


Regards...Kris
------------------------------
kolberg -at- actamed -dot- com
kris -at- olberg -dot- com