Shared content and context sensitive help

[bobmoon]

The company is breaking up a suite of products that has four main applications and many shared functions and modules. Right now we have one honking big help system for all the apps, but we need to create separate web help outputs for the main apps (General Ledger help, Accounts Payable help, etc.).

I know that I can build separate help systems for each application, each with a separate TOC and each pulling in shared content. That will work when the user comes into the help from the top. But what about context sensitive help links from the shared windows? Development needs to code the help links so that they work for each app. The help button on SharedWindowA can't be coded to open gl_csh.htm if it will also be used in the AP help.

Since the main issue seems to be the file name of the main output file, my plan is to set up all the help systems to use a generic name like financials_csh.htm. Development can code the context sensitive help links on both shared and non-shared windows to open this file name. The actual help system that is opened will depend on which application is installed.

Has anyone handled this in a better way? Is there something I'm missing?

Thanks!
Bob

[GregStenhouse]

Sounds like a sensible approach. Another possible way is to use the Javascript method of linking to your help. The developers only need to specify the ID, rather than the full URL. This may give you more options, for example, if the user ends up installing 2 or more applications at the same time.

See the help topic "Connecting WebHelp - Developers" for more.

Cheers
Greg

[Madcap Guru]

Bob,

You are on the right track, I would leavet the start page the same name, and just have your application make the call to the help file, that way your programmer doesn't have to do any different work for each of the help files.