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.
| Wow, I'm glad I asked the second question (about WWP). Yes, we do use
| FrameMaker, that's why we want to buy WWP. However, I come from the camp
| that believes it's best to write the online help first, then port
| the topics
| into manual format. And it sounds like people are saying that WWP expects
| you to create your single-sourcing text in manual format (Frame)
| first, then
| port it out to help when it's complete.
Actually, Beth, there's a paradigm shift here, and I think you've only made
it about half way so far! <g> If you go the WWP route, you most definitely
do not have to "write the manual first." You could actually follow the same
process you use now -- writing content for online first and adding elements
for the printed manual later. What's different is that you write ALL your
content in FrameMaker instead of first writing content in a HAT and then
porting the content to FrameMaker.
When you take the single-source approach, you are actually writing the
manual and the help in the same tool, so the question of which to write
"first" really goes away as a meaningful factor. Once your WWP template is
designed, you have both the help and the manual at the touch of button
whenever you want.
| This is disturbing because for years, I've found I can get my work done
| faster by creating the help first. I've found it's faster because
| help is so
| modular. First, I create all context-sensitive topics (screen
| help), then I
| use those topics to create the how-to's. After all that text is
| approved, I
| start bringing the topics into Frame and tweaking them into manual format.
| It's a very fast way to work. If I try to approximate that technique using
| WWP, I'll be adding a lot of time onto the project.
As I said, you can still "write the help first" if that's your preference.
And doing so won't add any time to your project. In fact, over the long run,
you'll be saving a great deal of time over the process you use now. With
your current process, after all, at the end of each project you have two
sets of source files: one in your help authoring tool and the other in
FrameMaker. Unavoidably, when it's time for the next release, you must
either update both sets of source files, or you must throw one of them away
and then recreate it using the updated content. Either approach creates a
great deal of additional effort each time the source documents change. With
a single-source approach, this redundant effort is totally unnecessary. So
far, every client we've worked with on a single-source project has SAVED
time, not added time to their project. (And the time and cost savings grow
exponentially on projects where the content needs to localized for
non-English markets.)
| I also prefer to create the help first because it gives the early
| customers
| answers to their questions about the product, right there, built into the
| interface. This, then, gives you a grace period, extra time to develop the
| best possible manual.
I agree that it's important to put help in the hands of early users.
Marvelous, too, if you can also provide documentation during the Alpha and
Beta test periods. If you're using FrameMaker and WWP to create your online
help, you can start to generate help as early in the project as you want.
With properly designed templates, it takes hardly any time at all to crank
out a WinHelp, HTML Help, JavaHelp, or WebWorks Help help system. And, if
you wish, you can also provide PDFs of the FrameMaker files.
