Your product "structure" reminds me of my client's product.
Four years ago it was similar to your description. Today it has
evolved and the "custom" applications are derived from a core
application but EVERYTHING is kept separate, down to individual
subdirectories for each topic within the app. Even my Help mirrors
this application subdirectory and file naming convention. This
makes it much easier to keep track of the entire project for a
given customer (over 18,500 files for my client).
If possible, manage the Help project in chunks. Base the Help
sub domain (subdirectory) structure right from the start. The only
place this gets referenced is in the Site Help links and this is
best handled as merged projects, as suggested by Peter Grainge.
The "core" Help is what you will create and provide to the
project developers. Be sure to provide a detailed list of names,
titles, related functions, etc. and instructions on how to import
the core Help into a new Help project customize for the client.
With this approach, you will need separate project directories on
your server(s) as each custom generated Help project will have
common file names but different content. The plus side to this is
easier upkeep of the Site Help when a sub domain project is
updated.
So, how is your architect approaching the application? Do you
use a container (common) window with additional frames, fields, or
combination thereof, that are populated based on a previous
selection? Or is there a unique window based on a previous
selection? How is the Help requested in the GUI - a Help button /
icon, hot key - does the call trigger a JavaScript written for your
application toolbar? Are you using the simple RoboHelp style
context sensitive call or is it customized to read the displayed
content window file name? Could use a lot more info to assist in
setting up an approach.
I think you have a lot of planning ahead and more than one
head-butting session with the developers. Good luck!
Regards,
GEWB
(been there, done that...got the bruises to prove it)