Splitting HTML topic pages, images and HTML utility pages apart

[Akala_Honu]

Hello everyone. I’m very new to RoboHelp in general and X5 specifically. I’ve done well so far in the basics of creating a project and generating WebHelp layout. I’ve even been able to resolve Firefox browser issues thanks to www.grainge.org!

Now I’m stuck. I hope I can be clear enough to explain. My managers have asked me to figure out:
1) how robohelp actually creates the output files
2) where source and output files are stored
3) what command line tools convert source to output

These are actual phrases used. The end result is for me to load only source files into our config mgmt system so that the development team can download those and programmatically create the derived files. Based on my initial research, it appears this can’t be done using WebHelp. And since we pride ourselves on our software product being cross-platform and cross-browser, I think we need to stick with WebHelp.

My company had RoboHelp specialists back in 2002 but they’re gone. I’ve been with the company for a little over a month now. I’ve picked through the existing online help folders/files created using RoboEditor. All HTML topic files, images, and HTML TOC, index and search files are in separate directories. I see quite a bit if JavaScript throughout some of the HTML pages. I’m just not sure if the old RoboEditor did all that or if the previous tech writers programmatically “spilt” the project files using JS.

Any help you could provide would be most appreciated!

[Akala_Honu]

Some more info re: the versions used to create our old help system:
RoboHelp 3 and 4

[MergeThis]

Q: 1) how robohelp actually creates the output files
A: Magic :-)

Q: 2) where source and output files are stored
A: Source files are stored in the project folder you have selected. You can generate and publish output files wherever you choose (the default is under !SSL, but most folks don't use that). The source project folder contains many files (htm, js, apj, ali, css, etc.) which it uses for its multiple purposes. Few of those files, except for the htm files, are carried over to the output; however, RH creates three "wh" folders to contain all the TOC, Index, and Search data.

Q: 3) what command line tools convert source to output
A: None


We went through this same developer-centric thinking here, and after months of haggling, we finally came to an agreement (probably only because the developers didn't want to do the work necessary to "build" their own output, such as customizing some third-party macro utility).

The problem seems to be that engineers insist that the help MUST be built whenever the application is built. The flaw in this thinking is that the help is not an integral module of the application; it is a peripheral item. That is, if you generated and published your Webhelp last Thursday and they want to build the app again today, how will their app be any different with a four-day-old help version than with a one-hour-old version? It will not, period.


Anyway, good luck fighting the fight,
Leon

[themint100]

HI Akala,

As Leon pointed out, the developers are probably trying to ensure that they have the latest version of help when they do a build.

When you're working with webhelp, you have three folders: your source, your generated output, and your published output. Your \source is obvious; the \generated output is just that, the output generated when you interactively tell RH to generate your help system, and the \published is where you'll copy the files for distribution (e.g. a server...see the "Republish All" options on the generate output dialog for options there). You can generate without publishing...e.g., to test out the help without 'releasing' it.

I have to disagree with Leon (sorry!) on one philosophical point: you have to think of yourself as any other developer in this system, not as peripheral. Suppose you generate help on Friday. Your devo team adds some features on Mon & Tues. They can do a build and include the contents of Friday's \publish directory. It'll include that version, but won't show any help for the new features (because you won't have written it yet). So that's what your developers need to understand. As long as you can guarantee them a directory where they can always grab the latest help, they'll probably be happy.

Ensuring that the latest version covers new features will require some human communication (!)...but that's true for straight devo, too. You can do a successful build with an out of date version of a library and think everything is OK!

Some options:

1) During development, make a new local /publish directory that includes a build date in the name. That way developers know when the output was generated. Something like "/publish-05-20-2006" or the like.

2) If they're insistent, I suppose you could do as Leon mentioned, research external macro programs that had a command line component to start robohelp and generate the files...but that seems silly, since you could be working on the source files while they're trying to build. Which in turn means you'd have to start using version control. And if you'd cut a version, you'd have also generated most recent output!

I think if you can simply guarantee them where the latest output files will be, they'll be happy.

-Greg