Re: Programming Languages for Technical Communication

[Mark Baker <mbaker -at- OMNIMARK -dot- COM>]

Kris Olberg wrote:

>Many people consider me a tool wizard. I've used a text editor many times
>throughout my career to code software in various languages, ISIL,
>BookMaster, IPF (OS/2's online help tool), RTF, WinHelp, SGML, and HTML .
>But frankly, I don't get my kicks out of hand coding. It's an inefficient
>use of my time, so I'm always looking for a good WYSIWYG.

These are markup languages, not programming languages. Marking up text in
HTML hardly counts as "coding software". With the exception of SGML (and
possibly ISIL, which I have not heard of), these are all specific markup
languages for specific media formats. SGML is a meta-language used to define
markup languages. Whether you can create a WYSIWYG tool for a markup
language is entirely dependent on the type of markup you have. If all the
markup has a direct correspondence to formatting, you can use WYSIWYG. If
any of the markup has any other meaning, you can't. You may be able to
create a visual interface to the markup, but it won't be WYSIWYG.

But the point of my original post had nothing to do with the quality of
tools for doing programming. It had to do with the need for writers to
become programmers in order to create information products that have
behavior. You can, of course, create information products with behavior by
creating markup for one of the existing engines, such as WinHelp, but the
behavior they offer out of the box is very limited. They deliver only the
simplest and most generalized kind of behavior. To really add value to
information products you need to add very specific, focused behavior that
matches your business model and your customers individual needs. You can't
do that with a off-the-shelf product (though you may do it through an custom
extension that integrates with the display engine, if the product provides a
suitable API). You need to design and implement your own data model and
display logic, and that requires programming skills.

>As you suggest, doing this requires two sets of skills: (1) writing
>nonlinear material and (2) pouring that material into presentation medium.
>I argue that the writer should concentrate on the first skill because tools
>will evolve that take care of the second skill.

It isn't just about pouring content into a presentation media. It is about
defining a unique presentation logic that suits your customers needs. For an
interactive information product, behavior is specific both to the content
and the needs of the user. The presentation media is just the place where
the content and behavior get expressed, it does not provide the behavior.
Look at any interactive site on the web. The presentation media is HTML, but
the interactive behavior that makes the site useful and compelling has
nothing to do with HTML. It is provided by a fully fledged custom
application running on the web server (or, in rare cases, a Java applet
running on the client).

Writing does not require less skill as we get better writing tools, and
programming does not require less skill as we get better programming tools.
In order to create the high value interactive information products customers
are now  demanding, you need both these skills, and tool development won't
change that.
---
Mark Baker
Manager, Corporate Communications
OmniMark Technologies Corporation
1400 Blair Place
Gloucester, Ontario
Canada, K1J 9B8
Phone: 613-745-4242
Fax: 613-745-5560
Email mbaker -at- omnimark -dot- com