Is there a way to make certain portions of a table of contents invisible to some groups, but visible to others?
For instance, let’s say I’m creating a RoboHelp project for a website that has some accessibility to the general public, but other sections of the site unavailable to the public; also, some portions of the website available to certain departments in our organization, but not to others. Put another way, say our company has sections A, B, C and D. The general public would not have access to the topics in the website concerned with these sections, and, in fact, each section would be “partitioned” from the others, so that the people in section A would only see ToC entries for section A, etc.
Confused? Let me know…
Not securely if you had to make sure that the public won’t stray into topics that they weren’t authorized to see. DUCC can separate out different streams, but if you choose the wrong one, nothing stops you from seeing that help. I suspect that you’re going to have to produce 2 (or more) flavours of output – one public & one private. The private one you would host behind some secure login gateway.
Thanks, Jeff, but I don't know what "DUCC" is.
I did find on tv adobe a video* that describes how to create separate table of contents, which may help. However, with that in mind, how do I show each group its own ToC? Do I have to compile a different RoboHelp for each ToC?
I think it stood for “Dynamic User Centered Content” or something like that. Yes, you can create multiple ToCs and associate each of them with separate flavours of WebHelp. Just create (or copy) your existing Single Source Layout for WebHelp.
Dynamic User Centric Content.
Couldn't I use Conditional Build Tags? Wouldn't that work?
If you just want to let people filter the content for ease of access, then you could use DUCC.
However, if there is content that must not be seen by one or more groups, then you would need to create completely separate output as suggested by Jeff.
You can achieve this either by creating separate projects for the different roles, or by having a single project and generating different outputs for each role. If there is no common content between each role, then it may be easier to create separate projects. If there is a reasonable amount of common content, then you may be better to have a single project with different outputs. In both the multiple project, and single project options, you would end up with separate help for each role, and the help for each would be published to a separate location. When each role tried to access your content they would be directed to the location of their own help. e.g. Admin might go to www.mycompany.com/admin_help. Public Knowledge Base users might go to www.mycompany.com/kb.
For the single project option, you would probably use condition tags. You may also need to create different ToCs for each role, but this will depend on how similar or different the content structure is for each role. You would then create a Single Source Layout (output) for each role and select the required table of contents and conditional build expression for that output.
I'm not sure how familiar you are with condition tags, so I'll include a few remarks about them, just in case.
How you direct people to the applicable help location, and how to set up security so that only authorised people can access sensitive content are not part of Robohelp. You would need to discuss these issues with your developers and IT/web server admins.
Hope this helps.
Jumping into the fray here.
One other option would be to create a merged system. With a merged system, you have separate RoboHelp projects. Each project containing its unique data. You then nominate one project to be the master, or parent project that gathers and combines the other projects at runtime.
The beauty of this particular approach for your situation is that you could structure things in a way that your IT folks control who sees what. For example, perhaps everyone can see the folder where the master project lives. And in the sub folders where each of the other projects live, your IT/Web Admin peeps control who gets to "see" that folder. If a user can't view the folder, the TOC self adjusts to not even show those entries to the user, so they are completely oblivious to the fact there is more there than may meet the eye.
Yes, I'm still wrestling with this problem, with a couple of new questions:
Does anyone know anything about RoboHelp 2015? Apparently it has "Dynamic Filters" that, according to an article in Tech Whirl, may be the answer, which leads to my second question:
Does anyone have any useful comments/observations about Responsive HTML5 as an output? The article says that this is required to use the Dynamic Filters. I'm now using WebHelp ...
When you create WebHelp output, you have the older browser window split up into framesets with the TOC and Index and Search and Glossary occupying different frames and having links that present information in other frames. On mobile devices, this often doesn't work.
So we now have this "Responsive" design where there are no frames any longer and the display changes based on the width of the viewing area. Because it reacts and shows different things depending on width, it "responds" to the width of the display. Hence the term "responsive".
In this new Responsive world, Adobe built in "filtering". Basically what you do is use Conditional Build Tags and tag information that might be applied to a filter. For example, perhaps you have a help system that talks about colors. So you tag anything related to Red with a tag named Red. And anything related to Blue with a tag named Blue. And anything related to Green with a tag named Green. You then configure filters so that your end user could click to enable seeing only information related to Red. So you filter out anything tagged with Blue and Green.
Hope this helps... Rick
But this filtering feature still probably wouldn’t serve your purposes because the user still gets to choose what flavours they want to see results for.