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
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.
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.
Yours copying this text to a Notepad file in case things crash again
The RoboColum(n) @robocolumn Colum McAndrew
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!
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
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:
- All writers reproduce the projects/child and mergedProjects/child folders on their machines (they have no need for the master project).
- 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.).
- 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.
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).