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.
You can also set up your WWP template to map Body1 to a specific tag
(Body?), if your source is messed up. After that, WWP will correctly handle
Body1 tags until the end of time.
However, perhaps the tough part of using WWP, for some, is that it requires
you use FrameMaker by the book and with structure in mind. If you use
FrameMaker in the MS-Word way, WWP is not going to work as easily as it can.
Furthermore, I agree there might be legacy docs that you cannot convert to
acceptable help. Probably, this is because the legacy docs use a structure
and styleset with which you are unhappy. Here's what I did: I stated I would
only make help files from docs I create or update. Thus, legacy docs that
pre-date me must be scheduled for an update, and I must perform the update
(which also includes moving some from FrameMaker 5.0 to 5.5.6) and use my
newer template before I make any online help. In some instances online help
exists for these legacy docs. Hey, if the subject matter doesn't change, why
revisit it? Certainly, my company doesn't put a priority on booking my time
for legacy docs for products that are stagnant.
To me, this is not a WWP, FrameMaker, or other tool issue. It is an issue of
how the documents are structured. And, yes, single-sourcing works better if
the source document is planned as a single-source book. For some reason, I
thought that . . . er . . . obvious. Thus, as you update legacy docs you can
edit them to make them "better" meet the single-source and WWP needs. As you
create new books, you can write them for single-sourcing from the outset.
Some docs, obviously, will evolve and get better with more, and planned
future updates. Finally, you need to plan time to get this done. These
changes will cost, money, resources . . .. And, yes, you can pick between 0-
and 100- percent desired quality. So, as I have read here often, you can
have "what you want," you can have it "on time," or you can have it "on
budget;" pick any TWO.
It's a planning thing, not a tool one.
sean -at- quodata -dot- com
From: Bill Burns [SMTP:BillDB -at- ILE -dot- com]
> Webworks maps Body1 to "default" by default. What you say is perfectly
> correct, but if you have the manuals I've been dealing with, what
> Webworks produces is Garbage Out that *must* be edited.
> effort to deal with whether Body1, etc. tags are in a doc, whether the
> split of HTML files is at the correct spot, etc. is another edit cycle,
If the source is a mess to start, you will have garbage in the output
(GIGO). As Eric said, WebWorks converts reliably, based on how you set up
scrap of code can be changed so the output is exactly
what you want, and you can add and customize styles to match your existing
Frame source, if you need. It sounds as if you're faulting the tool for the
shortcomings of the source.