TechWhirl Sponsors

About TechWhirl

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.

Recap: Wanted: RoboHelp Project Pothole Alerts

A public thanks to all who responded to my query. I promised a recap, so
here it is.

Paul Hanson was first to respond. He seemed to agree that we were
following a prudent course and had not had very many problems with RH2000
except:

1) I can't compile to a network drive
2) I can't get a post-bat file to execute properly through RH.

Gary Clark sounded a more ominous note (snips throughout):

"The first and immediate suggestion is to document every problem you are
having and make sure that your team is doing the same. Keep a daily /
hourly log of the delays. This will come in handy when finger pointing
time comes along, and the TW team is on the other end of the finger.

"A suggestion would be to incorporate a method used during Y2K conversions
for systems under development. Here the Y2K programmers took the system
off line, as it was at the present stage of its development. They then
baselined it. From this, they modified the code as needed. (snip) When
the new system was completed, tested and ready to implement, they
integrated it into the baselined code."

Ginger Moskowitz intoned:

"I don't see how you can complete (he context-sensitive help) until the
screens are feature-frozen -- that is, the layout is final. Otherwise you
are going to be repeating your work constantly.
(snip)
"I've worked in the type of environment you're describing and often found
myself doubling the work; a screen that I had just documented would change
radically and I'd have to redo all my writing. Now I try to get the big
picture first, find out if it's really ready to document, and go from
there."

Laura M. King-Moore suggested:

" . . . have the developers (provide) general Map IDs for each applicable
field. (snip) As they add new fields they will have to regenerate the Map
ID file. Import the new file into RoboHelp (obviously using the same file
name). The new Map IDs will display as available IDs. However, make sure
that your developers know that the existing Map IDs can not change! (I
believe that this means that they must hard code them into the
application.)"

Mike Donoghue added:

". . . develop the Help topics for each field and then assign the Map IDs
afterwards. This means that the development team will need to work with you
to assign the corresponding numbers to the fields and create the call to
the proper Help topic/Map ID. This also means that you can move steadily
forward and don't have to keep using/reusing the What's This Help Composer
module."

L. Kendall Johns digressed a bit to discuss a pen and paper approach
(useful when screen design hasn't been completed). Then advised: