browser-based doc using FM, WWP, Dreamweaver - help!

Subject: browser-based doc using FM, WWP, Dreamweaver - help!
From: "Buck, Catherine" <Catherine -dot- Buck -at- brooks -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 14 Mar 2002 21:35:28 -0500

This question relates to using FMaker, WWP 7.0 and Dreamweaver 4 to create
browser-based doc. I am just getting started in this project. I have a copy
of DW in a Nutshell, plus the WWP manuals.

If you think this email is way out of line and I am trying to get other
people to do my work, let me know.

*General comments*

We have already produced the documentation once, for inclusion in the first
release of the product. At that point, I was concentrating on the content,
so I wrote it all in Word, which I much prefer over Frame for writing and
revising. (But I am now resigned to the fact that we will have to convert it
all to Frame, then produce the online using WW). Anyway, we produced the
first pass at the online documentation in a very manual, labor-intensive way
that we would like to avoid this time around.

We are writing documentation for a software development kit that is used by
an OEM to develop customer applications.

There is online browser doc. There are also 3 printed manuals, which
together provide a subset of what's in the online doc.

The online doc comes from 4 sources:
- Fmaker files
- API doc generated from the IDL files. Our doc provides an entry point to
that doc, then the navigation within the API is outside my control (I guess
it's part of the html generated usign the Orbacus utility).
- html files (laid out in tables) that are generated from xml files when the
SDK is started. Our doc provides the framework for displaying these files -
so we have control over this stuff.
- a Java application. Again, our doc provides an entry point to that
application, then the app takes over control.

The doc is included on the product install CD, it's not available over the

*Question 1*: Where should I stop using WWP and switch to DW. I am getting
the feeling that I should just use WWP to generate the html from FM, then
switch to DW for everything else. Does anyone have insights? PS. We already
have a web-page layout that we designed for the first release and would like
to keep. It has a several frames: a top menu, a side menu, a bar that shows
the current location, a main content area, and a secondary content area
(which always points to the html file where the OEM will be able to put
their content, see Note 1).

*Question 2*: The side menu is currently designed using DW layers. It
expands to show sub-menu items when the user clicks on a menu item. Is
layers the best way to do this, or should the DW Nav Bar feature work
better. Also, I want to make the items use rollovers, so I guess that I need
to set up each menu item as an image.

*Question 3* has to do with the directory structure of the files. The html
files used in the online doc must be in a specific, fairly complicated
directory structure involving up to six layers of subdirectories (although
if I had to I could probably reduce it to 3 or 4). See Note 1 below if you
want to know why.

Question 3: WWP generates html files that are all in the same folder. (I
don't think you can change this feature?) Does either WWP or DW have the
ability for me to move the files from these folders to the install directory
"with one mouse click". I don't want to have to drag the files (even in a
GUI - that's not a solution, just a way of disguising a tedious job). If I
have to write a script or batch file or whatever, that's fine.

There are two versions to the kit - dev time and runtime. The OEM uses the
dev time, while they must buy the runtime so their customer can install it
along with the OEM's application. Given these two versions of the kit,
documentation output (ie the html files) must be initially segregated into
two folders - dev and runtime, so that the installer can install only what's

We have an intention for the OEM to be able to include certain pages (pages
that appear in the runtime version) in the online documentation that they
prepare for the end-customer. Therefore, we have a further segregation of
folders into one folder that we are allowed to overwrite when new versions
of the SDK are installed, and one that we do not touch (that's where the
OEM's custom content is kept). We have mapped out a place in the web
structure for these files to go, so they must exist in the initial install,
even if they are empty.


Catherine Buck
catherine -dot- buck -at- brooks -dot- com

Check it out! Get some cool freebies when you buy RoboHelp! You'll receive
SnagIt screen capture software and a 10% discount voucher for RoboHelp
Consulting. This special offers expires March 29, 2002.

Have you looked at the new content on TECHWR-L lately?
See and check it out.

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 for more resources and info.

Previous by Author: FW: When Programmers Design Web Pages ...
Next by Author: RE: Next weeks Techwr-l poll?
Previous by Thread: Re: UK tech writer salaries
Next by Thread: Consultants:Dim or Delete the Non-Compete?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads