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.
Subject:Re: Multi-file Winhelp projects From:Suzanne Lee <suzanne -at- AUTOSIM -dot- COM> Date:Tue, 14 Jan 1997 16:29:40 -0700
> One of my writers is working on a Winhelp project for an application
> that may be customized for specific clients.
<snip>
> What they're considering is creating separate help files for each area
> of product functionality, so they can choose which help files match
> the product features the specific client needs. These separate help
> files will then be combined and compiled together to produce a single
> help file. Kind of an object-oriented approach, with an emphasis on
> information re-usability.
>We're using Doc-to-Help 1.6 as our authoring tool, by the way.
we are doing a similar thing. We use Forehelp, so I don't know if this
will work in Doc-to-Help. Here's the basic approach:
============
1. keep each product function/module/manageable chunk in it's own help project.
2. Within each project, write topics and assign them to various RTF files
(like topics common to both products, topics specific to customer A, those
same topics written for the rest of the customers using the standard
product).
3. Keep all of this info in a database so you don't get confused (no, we
_never_ get confused!).
4. When compiling, compile the correct RTF files from all the projects to
get the desired help file.
5. Add intro, contents, and usually redo/add some links (every time you
redo this!)
EXAMPLE
project A: reference info
RTF1: common ref topics
RTF2: customer A ref topics
RTF3: ref topics unique to general users (don't apply to customer A)
project B: how-to tasks
RTF4: common tasks
RTF5: customer A tasks
RTF6: tasks unique to general users
When compiling a general release, compile RTFs 1, 3, 4, and 6 together into
one help file.
When compiling a version for customer A, compile RTFs 1, 2, 4, and 5.
Forehelp lets you assign each topic an RTF within the help project. You
can compile all topics into 1 RTF or to compile specific RTF files.
It's a real pain. So far it's working, but it's a tracking nightmare. We
compare a database report of what topics should be in a given help file
against a Forehelp report of what topics ARE in the help file after a
compile to make sure nothing gets lost in the juggling.
It's also VERY hard to write topics not knowing all the other topics that
will be in a given project (they change based on how you compile).
WARNING: this approach usually means you need to reconnect some links
EVERY time you recompile a set of RTFs. This is another thing you need to
watch for/track.
================
Hope this helps. Good luck and if anyone come up with any helpful
suggstions from other private posts, please pass them along to me.
Suzanne
***************************************************************************
from Suzanne Lee - suzanne -at- autosim -dot- com
AutoSimulations, Inc. - Bountiful, UT 84010
(801)298-1398 ext 333 / (801)298-8186 fax
Visit ASI on the World Wide Web at http://www.autosim.com/
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
