Multi-app Project Organization Question

[Guest]

We have combined several applications into a single "platform" web interface. The customer can buy separate licenses for the individual apps, and we don't want someone to see the help for an app they don't own. Since several of the apps interrelated, they share some help pages. I would like to have a single Robohelp project for the "platform" to reduce the Robohelp footprint and to allow me to share pages between app helps.

I was thinking just creating separate TOCs would keep things segregated. However, since the search function searches the entire project, you could find information about apps you don't own in a search query. The only solution I can think of is to have separate help projects for individual apps.

Does anyone have any suggestions on how they might approach the problem?

[Peter Grainge]

That looks like a job for merged help. For all customers you would install the parent project and then just the child projects relevant to what they have purchased.

There are various topics on my site describing what merged help offers and how to set it up.

[Amebr]

Peter's suggestion will work if you're installing the help locally. If you're not, you may be able to achieve what you want with merged help, but will require some developer help. The new output may give you additional problems as it's not something I've tried. We were doing it with webhelp.

I can't give you specifics, but I'll outline the general idea so hopefully your devs can come up with a solution, if web deployment is what you need.

At a previous job, we had a base product and multiple modules that people may have installed. In addition, they could have different combinations of versions of the base application and modules. This worked swimmingly when we used merged chms, but not so much when we moved to web-based help - the number of combinations of help we would have needed would have taxed google server farms. 😛

We maintained our merged project structure, but when it came time to publish each module we had a non-merged structure on the server.  (hope this looks right when I post...)

-parent

- product

  -v1

  -v1.1

  -v1.2

  -v2

- module a 

  -v1

  -v2

  -v2.1

- module b

  -v1

  -v2

  -v3

etc.

The client software passed a token saying what the base product and version, plus each module and version were.

On the server, magic happened. It made the system think the modules were in the required merge structure.  (The structure may be a bit different depending on the output you're building.)

One client might get help like this:

- parent

- mergedProjects

   - product v1.1

   - module a v2

Another might get this:

- parent

- mergedProjects

   - product v1

   - module a v2.1

   - module b v1

Hope that helps.

[Peter Grainge]

Peter's suggestion will work if you're installing the help locally. If you're not, you may be able to achieve what you want with merged help, but will require some developer help.

What difference does local or server make? In both cases the author creates the full help, parent and all children and then hands over to the developer(s). It's then up to the developer(s) to install the parent and only the required children.

The new output may give you additional problems as it's not something I've tried.

By "new output" do you mean responsive and frameless? If so in 2019 changes have been made so that they work the same way as webhelp in terms of installing only relevant children. Earlier versions only had responsive and the author had to generate each combination that was required.

[Amebr]

I meant client as in hosted at the client (either on their own web server, or installed on individual pcs). 

It's pretty common that companies don't want to bundle the files for individual client installation, and instead the software connects to an internet based web server for the help. In this case (multiple clients connect to a central web server) that is when you need fancy footwork by the developers. 

If only a couple of installation combinations are possible, then outputing the few different merges required would be manageable (with some sort of code in the application to point to the correct output), but for more than a couple of possibilities, it's hard to manage, and companies balk at the web hosting space for some reason. 🙂 That's where my scenario comes in.

[Peter Grainge]

Wherever the app is installed, the developers have to create a routine that installs the core product and just those modules the user is authorised to see. The routine I see is when they install the core product, they also install the parent and any child outputs common to all modules. When they open up other modules, they open up access to the relevant child outputs.

As that is the same wherever the app is installed (client PC, local server, web), I am not getting why you see local and server being different.