Users require multiple outputs

[jenco]

I work on a system that has ~15 core applications and at least that many add-on products, all of which are licensed separately. Many, many possible combinations. Currently we provide PDF doc (~150 different guides!) and clients download the PDFs only for the applications/add-ons they have licensed.

But now we are moving to providing online help. Following the model we have now, it’s likely that clients will download 20 or more different help outputs and use them all somewhat regularly. That seems cumbersome for a user.

Does anyone have a similar situation? If you do, have you found a way to streamline the user experience? Or have you found that users don’t mind this setup? We do not want to commit to packaging customized help for each client.

Any feedback is appreciated. Thanks.

[devans]

My situation is similar in that we have a number of separate applications and customers may use one or more of these applications.

I have one large project that includes the documentation for all the applications and they are all published in our HTML5 help. I guess it means that users have access to information that they might not use but it is a whole lot better than having to keep going to different URLs to get the information they need.

If some customers only want the information that is relevant to them, you could simply PDF the appropriate documents and send them to the customer. But at least they are all maintained and accessible in one location.

My project also includes additional information for our inhouse staff, so I actually publish two different versions of the project - one for customers and one for staff. It works well for us.

[jenco]

Thanks, devans. It helps to know what others are doing.
Unfortunately for us, the direction from high above is that clients get doc for licensed applications & add-ons only, so we can't publish it all together. Even the add-ons have to be separated. So if a client licenses applications A, B, and C, and licenses 3 add-ons for each application, they've now got 9 helps. Not very user friendly, imo, but maybe this is the only way with the constraints we've been given.

[devans]

That seems really inefficient. The only thing I can suggest is that you maintain all your documents in one project and then produce a separate target for each customer which contains the full subset of their documents. At least that way, they get them all in one location rather than having to access, say, nine different locations. I guess whether this is feasible depends on how many customers you have - a couple of hundred customers would mean a couple of hundred targets. However, once you have the targets setup, it shouldn't be too hard to maintain. It's just that when you make changes to a document that need to go out to a whole lot of customers, you'd need to re-build each target again. I am not technical but there may be a way to automate the build/publishing process?

[devans]

Sorry, it's a different TOC you'd need for each customer - just copy and paste the TOC entries for the appropriate manuals into that TOC. I think that would be easier than trying to maintain different conditions for each customer. You could use the same target (e.g. HTML5) and change the Master TOC each time you build for a different customer.

[devans]

Sorry, Jenco, more ideas! It's still going to be a huge amount of work for you if you have hundreds of customers. It might be easier for you to publish all your manuals together and instead get the programmers to do the work - i.e. they could put a logon on each manual so that customers could only access a manual if they were registered for it and had logon details.

[ChoccieMuffin]

Ah... I know there's a way to do it, as my predecessor has already done what you're after. Let me have a dig around and I'll see what I can find.

If my memory works today, we have a TOC that contains links to help files that only show up if the customer has that file installed.

Assumptions:
The master help TOC contains links to the COMPILED HELP files that the user might have (not the Flare TOCs).
If the user has purchased the plugin, the plugin's help file is installed into the same place as the Master help. You might need to get your devs to make sure this happens.
When the user has a plugin, they see the help file as part of the Contents when they view the main Help.

Attached screenshots:
The second shows the TOC with 9 broken links. Any user will only have installed one each of the A, B and I plugins and possibly the P plugin, but not necessarily all of them. When this help file compiles it does have warnings for the broken links but because I know what they are, I accept them.

The first shows the installed help where the user only has one of the I plugins and the P plugin, but no A or B plugins, which they don't even see.

If I were you I'd give that a go and see if it works for you. You really DON'T want to be custom-building help for hundreds of users!

[devjoe]

It sounds like what you want is run-time merging. This is available only on the server-based outputs for HTML5 and WebHelp Plus. For this to work, you'd have a small shell help system (the master) and each installed product or add-on would install its piece in the automerge folder. These would then appear as top-level books at the end of the TOC.

That may be a pain because it's server-only, and your users will have to have IIS set up. All of the local webhelp variants require build-time merging. On the other hand, if they have multiple installations at a company, the company could set up a shared server and each user wouldn't have to install a help component with each product installed. Otherwise, each project is going to be separate help system, unless you do a separate target/TOC for each customer or combination of products.

Years ago, before Flare, we used to get this capability with modular CHM files, but it was a pain to maintain (largely because RoboHelp didn't support it, and because there were lots of problems with what they did support in modular CHM output). I'm not sure if Flare supports all the requisite parts, either. Basically, you have a master CHM which has references to the child CHM projects. These files are delivered separately (i.e. you would deliver each module's help as one CHM along with a small master project), and they all have to be registered in the Microsoft HTML Help section of the registry in order for the help files to find each other reliably. The TOC, index, and search are merged at run time. In order to make it work, you have to select certain options in the projects, including Binary Index (required to merge indexes). If each program calls topics in its own help file as context-sensitive help, you also need the master TOC in each project to reference THE master TOC to make TOC merging work (otherwise, the TOC merging only works when the help is launched via the master project). If you want to go this route you should go find somebody in the CHM forum who has actually done this in Flare.

[jenco]

You've all been very helpful and I appreciate it! I'm not sure if we'll be able to implement any of these suggestions, but I'm looking into it.

[ChoccieMuffin]

jenco, it looks like the output type really matters, but you didn't specify what output you're looking to produce. My suggested solution works if you're outputting .chm files but won't work for html help because there isn't a compiled thing to add to your master TOC.

If you pin down what type of output you want for your help and it turns out you need something fresher than .chm, some proper experts might be able to help. Good luck!