Anyone Have 3rd Parties Adding Custom Topics to Built Help?

[amatsumoto]

This topic is coming up more frequently in our organization and we will need to find a fairly simple solution. We are using WebHelp.

We have developers within our company who create plug-ins for our products that are classified. No one in our group has the clearance needed to document these programs, plus they cannot be built with the main help. The developers would like to be able to write help that can be installed as a "plug-in" to the main help that can be installed and uninstalled with the classified program. Ideally they want that help to show up in the TOC, Index, and search. I know how we can do this plug-in method if we were able to regenerate the main help with the plug-in help, but this will not be an option. Is anyone else working with 3rd parties to who create add-on help? If so, how are you doing it? Is it even possible to do?

Thanks!

[LTinker68]

Why not just install Flare in the classified environment and let them author the topics there? They can merge your project with their project at build time. You'd just have to periodically give them your updated project files. The Flare license agreement will allow you to install your copy of Flare in that classified environment, so long as they're not using it at the same time you're using it, but since they most likely have to get approval to install Flare, you might want to just buy another copy anyway.

[amatsumoto]

That could work. It does seem like we'll need to get them on Flare. I forgot that you can merge with the output files and do not need to have the master project files (which is probably easiest).

I'll give that a try. Thanks!

[amatsumoto]

So now that I have tried this out, I can see that it works so long as we, the keepers of the master project, create a pointer to the child project in a TOC and generate the master project ourselves. Unfortunately, this is not what our workflow needs to be.

We are still the keeper of the master project, but what needs to happen is for the developers to create their classified topics in their own project and THEY must be the ones who generate the final help using the output files from the master project. We do not want to give them the master project files, as it will only complicate things more.

If I try it the way they need to do it, by pointing to the original help output (*.mcwebhelp) as an external resource, the directory structure I end up with for the new output is quite different from the original help. Here's the original help directory structure:

Code: Select all

\OriginalHelp
    \Content
     \Data
     \Skin

But the new output including the plug-in looks like the following. What I did is create a master help project that only links to the output of both the original help and the plug-in help, so the first level of the Content directory is empty, as it has no topic files:

Code: Select all

\OriginalHelp
     \Content
     \Data
     \Skin
     \Subsystems
          \OriginalHelp
               \Content
               \Data
               \Skin
          \PlugInHelp
               \Content
               \Data
               \Skin

I also tried generating help from the child project for the plug-in topics, so the TOC had a reference to the external original help output, followed by the TOC entries of the topics from the child project. The output directory structure for that was even worse, where the original help was located under \Subsystems and the child project files were at the higher level in the output.

Is there any way I can retain the original directory structure of the original output and have only the child project output go under \Subsystems?

Thanks

[NorthEast]

If you can use WebHelp Plus (i.e. put your WebHelp on a server running IIS), that would allow you to use runtime merging of WebHelp outputs, so you could both publish your help independently and still have them combined.

See: http://webhelp.madcapsoftware.com/flare ... 20Plus.htm

[i-tietz]

???
Doesnt' IIS mean it's gonna be a real ONLINE help - i.e. available via internet?
The topics are classified. They are so secret that not even employees of the same company are allowed to see them.
How realistic is it to put those topics, that help, on a webserver? And that would alos mean, that the software users need internet access on their computers ... wouldn't that be a pretty schizophrenic thing to do?

[RamonS]

???
Doesnt' IIS mean it's gonna be a real ONLINE help - i.e. available via internet?
The topics are classified. They are so secret that not even employees of the same company are allowed to see them.
How realistic is it to put those topics, that help, on a webserver? And that would alos mean, that the software users need internet access on their computers ... wouldn't that be a pretty schizophrenic thing to do?

No, you can run IIS or any other web server as an INTRAnet web server. Public access is not implied by using IIS. I have IIS running on my box here and I am convinced you cannot access it.

The other concerns are valid. Not only authoring is an issue, but also applying the proper security once it is deployed, which requires at least two sites for help of which one needs to have a login or other security applied.
I think having the doc team do the general purpose help and providing the project files to the dev team with the clearance is the only way to go. It will then their task to find a home for the help and implement the necessary security.

[i-tietz]

No, you can run IIS or any other web server as an INTRAnet web server. Public access is not implied by using IIS. I have IIS running on my box here and I am convinced you cannot access it.

So it's the customers who would have to have an IIS - maybe even for the help only, because the actual software won't run on it or at least isn't officially released to run on that server ... that works with individual software but not with standard software - at least not as a short term solution. Short term would mean real "web"help ...
But you're right - if amatsumoto's company produces individual software the IIS would be an option ...

[RamonS]

amatsumoto didn't say it was for external customers, but even if, that doesn't change much. Without the need then to do runtime merges plain WebHelp works as well and that can be run off any web server app or even without server when accessed locally (each with their own set of quirks).

[amatsumoto]

So, I have a few questions about WebHelp Plus. We've been using Flare for several years and we did not go with WebHelp Plus output for some reason or other. I'm thinking it was because it didn't support context-sensitive help. Or maybe it was too Windows-centric? I can't remember, but the v7 list of support doesn't seem to indicate either of those as a deficiency anymore.

Being able to add the plug-in help to the standard help and have it dynamically update the TOC/Index/Search is EXACTLY what we need, but it sounds like this help can only be loaded on a single machine? Our standard help is loaded locally on a user's machine along with the software...we can't still distribute it that way? In the case of customers who are using the classified plug-in, I know for certain they do not have inTERnet access, but I am not sure what they might have for an inTRAnet. It also sounds like we have to install additional software on the help machine (IIS, anything else?), which could be an issue in a secure environment. Plus, we would have to make this a standard method of delivering help to *any* of our customers, even the non-classified users. The sort of intranet/internet setups they have will vary. Maybe distributing WebHelp Plus output isn't as complex as I'm making it out to be, but it sounds like we'll have to stick with plain old WebHelp output, give our developers access to the standard help project, have them create their own Flare project for the classified topics, then generate their own fill version of help.

[RamonS]

The users will definitely have to install IIS, but that can run locally. Also, some configuration is likely needed to get WebHelp Plus to work. It is doable.

One question though, will users who have one of these plugins the clearance to know about the other plugins? If yes, it may be easier to create a non-classified help and a classified help for all the plugins, then distribute the classified version with the plugins. If that is an option you save the extra steps involved with WebHelp Plus and can use plain WebHelp.

[amatsumoto]

That's a good question and I'll have to find out. I have a feeling some users will have the clearance for access to all, but some will not.

Thanks for all the feedback!