Using RoboHelp for Multiple/Merged Projects

[sharon27lily]

I work at a medical software company where users of the software are given specific roles, and are not allowed access to complete help systems, based on FDA regulations. In an upcoming web application we are developing, roughly 100,000 users at sites worldwide will use the software, but each individual will have a specified role, and a set of allowable "portlets" for access.

The Online Help system, along with the application, will require an ability to identify the role of the user, their access privileges to the software, and provide the appropriate help files. For example, an investigator who has rights to approve data will need to see three portlet help topics, including the approval workflow and steps; another investigator without approval privileges will see only two portlets, etc. Some of these roles will have access that overlap; some will not. We will probably have about 14 roles for the first release, but this may increase to 25 or 30 over the next year.

I am using RoboHelp 6 at this time, and am looking at the use of Merged WebHelp (on www.grainge.org), conditional topics, and RoboHelp Server. Can anyone provide some insight as to the benefits/risks of each of these? Also, I would like to be able to create separate indices for each subproject.

Any assistance in figuring out the most efficient approach would be greatly appreciated.

Sharon

[Peter Grainge]

You need to look at RH8 and its associated version of RoboServer. You can find out more about these new releases here. You would need to install the trial version to run the Try It exercises.

Reviewers Guide
http://tinyurl.com/cvaxzh

Try It Exercises
http://tinyurl.com/c9a6ul

[Peter Grainge]

Doh! I forgot to explain why you need to look at them. RoboServer will enable user group access. It is described in the Reviewer's Guide.

[MergeThis]

"I am using RoboHelp 6 at this time, and am looking at the use of Merged WebHelp (on www.grainge.org), conditional topics, and RoboHelp Server. Can anyone provide some insight as to the benefits/risks of each of these? Also, I would like to be able to create separate indices for each subproject."

Merged WebHelp
We run a 7-writer, 42-project merged WebHelp environment (with Peter's recommended structure). The output gets published, project by project, and requires no major "build" of the entire help.

conditional topics
Based on your user-privilege scenario, I'd eschew conditionalizing topics in favor of organizing your merged help into separate projects for each of the user responsibilities. Then, your developers would set up access privileges by user/by folder, allowing for relatively painless growth (conditionalizing your anticipated "25 or 30" user roles would definitely drive you into a different career, perhaps sorting items in a recycling center?). You might also ensure that each project is assigned to an individual writer, thereby negating the need for source control. We simply use Karen's Replicator, a free tool, to sync our projects daily from our local machines to a dedicated server for storage and backup.

RoboHelp Server
The RH Server is used to house WebHelp Pro output, which allows for more advanced searching and for topic "hit counts." However, I believe that those features are only available in those instances where the WebHelp Pro output is actually being accessed from an RH Server (if you were hosting the help on your company's web site, or if your users bought an RH Server license for their site).

RH 8
If you're going to follow Peter's recommendation to check out RH 8, you might also take a look at the Adobe Packager for AIR, which wraps generated WebHelp (even merged) into a single executable file (think .CHM file) with its own skin. It provides cool stuff like topic-specific "mini-TOCs" and Favorites, user-generated comments that they can add and share, seamless updating on demand, etc. In addition, its standalone construct takes your WebHelp entirely out of the ongoing browser wars, with their add-on and plug-in mania. The only issue that's come up in my testing so far, is that my JavaScript mouseover tooltips (using Walter Zorn's free utility) are being ignored. All others, which are based on simple JavaScript rollover image arrays, are OK. Further testing will be needed to determine how this construct will affect our URL context-sensitive calls from our app (also well defined on Peter's web site).


Good luck,
Leon

[sharon27lily]

Thank you both for this information. I will investigate.

Regards,

Sharon