A few questions about RoboHelp

[Guest]

Hi there,

this is my first time to post on the forum so please forgive me if my questions seem a bit silly!

I have worked with RoboHelp before, but I have just started a new job where I will be required to manage several RoboHelp webhelp projects at the same time. Different authors will work on different projects but it will be necessary to create a single project for each release of our company software. Links between child projects will be required. I have a few questions about managing multiple RoboHelp projects:

I have read the www.grainge.org website regarding merging RoboHelp projects and it seems that merging is the way to go if different authors are working on multiple projects.

I was wondering, however, how people usually manage merged projects. Say, for example, each team member provides me with a child project before the release of version 1.0 of our software. I create a merged version of the project and create all the necessary links between the child projects. When 1.0 is finalised, we need to begin working on version 1.1, so each team member needs to continue working on their own child project for this version, but I also want to maintain the links between child projects and allow team members to create their own links between projects (if possible). This is where it gets a bit confusing.

Is it possible to demerge the projects after the first release, so that each author has a new version of the child project that includes the links to the other child projects. Or, is it necessary to provide each team member with a copy of the merged project so that they can work on their own child project and also have access to the other projects for linking purposes? And then, when it comes to creating a new merged version of the project for the version 1.1 release, is it not a bit complicated if each team member is now working on a version of the orginal merged project? It seems a little bit complicated and I would appreciate if anybody has ideas about how to manage multiple merged projects in this scenario.

I have also been asked to investigate the possibilities of printing an online help from the end-user point of view. Creating PDF versions of the online helps will be part of my role, but I also want to investigate whether the end user has the option to print the entire online help themselves (and not just pages of an online help, which I know is possible!). For example, with the online help for RoboHelp Screen Capture, there is an option to print the entire online help. But I have not seen this option in some other online helps and I wonder whether this is something that can be configured in a RoboHelp project istself.

Thanks in advance for your help!

Niamh

[RoboColum_n_]

There is no problem with the questions Niamh as we have all been in your situation so are only too happy to offer advice.

Regarding the inter project links, it is best to have some control over these. The issue arises where AuthorA adds a link to a topic not knowing that AuthorB has renamed, moved or deleted it. You could handle by leaving the links until the final stage before delivery and ensure that all the authors have the latest content. However this is not always easy. I personally would suggest that a single person is responsible for adding the links and if you are doing that for version 1.0, why not do so for version 1.1.

As for how you'll get the team all working from the same source, this scenario is begging for a source control application. There are a number available, RoboHelp even has its own application built in. It works by having a central database that contains the RH project files. Authors check the code out for the project they are working on. When they are finished they check the code back in. The advantages are that you have a full audit trail, backups and no two Authors can work on the same code at the same time. Having said that, there are ways around that final scenario if it is an issue for you.

Finallt the print issue. You can generate a PDF directly from the Printed Documentation Single Source layout. You don't say which version of RoboHelp you have but I'm reliably informed that version 9 has some improvements in this area. I don't produce printed docs in any shape or form but my advice would be to generate a Word file first and then PDF it. If you want to provide a printed version of the WebHelp, you can do this and embed the PDF in a topic or in the TOC to make it accessible to your users.

---

The RoboColum(n)

@robocolumn

Colum McAndrew

[Guest]

Thanks a lot Colum!

I will be using RoboHelp 9.

Regarding the merged projects, the situation would be that each team member works on a single RoboHelp project and I would be the person to merge the project (and create the inter-child links, I suppose!) at the end of the project.

Is it the case that, after a release, each team member could go back to their child project and work away on it as normal so that for the next release, I could set up a new merged project and merge all the child projects again? In that case, would the links created between child versions in the first version be maintained or would they be lost?

Also, in my company, it would not really be necessary for two or more team members to work on a single project at the same time, I think. That said, we would definitely need to keep back-ups for each project - is it worth using RoboSource Control simply for this purpose, do you think? I have no experience of using source control for RoboHelp so I would need to be sure that it would be necessary to go to the effort of learning how it works and setting it up, if you know what I mean! Previously I have saved regular back-ups of my RoboHelp projects to the network.

As regards, the printing, my question is really whether the user can actually print the entire online help themselves if they wish to do so. So if they open the online help, is there some kind of option (that can be set in RoboHelp) that allows them to print all of the topics rather than just the current online help page that they are viewing.

[RoboColum_n_]

Grrrr! Don't you hate it when you spend 10 mins typing a reply only for the forum to crash forcing you to type it all again - and relax!

