Team Authoring

Team authoring is an important requirement for technical communication. Technical communicators are often working in teams and need to collaborate on projects. There are of course several means of collaborating, for example, through e-mails, shared folders, source control repositories and content management systems.

Each of these collaboration methods have their positives and limitations.

E-Mail

E-Mail is convenient and available for everyone. While ad-hoc nature of e-mail is positive, it can also become a problem when you have tight deadlines. Since there is no shared collection of all the project files, there is no way of tracking the team activity and ensuring everyone has a same view of the project at all points in time.

Shared Folders

Shared Folders are easy to use, can use access control built into the operating system and work well in LAN environment. However, you must work on the network all the time. For example, if you are editing a file and don’t want anyone else to change it till you have finished, you cannot work on a local copy. If you create a local copy and work on that, you lose the benefit of shared folders. Also, if two authors simultaneously edit a particular file, there is no way of merging the files.

Source Control

Source Control repositories enable all the benefits of file sharing, with an ability to work on a local copy of the file, while the file remains “checked-out” from the repository. Source Control systems also allow the ability for multiple authors to simultaneously work on a particular file and merge back the changes made in each version. Version management, access over a network (outside the LAN), access control, file sharing etc are features which are normally available as part of source control systems. In the case of RoboHelp, RoboSourceControl is integrated inside the application, which makes the workflow seamless. RoboSourceControl also has advanced version management capabilities, for example, comparing different versions – view changes, merging two versions of the same file, labeling different versions and rolling back to a previous version. Installation of source control system is relatively easy (it took me about 15 minutes to install, configure and run RoboSourceControl).

Content Management Systems (CMS)

Content Management Systems add advanced workflow management capabilities, searching the repository for related content, and have a mechanism to alert team members about the status of the project. Even though, RoboSourceControl also has e-mail alert capability, this feature is usually not part of source control systems. Content management systems are usually installed and maintained by IS systems and may require consulting support for installation and training. Often, companies opt for an enterprise-wide installation of a content management system.

It would be useful to know your views on the best way of collaboration and what is that you are most comfortable with.

adobe

adobe

Posts from multiple members of the Adobe TechComm team.

3 thoughts to “Team Authoring”

  1. Hello, over the past 3 years for xml editing reasons many usrs of our cust. doc. dept. changed to another product, as xml was not implemented in the complete detail inside FM in the past. I personally think if FM 7.x would jump back to Mac on OSX all the depts. and companies using xml and design software will jump back to FM. Regards,Manfred

  2. Currently using source control (SVN and Tortoise) and it works a charm (we only use FrameMaker here though, and publish to JavaHelp through WebWorks).I’ve also worked in a Documentum environment (CMS) and that was more limiting, purely because of the overhead of the CMS client (the actual working practise was the same as a source control system – check out, edit, check in).However, in the past, the traditional authoring environment is typically small, shared by small numbers of users and generally X person works on X product/chapter/book. Few conflicts arise in those situations and they do tend to make source control systems look a tad ‘overkill’.Of course that presumes you store your working files on a network which is backed up! But that’s a different story… Gordon, thanks for sharing your perspective – Vivek

  3. Wikis are great if you can promote them enough to use by several people. Theres a need for technical documentation to have good screenshots and images, and also it would help if actual writers can work in the wiki. Wiki’s are still underused in this area and I think it’s just making it motivating to use, easy, fun, good version control, easy image inclusion. How will you rate Wikis in terms of ease of use? Will end-users prefer a mechanism in which they can work on local files and a separate application takes care of synchronization with the repository (check-in, check-out). – Vivek

Leave a Reply

Your email address will not be published. Required fields are marked *