Different Help for Different Web Site Domains

Hello LaKisha -

Pick up your private message file.

Regards,
GEWB

Thanks everyone for your suggestions. It really sounds like developer-intervention will be required after I produce the master files, if indeed we go down this road. I wish we could do what MergeThis said ("can set the conditional text yourself, based on the input from the teams. For example, a topic can have multiple H1 headings, each based on conditions you create"), but there is no way for me to know upfront what conditional names I should add. Clients can ask for the names to be changed to whatever they want, and then the project teams make the changes. So for me, as the developer of the 'baseline' materials, it would be like putting "xxx" in there as the conditional text and the project teams would have to change it anyway.

Linux Rules,
I think we could really use your help. I'm not sure we have the capabilities required to carry out your idea (using a server, etc.). I think it would be wonderful if you had time to talk to two of our developers and our requirements manager...is that possible?

To be honest, I have no idea how to answer your questions, except to say that the user clicks an icon on the page to access Page-level Help (an individual HTML file specifically explaining the page they are currently looking at), and they click a link at the top of the page to access Site Help (the entire Help system).

Thanks again everyone for your input!

Lakisha

What you describe is virtually not possible. Yes you could create a master and keep issuing it to the installers and yes they could keep amending a copy using RH but the work would be ludicrous and there would be errors. As Linux Rules say, breaking it down to match your application is the only chance you have.

OK, you have 200 sub-domains. Some things are manageable, but it's unreasonable to demand total variabilitity, and, in fact, I doubt they will have so many permutations and combinations across 200 products. Some commonalities should appear, I'd think.

Including and excluding material can use build expressions if you can define common patterns. Say, for example, The topic "Blue Moon" will be seen by everyone in Groups A and B but omitted for all other groups. The topic "Who's Sorry Now?" will be seen by everyone except people in Group C.

It gets complicated, yes, but if there's any commonality among clients, you can take advantage of it.

For a given label, such as "Surveys," how many variations are there likely to be? Certainly not 200, I'd guess. Can they give you an idea whether 5 or fewer variations are most likely? Do they expect "Surveys," for example, to morph into 100 alternatives?


Harvey

OK. I've spoken with a member of management and let me start off by saying my example of usage in my first posting was a bit too in-depth. Thankfully there won't be any turning on/off of fields on individual pages. Here's what the project teams have to do when they are customizing:
1. The TOC needs to be different (dynamic) for each domain, and any reference to a title/item/name in the TOC needs to match that title/item/name in the web site.
2. They might also move TOC items around (might be different order for each domain)
3. Change names of menu items (might be different order for each domain)
4. Turn on/off entire pages (one sub-domain might display information that another one doesn't, i.e., sub-domain 6 has "Surveys" in the TOC, but sub-domain 8 doesn't have anything at all that has to do with surveys)

Allow me to provide a better example and then answer the questions from Peter Grainge and Linux Rules.

The parent domain will have a site menu. The TOC for Site Help matches this site menu. For each sub-domain, project teams may move things around in the menu, or remove some items altogether. Say, for example, the parent domain has a menu item named Surveys. In the first sub-domain, this item may be renamed as Your Surveys. In the second sub-domain, this item may be renamed as Give Us Your Feedback. Therefore, we have the same function with three different names in three web sites. The Site Help for the parent domain and each sub-domain will need to reflect the correct name.

Peter, if I understand your merged WebHelp explanation correctly, the problem is that we can't have 200 sub-folders (1 for each sub-domain, right?) and that's what makes this tricky. We definitely want to find a solution that ensures that the TOC, Index & Search only contain the appropriate information when changes are made, but the goal here is reusability without having a sub-folder for each sub-domain. Is this possible? Currently we aren't doing anything for sub-domains - this flexibility isn't available in the product yet. It is in the planning stages, which is why I've been asked to figure out how to modify our current Help to work within sub-domains. Right now the product just has one set of source files that produce one set of output files. We need to make the current files 'dynamic' enough to allow the changes without additional sets of output files.

Linux Rules,
The 'ideal' situation (i.e., what we are striving for) is that each project team will have access to RoboHelp and one person trained in how to use it. I've also already written a detailed procedure to help each project team accomplish the task of updating the help files when they do their customizations. They will be modifying the source files and generating new output based on their customizations. For each product release, I give them a list of the base product help files that I've updated and it's their responsibility to get those changes implemented in their client's customized help files.

Alas, any ideas?

Hello LaKisha1 -

Does each project team have a copy of RoboHelp and at least one person trained in how to use it? If so, you have a fighting chance but it will require solid planning and adherence to the procedures.

Or do they expect to modify the "base" generated WebHelp output files (html) and use that for their Help? If so, prepare for disaster, don your life vest and prepare to jump ship.

With deep sympathy,
GEWB

Is this a new setup? I ask as what you seem to want to do is strip out certain topics for certain setups. If you start just trashing HTML files from the baseline help, those topics will still be referenced in the TOC, the Index and the Search so users will be clicking links to topics that have just been blindly stripped out. Your installers cannot tweak the TOC, the Index and the Search. If it is not a new setup, how is it being done now?

Merged webhelp is what you ruled out by saying you could not have multiple projects. This broadly is how it works.

You have a parent project that all installations have. Then you have child projects with content split between the child projects in a logical manner. You generate an output from the parent and RH creates a folder under that called mergedProjects and that in turn has one folder ready for each child. You then generate the help for each child into its respective folder.

Now where this gets useful is that having generated the whole lot, you give it to the installers. For any given installation, they just trash the child projects they do not want. The TOC, the index and the Search then automatically adjust. Much cleaner.

In your scenario what you must avoid is links between two projects where a user might have one and not the other.

BTW. It would not be the installer or the client using the build tags and generating different outputs. You would be doing that from a single project creating a library of outputs.

The only other option is each domain does have its own help but that feels as if it would be messy for the end user.

Welcome to the forum

I am not clear why you rule out merged webhelp but assuming that is something you do fully understand and have good reason for ruling out, then perhaps the use of build tags and expressions is the other way to do it.

Apply tags to relevant topics so that you can include / exclude topics in a build. Under SSL you would have multiple webhelp layouts all configured with the relevant expressions.