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.
<< Is not such modifying the style on-the-fly such a wide-spread issue that structured Framemaker is bound to be of limited use? >>
Our processes are very rigid and only valid SGML
coming from FM can be accepted into our delivery
system. If it fails, it will not be accepted, so we
are in a situation where we have a hard stop as to
how creative we can get. Sure, we can get around some
of the limitations, as long as we can still get it
validated, the system won't care, and I've been known
to do that at times.
Our limitation is that we did some extensive mods to
FM for in-house use. As FM evolved, our costs for
changing our tools got to the point where it wasn't
cost effective to continue with FM. The experts who
could make the changes retired or went away, so we
were left hanging. We started with 5.0 on Unix,
included Windows on 5.5, then went to 6.0 when we
decided to migrate to XML, so no new dev is being done
to our FM tool.
We saw the opposite that you did. The tool limited
our ability to express what we needed to show to our
customers. We had no ability to change fonts, and
limited ability to use font effects to emphasize
particular words, so we learned how to use the given
elements to express ourselves to the users.
We are moving into Epic Arbotext XML, and the
structure in this environment is even tighter as we
are limited by the markup we have available to us via
the tools we will be using. Some teams have been
fully trained and are using XML, while others are in
the middle of training, such as my group.
We have been given an edict by the corporate folks to
have a single style for all of our documentation, and
since they will control the output transforms, they
can finally do so once all groups are on board.
While we can provide structure to our docs via the
markup language avilable, we will not be able to
control the actual presentation, which takes some of
the burden off of us, but it still leaves open those
situations where we need to violate the standards.
Hopefully by getting authors involved with the tools
at the development stage, which they did, we will have
all of the markups available that we need, or will
find something that suits us.
A simple example is a command to be entered into the
computer. We will have a <command> tag that we must
use whenever we show a command in the text.
This will result in a fixed-width font that will be
different than the surrounding text. This will also
result in the system being able to create a list of
all commands used in the document as a summary.
Forcing writers to use a rigid structure for writing
also results in being able to systematically go
through the docs and extract other information as a
direct result of using a stuctured markup language.
There are other benefits beyond just the resulting
document from a structure being applied to docs.
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l