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.
Where FrameMaker is *required* by people is in the industrial strength
area. Examples that I have experienced in 2001:
Cell library datasheets (EDA fru-fra) comprised of 500+ cells. The
client sends me 30+ Meg of MIF generated by their simulation processes.
I update/edit the introductory discussions, import their data, generate
TOC and other lists, then generate PDF. The result is in the area of
1000 pages for each library, with individual files up to 200 pp
comprised almost entirely of tables. Using Maker, I can turn a job
around in about 4 hours. I hate to think how that would work in a
product that was not "industrial strength". The templates were designed
by a graphic designer and look really nice, so while it's industrial
strength, the project also incorporates aesthetics.
The British Parliament writes their bills in SGML - they use Maker+SGML.
Maker+SGML is interesting to them because the formatting (page/type
design) is reasonable, and so is the SGML editing environment. I
developed a plugin that automates some of their processes. Again, we're
talking about many pages, plus SGML, which is app-independent.
A manufacturing company writes their docs in SGML, and stores chunks of
it in a doc database. They author in Maker+SGML - I produced a plugin
that attunes xref management to the doc database. Then they assemble
the chunks into a publication in Maker+SGML. SGML and many pages, yet
again.
Aviation maintenence manuals - I developed a plugin that generates a
list of effective pages and a print job for just the loose-leaf pages
that have been changed (the "effective" pages). Not SGML, but many
pages, yet again.
A common theme is some sort of automation. In fact, for this year of
(?) recession (?) I have seen little writing work and much programming
work. Automation is very interesting these days. So FrameMaker is also
interesting because it offers two basic routes for automation - you can
generate MIF via some process, and you can automate processes within the
product via an API. Of course, this is not just a FrameMaker thing -
Word has VBasic and RTF, for example. But it is a recurring theme in
the FrameMaker arena. So as you use FrameMaker, you should get used to
thinking about your *process* and keep an eye open for two things:
How to design/author documents in ways that are open to automation.
What I mean is, how to keep the document data "normalized", and how to
identify data by type, not just by appearance. The more you do that,
the easier it will be to automate any given authoring process. This is
considered "good citizenship" in the FrameMaker world. Specific
example: Design your char and pgf formats, and don't use format overrides.
What processes do you repeat often, and can they be automated? If you
constantly repeat a specific set of steps, then you're asking for errors
and wasting time. Automation may be called for. Just keep that in the
back of your mind. (Is this a shameless advertising ploy? Yes and no -
Whether or not I get the contract, I still think it's a good idea. The
more we all think in terms of automation, the sooner we will all develop
environments that are more friendly to SGML/XML - see below.)
I would look forward to more action in the SGML/XML area in the near
future. B2B (the recent failure notwithstanding) is waiting for net
bandwidth - when that comes there will be an XML explosion. XML will
divide into (at least) two general categories - short snippets that get
zipped around the net, and large publications that get frozen in a
specific state (read "paginated") to represent the known information at
a given point in time. Microsoft + .NET + Word will try (and probably
succeed) to dominate the former. My guess is that until the current
concept of "document" changes radically (which it must as a result of
XML - 4 years from now?), FrameMaker will be included in many SGML/XML
authoring systems, and will be used to build many of these large, frozen
publications.
So I suggest you pony up for Maker+SGML, and get comfortable with that.
If you can make an EDD that automatically formats your text depending
on where you put it in the document's structure, you are well on your
way to understanding SGML/XML.
cud
--
Chris Despopoulos, maker of CudSpan Freeware...
Plugins to Enhance FrameMaker & FrameMaker+SGML http://www.telecable.es/personales/cud/
cud -at- telecable -dot- es
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Be a published author! iUniverse gives you: a high-quality paperback, a
custom cover design, and distribution to 25,000 retailers. And it's
affordable. Join our almost 10,000 published authors today. http://www.iuniverse.com/media/techwr
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.
