I have a project with about 150 topics that will soon grow rapidly for some of the following reasons. My project is basically a technical reference guide for a suite of software applications that Clients can implement all together as a comprehensive solution or individual components. Currently the project contains information for all the components divided into sections for each. Clients can easily navigate via TOC to the sections that cover the
information for the components they have implemented, but they usually just use the search to find what they are looking for. This has worked fine so far, but the problem is that the main (base component) is completely changing while the other components will remain the same (although they will continue to be upgraded with new enhancements). I would like to replace the old content on the main component with new content and just do away with the old, but that is a no go, because our organization will continue to support the current version of that main component for at least another five years. What makes it worse is that Clients can choose to keep using the older version of the main component, but continue on upgrading the other components. I do not want to split the whole thing in two, because more than 1/2 of the topics need to stay the same and be accessible from both the new and old versions of the main component topics. I do not want to maintain two instances of the same topics for the other components. In addition, I also want to be able to publish everything at the same time and to the same location. I also need to be able to keep the URL the same for Clients who continue to use the current version of the base component and have a different URL for Clients who are using the new version of that base component.
So basically, the whole mess looks something like this:
That all being said, does anyone have ideas as to the best way to accommodate this situation:
RoboHelp 10 / WebHelp Pro (currently)
Before we fall into this rabbit hole, just one question.
WebHelp Pro. Are you also using RoboHelp Server and publishing to that?
WebHelp Pro is what I am currently using for final file output. The generated files are all actually published to a SharePoint library that is externally accessable (it is the SharePoint environment used for the external company Website).
I realize WebHelp Pro cannot handle the Dynamic User-Centric Content thing. Is there any reason I should be using WebHelp Pro other than I just inherited it that way?
Last question not to immediately get things off track though now that I think of it - apologies.
All too often we have seen folks opt for WebHelp Pro as the output type in a rather misguided belief that it is somehow better than basic WebHelp. (Gee, if WebHelp is cool, then WebHelp PRO has to be all that and a bag of chips!) Or, for a real world recipe comparison, consider Apple Pie. We all know Apple Pie is awesome. But if you saw a menu that offered "Apple Pie" and "Aunt Martha's Special Apple Pie" you might consider choosing the latter because the former sounded "boring". And in reality, Aunt Martha was diabetic and her version of the pie contained a sugar substitute.
The thing is, it's simply a different output that is specifically intended for use with the companion "RoboHelp Server" application. The files are generated with specific coding that "converses" with RoboHelp Server. So if you are simply publishing to SharePoint, WebHelp should be just fine. This would explain why you cannot use Dynamic User Centric Content. I don't believe that particular feature works with the Pro output,
I'll be back in a bit with some suggestions. Until then just know that you should seriously consider moving away from WebHelp Pro and toward basic WebHelp.
I would create specialized TOCs for every component and merge them into a main TOC. With CBT's in the main TOC to filter the content.
If you place content for each component into separate folders, it'll be easier to manage. No need to split up into multiple projects, use merged help or something like that. As long as you're below 750 topics I wouldn't recommend the hassle of splitting up.
When you use WebHelp, you can use Content Categories to create multiple outputs in the same WebHelp. The downside is that users may need to switch categories based on their product configuration. When you can use RH2015 Responsive HTML5, you can use Dynamic Filters to achieve the same.
Do you know which clients use the old main component or new main component? If you know, could there be a way to deliver clients help for either the old or the new component? In that case you don't have to use categories. You can simply create two separate outputs and deliver either one or the other to your client.
You may also be interested in my mini course on content reuse: Adobe RoboHelp: Advanced Content Reuse
I have a couple questions related to your responses that maybe you can clarify.
You mentioned creating specialized TOCs for every component and merging them into a main TOC. Is this really necessary or could I just create two main TOCs, one for each version and tag only the content that is specific to the old and new component?
When I output, I would probably have to do two, since I do not want the Clients to have to choose the right category. I think I would have to also create two folders in the SharePoint library for each "version". We would then need to provide Clients with the appropriate URL for the version of the main component they are using. Is this beginning to make any sense or am I just plain delusional? Also, do you think there is any way around having to do two outputs? I really want to avoid having to output twice and have extraneous files to publish.
It is not necessary. Why I would recommend it, is that you will have only 1 TOC for every component. Content from different components in the main component will only exist once. If you create 2 separate TOCs, you will also have to maintain component content for both TOCs. Having multiple ones avoids that.
If you have just 2, that makes sense. If the client (or the software?) points to the right output, it will work. And you will only have the one RH project to maintain.
Thanks for the clarification, it is all making more sense now. In any case, will there be any way to avoid having to do two individual outputs every time I want to publish? I would really prefer to only output once and get the two "versions" with different URLs. I think this can be done with DUCC/WebHelp, but do not want a User option to actually pick the type of content to view (just direct them to the appropriate URL).
Sorry to be late to the party but isn't this a scenario for merged help. The output would appear as one to the end user but you could have one project with those topics that always appear and other projects for the bits only relevant for some clients.
Take a look at Merging WebHelp - Reasons to see if you think it would work. If it does fit the bill, there are also tutorials on how to go about it.
See www.grainge.org for RoboHelp and Authoring tips
Just to be a bit clearer, you could have say four projects, A, B, C and D. None would contain common topics. All customers could have the output of A and then you would supply any or all of the others. To the client it will work as one output.
See www.grainge.org for RoboHelp and Authoring tips
Thanks, this is good to consider the options. I am a bit weary about having multiple projects, because editing/updating the content might prove to become too much of a hassle to make it worth while.
I am hedging towards having one project, two TOCs and two outputs if it seems manageable. In any case, I will check these tutorials, because you never know?
Thanks for the excellent explanation on that. I will go with regular "Apple Pie" from here on out.
Looking forward to seeing your suggestions!