Structuring Help for Many Apps and Agile Development

Question

Hi Guys
I am starting to evaluate RH9 (with server) and am lookign for seom advice on structuring help.
We produce a management information system, which comprises 17 apps.
We have major release versions: e.g. 4.9, 5.0 and then sub builds (e,g. 4.9.0.23)
Most sub builds contain new features that require documentation. We do agile dev, so we are producing new builds every few weeks. This means we can't just produce documentation for major releases (e.g. v4 and v5). This is waht we do right now, but it means it's always out of date
My initial project is to setup the master pages and css and import the Word manuals into RH and do any necessary cleanup. We will initially publish web help and "printed" (PDF) documentation from this, but eventually want to link into our applications (initially on the help menu and them adding context sensitive help).
So if a user is running 5.0.0.23 of Inventory Management and goes to the help menu, I want them to be able to get to the documentation for that specific build.
So, from a documentation point of view, how do I manage all of this?
Do I put it all under one project or one project per app or per major version or build? My main concern is that we can literraly have 100's of different builds in use by customers, so if we change the documentation for feature X, all users on relevent builds get the updated documentation.
We are keen to get user feedback and improve areas that require improvement, so let's say a user says the documentation for setting up warehouse locations is not very good. This feature has been around since version 1.0, so we want to update it's documentation and have it available to all current versions (4.x and 5.x). Is there a way to setup the documentation such that I can flag parts of it to specific versions. Using the above example, I want users on all versions and all builds to get the updated version; however, if we change the way locations are managed in 5.0.0.23, how do I ensure that everyone on 5.0.0.22 and below gets version A and everyone on 5.0.0.23 and above gets version B? Clearly, I don't want an entire project for each build (e.g. 5.0.0.23); otherwise, I'd have to make the smae update dozens of times if it's documentation on an existing feature .
One other thing to consider: related topics can be in other apps. For example in App 1, a related topic might be something in App 2.
Any pointers greatfully appreciated
Regards
Mark

Answer 1

What you describe is similar to what we are doing currently, with a few notable exceptions. Two of us maintain a large number of online user's guides that are published both as Webhelp (25 projects merged into one parent help system) and as standalone .docx and .pdf files. We are also using Agile. Our company offers two or three major releases per year (2011.1, 2011.2, 2011.3) with one or two patch releases for each major release (2011.1.1, 2011.1.2, etc).
Our customers also use different versions--some are still on last year's release (possibly earlier), while others install the latest version as soon as it's available.
A few things you may want to consider:
1. We've had limited success importing Word documents directly into Robohelp--the HTML invariably gets screwed up with a bunch of extra codes from Microsoft. We've found we have better control over the help files if we simply copy the Word text to Notepad and then copy and paste the stripped-down text to Robohelp, where we create topics, apply styles, insert hyperlink, and import images. This method of converting text from Word to RH takes longer initially, but seems to work better in the longer term, especially if the original document had nested lists or complex tables. FWIW, doing the conversion is relatively mindless work--the kind of task that is great to do at the end of a long week when your mind is numb from writing.
2. The start pages for each of our 25 projects are linked to their corresponding modules in the software (users can click the Help icon or press F1 to see the online help for the module or to access the entire help system). However, we do not offer true context-sensitive help.
3. We use the same source control system that is used by our software developers and check our Robohelp files into the same mainline code branch--this means that up-to-date documentation accompanies each release from mainline. Typically, we do not update the help files in our patch branches, since this would mean duplicate work (after updating the help in the patch branch, we'd have to make the same updates to the mainline branch). Instead, we use release notes to document any user interface or functional changes in patch releases. That said, the majority of our patch branches are for bug fixes, not enhancements, so they require only limited changes to the help.
4. Our entire help system is automatically generated during our nightly software build using the RHCL batch command. When customers install a new release of our software, the latest help files are automatically written to their computers.
5. After major releases only, we generate a revised Word/PDF file for each project and post those files on our customer support portal. Other than that, we make no attempt to provide improved documentation to customers who are using downlevel software. That is, if we need to rewrite the basic instructions for some task, we update the mainline branch for use with the next software release and all subsequent releases. I guess we figure that if our customers are interested in the latest and greatest instructions, they should spring for the cost of a software upgrade.