Skip to main content
C
Colette_M_
Known Participant
May 24, 2010
Question

Merged Help vs. RoboHelp Server

  • May 24, 2010
  • 1 reply
  • 852 views

We are looking at using either merged help or RoboHelp Server so that 4 authors can publish portions of a large project independently.  I'm curious to know if anyone has had experience with both and what the pros and cons may be for the scenario below..

We have a large project that would consist of about 5 child projects in a merged help situation.  MANY topics need to be linked across child projects and across TOCs. Some topics need to be linked to other topics in another child project.  The "home page" includes links to pages across multiple child projects.We've gotten our test merged project to work for the most part, but we're still testing.

In a RoboHelp Server environment, do authors still need to focus on only one portion of the overall project like they do in merged help, or can they publish any topic to any area at any time?  Do they work with separate versions of TOCs and Indexes or do they all work within one? Can multiple authors update the same file, like the home page?  What are some of the possible disadvantages (other than needing to install it on a server)?

Thanks for any feedback.

Colette

This topic has been closed for replies.

1 reply

Peter Grainge
Community Expert
Peter GraingeCommunity Expert
Community Expert
May 24, 2010

We need to correct the beginning. You state you are considering merged help OR RoboHelp Server. Merged help can be delivered with or without RH Server as can a single project.

I would like to suggest that you take a look at the merged help tutorials on my site. I don't recommend that you have any content in the parent project because of the difficulty of creating links to and from child projects. When you publish not using RH Server, they will break. I am going to ask John Daigle to come in and deal with that point in merged help when RH Server is used.

If you use the method I advocate the parent is virtually nothing more than a shell and all the content that you would have in it goes into a child instead. Links between child projects are not an issue.

The way we work it is that each author starts with a full copy of the merge but is allocated specific child projects and one author is designated as the lead. Each author needs the full set of projects so that they can create links more easily. An author can publish their bit but what we do recreate the full set up and then the lead author publishes.

That is done by making a copy of the merge project set up and then deleting each child and replacing it with the source project as delivered back by each author. Sounds messy but is a doddle. Then the lead author publishes the full output.

The alternative is to also implement source control so that any author can work on anything.

Take a look at the tutorials and then come back with the next round of questions.

Why are you considering RH Server? Is it because of the reports and suchlike (fine) or because you think it is necessary for merging (it isn't)? We have various merge setups and one has around 12,000 topics in 9 child projects.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

Use the menu (bottom right) to mark the Best Answer or Highlight particularly useful replies. Found the answer elsewhere? Share it here.
johndaigle
johndaigle
Legend
May 24, 2010

Here's where I think folks may get confused about merging when it comes to RoboHelp Server. RoboHelp Server supports two ways of merging projects.

  1. Manual merging technique - (as described by Peter above - and the one most used.)
  2. Automatic Merging technique - With automatic merging, there is no master project TOC or "child" projects. Rather, separate projects are merged in a TOC heirarchy governed by the order in which the projects appear in a Projects list on the server.


In actual practice, I'd say most users of RoboHelp Server do not use the automatic feature and instead prefer the "manual" merge procedure described by Peter.

Aside from the merging issue, the more relevant benefits of RoboHelp Server are:

  1. User Feedback Reports - that allow for continuous improvement of content based upon learning the habits and needs of your users. (This goes beyond common log analysis such as Google Analytics.)
  2. Controlling user access to content and security authentication - This is particularly helpful when managing a knowledge base or online procedures manual where there may be a need for confidentiality (e.g., healthcare HIPPA rules, etc.)

So, while RoboHelp Server has many useful benefits, merging per se is not really the deciding factor.

Q: "In a RoboHelp Server environment, do authors still need to focus on only one portion of the overall project like they do in merged help, or can they publish any topic to any area at any time?"

Answer: Again, you would not work any differently in this regard whether you are using RoboHelp Server or not. Merging or not merging is not an issue. Authors can publish any topic to any area at any time regardless of whether they may be using RoboHelp Server or not. It's really more a decision of what makes sense in terms of not "stepping" on one another within your team. Depending on the size and complexity, it usually makes sense to designate a "lead" author to be responsible for publishing as described very well by Peter in the post above.

Q: "Do they work with separate versions of TOCs and Indexes or do they all work within one?"

Answer: The TOCs and Indexes are exactly the same. It's simply a different Single Source Layout that you use to generate and publish when you're ready.(i.e. WebHelp Pro instead of plain WebHelp)


Q: Can multiple authors update the same file, like the home page? 
Answer: Yes. But see the common sense practice and workflow suggested by Peter.

Thanks,
John Daigle

Adobe Certified RoboHelp and Captivate Instructor

www.showmethedemo.com

John DaigleAdobe Certified RoboHelp and Captivate InstructorNewport, Oregon
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices