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.
In article <9306251247 -dot- AA21762 -at- ssdss3 -dot- asl -dot- dl -dot- nec -dot- com>
Chuck Banks <chuck -at- asl -dot- dl -dot- nec -dot- com> writes:
We are still studying SGML, looking for an elegant tool
that will give us SGML without all the internals. From what I've
read and seen of the SGML tools used by many of those who post to
the USENET newsgroup comp.text.sgml, I'm not impressed. To use
those tools I have to spend too much time on technical specifics.
The technology gets in the way of the writing. Most
SGMLers I've met and read from are all wound up in the complexity
of it all. Give me a WYSIWYG tool with a GUI interface and I'm
happy. I want the portability SGML perports to provide, but I'm
not willing to sacrifice ease of use to get it.
This strikes me as similar to a programmer who says "Why should I
develop my program on top of a platform-independent library? The
technology to create platform independence gets in the way of
programming. Give me a single-platform, mono-purpose text editor and
a non-standard programming language and I'm happy. Sure, portability
is important to the final product, but I'm not willing to make any
extra effort during the coding phase to generate portable code." No
one would fail to laugh at such a view from a programmer; what makes
it more reasonable for a tech writer? As much as the conservative
part of our emotions may be attached to paper, the 8-1/2 x 11 page is
not the only conceivable output medium, nor is printing the only, or
even necessarily the best, method of delivering information. As long
as you continue to write on a page-oriented WYSIWYG editor, whose idea
of a document is essentially a stream of graphic components, you
continue the tradition of single-purpose development of documents.
FrameViewer isn't all I've ever dreamed of in function and
ease of use, but it beats the daylights out of HyTime and its ilk.
Comparing a product to a standard doesn't really provide much
information. Every program has more functionality than any written
document, if you compare how they run on computers :-).
I don't want to know about the internals of my DTP package's
filing system or data storage format. I just want to get on with
the job of crafting the best documents I can within the constraints
There are those, and I count myself among them, who claim that one
cannot write the best documents within the given constraints without
understanding the tools one uses. In addition, there seems to be no
good reason to impose irrelevant and unnecessary constraints on
oneself by one's unwillingness to examine alternatives.