If you were the one who added any inter project links, you could in effect be the source control application! You'd just take their source, create the merged project, add any links and generate the output. Then once version 1.0 has been released you could give them back their project source to start on version 1.1. However you'd have to 100% sure that they would not be making any amendments whilst you are working on the merging / linking. If they need to do any updates, they could keep a record of what has changed and manually import the affected topic, TOC, Index, etc. files but this starts getting messy and prone to error.

The real beauty of the merged project setup is that it only needs to be done once. As long as there are no changes to the projects being used, your team would just give you their source files which would fit snuggly into the structure you had previously created. The provisio here is that there have been no changes in the project names, number of projects, etc. Just setup as described by my friend Peter Grainge. You just need to add the links, generate and publish.

Personally I wouldn't use source control just for backups. Carry on backing up to a network would be my solution. Source control really comes into its own when two or more authors have to work on the same project. Should you choose the source control route, there are a number of other applications around. Microsoft Visual Source Safe and Tortoise SVN being just two that I have used. However there is a learning curve and some set-up with any source control application that needs to be considered before going down this road. As long as someone (I'm guessing you) has a copy of all the source somewhere that the others can copy when they need to, that would be good enough but it is your choice. My personal opinion though is that this would be better handled by a source control application in the long term.

As for the print function, this is possible if you really want to kill a few more trees Is this a user requirement? What you'd need to do is set-up a custom button in your WebHelp skin which would have some Javascript attached to it. It would be best if you already had a Word / PDF file to print though. This requires you to be comfortable with editing Skin files (which I can help you with) and writing JavaScript (which I'm definitely not). There are a number of Javascript sites around that you may be able to find a fit.

Yours copying this text to a Notepad file in case things crash again

---

The RoboColum(n)

@robocolumn

Colum McAndrew

[MergeThis]

You are creating more work for yourself in assuming a production-time merging/linking process. Once you set up the merged project as per Peter's (we all bow before the Master) tutorial, you need to establish this architecture on your machine:

SOURCE
master
projects
...child1
...child2
...etc.

OUTPUT
master
mergedProjects
...child1
...child2
...etc.

1. All writers reproduce the projects/child and mergedProjects/child folders on their machines (they have no need for the master project).
2. They synchronize updated files from other writers' current files. How this is done is a choice to be made by you and your organization (a source control product, some form of automated synch process overseen by IT, etc.).
3. When the child2 writer needs to link to child1, the writer selects Link to > File to select the child1 target topic file (and ignore the warning about linking to an external file; that's irrelevant when you're in a merged project like this). RH then understands that it is to transform the initial absolute link that you see in the dialog's field (file://C:blahblahblah) into a relative link path (../child1/target_topic.htm).

Then, of course, you would generate and publish the master as needed (changes in the skin, adds/deletes of child projects, etc.).

The beauty of this merged setup, as Colum says, is that there is no "whole-project compiling" needed here. Everyone generates and then publishes to a server location on an ad hoc basis. That is, if child1 has not been changed in the month prior to ship, it does not have to be generated/published at ship time. Your release engineering group then pulls the help from the server location to insert in the product build.

As the mergeProject overseer, you don't need to add all those links either. Just download the free Xenu utility for link checking, and you're good to go! You can ask Xenu to create a report "by page" (the topic file first, then its broken link) or "by link" (the broken link first, then the topic in which it appears). We've settled on the "by page" report here, but you can try both to see what fits your group best. Then distribute the report to the writers and have them clean up what's needed.

Good luck,
Leon

[Guest]

Thanks a lot, that's exactly what I needed.

I will definitely have to raise the issue of SourceControl and see what management has to say. If we do go with it, I think I will need specific training on the subject as it's really outside of my area of expertise and it would be better to know what I'm doing from day one!

Thanks again!

[Peter Grainge]

Source Control will allow many authors to work on the same project and I don't disagree with anything Colum has said.

If you choose not to use source control then the process is that you hold the master of all projects in the merge and issue copies to the other authors so that they can create cross project links. While they work on a child, no one else can. Each author can only work on the projects assigned to them. Periodically you take their copies back and replace what you have.

As Colum says, no renaming and it does not cover new topics. For us that works, it might not in other workflows.

Looking at print. You cannot get a single document that covers many projects, other than be merging in Word. Do you really want individual users printing the whole help?

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Jeff_Coatsworth]

Regarding printing the entire help contents - I've just discovered in RH9 that locally-installed AIRHelp's Print button has the option of printing just the 1 topic page you're on or the entire help project. The problem is that I don't think AIRHelp works for merged projects (from what I can remember running across - I don't work with merged stuff at all).

[Peter Grainge]

First locally installed AIR help cannot be merged, as Jeff suspected.

Second, depending on the size of the help, Print All may not be successful. Also check out the print quality.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge