Multiple Scattered Authors

[Guest]

I am developing WebHelp on a contract for a company. Some of the content is being supplied by various non-tech writer people scattered around the country, via Word documents. I incorporate the content into RoboHelp. This seems to be working fine and efficinetly, however now that the RH project has been set up and settled in, they want all of the contributors to start authoring directly in RoboHelp (which none of them has ever used).

I believe that after the first wave of collaboration through the next 2 software releases, the project will end up in the hands of one person who maintains the content. Some of the contributors will not even be on the team anymore.

With all of the nightmares I have been reading and hearing about regarding RH with source control and accessing a project over a network (wirelessly no less), I am concerned that whatever benefits are gained from having each content provider work in RH does not outweigh the pain and expense in work hours that will be involved, from an intial setup perspective, IT troubleshooting (through outsourced IT), and the RH learning curve for writers.

I keep reading warnings about not running a RH project on a network. Is that the same as each writer having a copy of the project on their desktop and using RSC to check files in and out ?

To anyone who has gone through it, was there a lot of back-and-forth with IT to get it set up ? Was it worth it ? Did you bail and what did you do instead ?

Bottom line, I want to recommend that this company continues down the path we are on (one person maintaing the RH content) and not open a can of worms with multiple authors and RSC. Can anyone convince that is good advice, or not ?

Thanks

Johnny in Sarasota

[Jeff_Coatsworth]

Definitely good advice - unless you really need it, stay away from Source Control (in whatever software form it takes). BTW - working on the network and SC aren't the same; in SC, you check out the project's files to your local drive, work on them & check them back in.

[Guest]

One way you could approach it is to use a merged project. You could use the sub projects for modules of help that can be updated by different people. That way you have some flexibility but don't use revsion control software.

[Guest]

I was actually just reading up on Merged Projects. I'm not sure it would be a good fit.

I currently have a help project that consists of about 70 topics, divided into sections in the TOC by the main UI page they relate to.

Going forward, different people will "own"each of those sections and either updating those existing topics, or adding new ones to the section. There will also be entirely new TOC books with topics added.

Doesn't sound like merging is practical in that scenario ....

[Guest]

Well, you could have a sub project for each UI section for example....

[Peter Grainge]

You cannot have a non source controlled project on the network. With source control the authors take check out what they need to their local drive and check back in the changes.

As I see it, either you implement source control or you go with Author Care's merged help suggestion. You would have the full setup, the authors would have just their project(s). After updating they would send you their project and you would overwrite your old copy of it within the setup. May sound a bit messy but as long as you are methodical, it works fine, it does for us.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[EuroMatt]

I would go with Author Care's suggestion in this situation and have each content provider create their own manuals, which you then merge with a master project that contains the top-level TOC for each section. 

I work with another author on a project that was maintained by just one person for 3 years.  We do not work in the same office and so trying to work collaboratively was awkward, even with source control.  In the end I decided to turn several of the more disparate sections of the manual into separate projects, which I merge (both as CHMs and webhelp) back into the original on output. 

The only thing I would add is to make sure they are all using the same stylesheet.  Because our master and child projects are all under source control, I share the CSS between the projects.  That way any changes to one are available and clearly visible in the others when the other authors next get latest.  It helps provide parity and clarity for all.