WebHelp Distribution - Best Practices

[Aurora Tech Writer]

Good Morning (or Afternoon as the case may be)!

This question is less about Robohelp itself, but more about Documentation in general.

Our CEO recently "came up with the idea" that we should begin hosting our application help on our website instead of distributing it with each release version of our software.  Doing so will allow us the flexibilty of making corrections and updating specific topics "on-the-fly" when necessary.

However, in discussions, we realized that we may need to parameterize the path to the hosted help based on the release version of the software that a client is using.  So, for example, a client using release 3.0 will need a path to "help3, whereas a client using release 3.1, will need a path to "help3_1".

Our reasoning is that since we add new features\programs with every release, we needed to keep separate help libraries so as to not confuse clients who have not upgraded to the latest release.  Does that make sense?

Does our basic premise make sense?  Do we need to maintain separate libraries, or is there another way of handling this?

For anyone that centrally hosts their Help System, how do you handle library management for multiple "versions"?

Our current help Merged WebHelp, which works great (thanks Peter G!) and if it matters I am using Robohelp 8 HTML.

Thanks for any insight that may be offered...

jim

[Peter Grainge]

You will need a version of the help for each version of the software, each having their own URL.

www.yoursite.com/help1

www.yoursite.com/help2

and so on.

If you were never going to change the Help 1 version, you could carry on updating your project as you would never need to regenerate the Help 1 again. Obviously you would keep a backup of it.

If you are going to make changes to Help 1 as well as Help 2, when you are about to start on Help 2 you take a copy of the project. One copy is just for Help 1 changes while the other is where you rewrite to suit Help 2.

You could maintain just one project and use conditional build tags to produce different outputs but I think that would get very messy and that the two project approach is easier.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Aurora Tech Writer]

Peter,

That is exactly what we were anticipating...each help with it's own URL.  We are going to add a switch on the backend of the software tied to the version number, so when they upgrade, they will automatically be pointed to the new URL.

That's exactly the confirmation I was looking for.

Jim

[Amebr]

One potential problem if you are using merged webhelp, which is a bit difficult to explain.

Our situation is we have a base product then separately installable modules.It's possible to have any of the following install scenarios:

ModA v1.0 with ModB v3.0, ModC v2.5 and ModDv1.0

ModA v1.0 with ModB v3.0

ModA v1.1 with ModB v2.2, ModC v2.1

etc.

The folder structure of the merge means either a folder for each possible combination of installed versions and modules and some tricky coding within the application, or some very special custom coding. We've been investigating the second option but have not worked out a solution yet so can't actually tell if this is even a workable option, unfortunately. (And the massive disk-space requirements and issues with managing the large number of combinations precludes the first option for us.)

Possibly we have a very unique product architecture, but thought I'd mention it.

Amber

[Peter Grainge]

Easy. A guy by the name of Phil Wells had a similar problem a few years back. See http://www.grainge.org/pages/authoring/merging_webhelp/multiple_outputs.htm for the solution.

Basically you share the job between many parents who will look after the children that they want.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge