I have 1 registered domain in which I need to build 4 projects.
Let's call them A, B, C and D.
The users accessing the website, will be subcribed to one or more projects.
I want to structure the individual projects in such a way, that when a subscribed user executes a search in Project B, the search will be limited strictly to the contents of Project B; in other words, no content of Projects A, C and D should be retrieved.
I don't know how to do that and I also don't know whether it requires to use 4 separate projects or that it can also be done in a different way.
Ideally, I would like to use one landing page, from where the subscribed user can jump to the project they're entitled to use.
I know there's a lot of brainpower & experience in this forum, so my question to you is:
please enlighten me.
My workflow will be: FrameMaker 2019 > RH2019 (frameless HTML5) > website on the Internet.
I don't have existing content, so nothing needs to be converted.
I just want to build with the correct structure in place, instead of having to find out after the fact that the whole setup is wrong.
Thanks in advance for your feedback and tips.
I don't work with FrameMaker but to the best of my knowledge, you can do that from FrameMaker without going through RoboHelp unless you have some other reason for doing that. I'm sure someone with FrameMaker knowledge will be able to commment on that.
The only advantage right now of the FM to RH workflow is that RH gives you a few more choices in output layouts than FM alone does & there's a bit more of the options exposed in RH for tweaking than in FM.
we already set up such a multi-output project using the frameless skin in RoboHelp 2019 (new UI), and also reused some FrameMaker content for that purpose. Seems to be the use case you're heading to. By the way: your user ID hints to Germany - we're based in Niedersachsen/Nordrhein-Westfalen. Maybe we should connect... 😉
What we did:
We started our RoboHelp experience with a 200-pages manual made with FrameMaker 2015 and imported it to RoboHelp. During this process we split it into topics on the subchapter level, resulting in about 90 topics.
Next step was to adapt the content to the topic-based approach of content delivery (EPPO - "every page is page one") and use the features of the web interface for easier access to the information (descriptions to programming platform, somewhat complex and tending to be "too much information" at first sight, so we appreciate the features for hiding/unfolding sections, popping up glossary terms and so on).
Yes, some of the features can also be added in FrameMaker, such as drop-down text, but you'll have a much better control of all the features by toggling between the editor, the XHTML source code, and the preview while editing which is possible with the RoboHelp interface.
All this content is related to a common ground, so having it in a common user interface and search base was the perfect choice. A single RoboHelp project, crafted by two technical writers of whom one is mostly teleworking, sharing the assets (like images, masterpages, and css formatting of content) and synchronising via a GitLab repository. Working quite fine (after some obstacles).
By the way: By now, we do not need a restricted access to our content, but it sounds interesting for keeping some information internal / private / employees access only. Let me know how you will set that up, will you?
After redacting and converting all the content, we generated a "Frameless" output and uploaded it to a cloud service where it can be linked into an online community menu. Need to add or correct something? Just edit, generate a new output, upload - et voilá! - ready in minutes. What we did not manage to do by now is publishing directly to the cloud service, due to some obstacles there. We're changing the platform soon, and then it will be a complete working process out of RoboHelp.
We are doing this for about half a year now, and we would never go back to FrameMaker again. One of the reasons is the lack of real list formats in FrameMaker, and some other exhausting things we need to correct after converting to XHTML.
Next step: adding two separate content packages
As we presented our new online information platform, some colleagues got excited by this approach and wanted to put their manuals into this kind of platform, too.
Because their topics are not closely connected to ours, a different output with its own search base would be the best idea.
BUT: Having a corporate design and approach to displaying content in this way, all depends on the same tools and sources in RoboHelp, and not copying anything to another project. This is done by using the same RoboHelp project but adding another content folder that uses the same central sources:
So, this is what I recommend for your use case:
Set up a single project, and just separate the topics by folders on the first level in the content view of the RoboHelp UI (which is the sames as the "Content" directory the file system).
For generating an output, we only put the related topics into the ToC that will be used by the output preset. Of course we're using the Conditional Tags feature, too - but not for separating the output. It's much easier (and better to comprehense and control) to do it via different ToCs. You put your topic structure into a ToC by dragging and dropping a content folder - and this is just one of the folders in the content section.
This way, we already put up two new outputs in the same way, working now on the same RoboHelp project with four technical writers and publishing three separate outputs that do share the tools and standards, but do not share the search function which is based on the output content only.
Let me know if you need some more details to this, we're happy to help.