CMS or Version Control - which one for documentation?

Version control has been and is being used by 1000's of companies to manage their software design. Software programmers check out files from a server to their local client. They can then, make changes and update or check the files back into the server at any time, as long as the connection between the client and the server is available. The version control software keeps the change history. Version control is often used by the documentation department of small companies to track the changes in documents. So why would anyone need a Content Management System (CMS) to look after their documentation? I believe now that CMS tools are becoming more available and cost effective this questions is being seriously asked but the habits of the past are making it hard for us to justify the cost of the change.

In the 60's and earlier technical writing was a very narrow field, comprised mostly of defense and aerospace documentation content writers. It wasn't until the age of the personal digital computer and the explosion of software applications that the technical writer became an invaluable person in the design, distribution, and marketing of these new products. Before this age documents were paper based, stored in boxes. Design history was a function of process and procedure, tracked by a paper-driven system. Even as late as eleven years ago I can remember clearly the physical effort involved in updating a procedure or manual. It required:

• many trips to the active and archived document filing system
• the walking around of drafts for sign-off
• walking around beta for testing
• filing drafts
• archiving current documents to a physically different filing cabinet located in a different room
• holding a release meeting to have the traveler signed off by all officials
• filling the final released document to the active document location.

The process itself is not unlike what is used today, but we did not even have internal email so every question, response, check, and issue had to be physically walked from person to person.

As computer memory increased and word processing applications became more accessible the ability to store documents electronically became more feasible, but the systems that were available to the average company where for tracking the history of code changes. Using version control to track document changes was really a stop-gap solution with no alternative.

I don't know the exact history of CMS applications but I do remember witnessing the increase in hype amongst the technical writing community with respect to XML and CMS about 9 years ago. With the responsibility of a technical writer changing quickly, the hype was more of a plea for a solution to be able to organize, share, and search the increasingly growing size of paperless content. Content writers where now often responsible for coding (HTML, XHTML, XML, JavaScript, CSS, XSL), designing (print, web, help, training, blogs, FAQ's, knowledge base), doc management, graphics, web marketing, regulatory, usability, user validation, applications expertise and evaluation (Word, FrameMaker, WebWorks, RoboHelp, Flare, CMS software, bug reporting, version, screen capture, publishing, e-mail) and finally publishing.

And again I ask, "what is the value of a CMS to a company?"

Content is not code. Software code is written for a specific function, used in a specific location, in response to a specific action or inaction of the hardware, user interface, or the software itself. Content is the description of a concept or procedure that can be used in multiple ways to define a product or company. The design of software code cannot be changed without a consequence to the quality of the product. The content can be written in multiple ways to mean the same thing or sometimes written exactly the same to mean something completely different. The consequence of changing content may or may not affect the quality of a product. At best it is merely inconsistent.

Kevin Ballard of L-3 Communications says, "CMS allows authors to maintain unique names" as well as "maintain the [relationship of] links" between document files. I believe he is right and here is why. As the volume of the content increases, the location of specific wording becomes impossible to track and remember. Content reuse is only possible if the relationship between the new document and the current content is known.

File Relationships
In a version control system files are checked in to a files system designed to store code. The file is checked out to any location on a clients computer. In a CMS system the relationship of file system is maintained when files are checked out. This means that when ditamaps are created for XML files or images used in marketing are imported into a user manual, the relationship is the same on the authors computer as it is when it is checked in. The knowledge of where a file is stored is related to the file it is linked to, not the absolute file location.

Unique Names
Files saved to a version control system use specialized naming structures to meet coding standards. This nomenclature often makes it difficult to determine the actual content or purpose of the document.

Metadata
Another very important functions of a CMS is the ability to search for and find information using metadate. The term "information mining" is become very prevalent in this age of information. The more products and models, the more content that is created and the harder it becomes to find pertinent information. Text files and some word processing files can be easily searched but binary files like jpg, cdr, and quark files cannot.

In a CMS environment files can be categorized using metadate so that the information can be quickly grouped and located. For example, lets say we are a moderate sized medical device company that has 80 products on the market. Within those 80 products there are three target markets (hospitals, government, and personal use). How would you search for all products that can be sold to both the hospital and government market? Well if it was a Word document and you happen to put the target market in the document content then you will find those with a simple search using Windows Explorer, but what about marketing documents designed in Quark or Indesign, or jpg images, FAQ responses in XML, and HTML help topics?

Result
As the amount of content in a company grows over the years, the ability to find specific information becomes more difficult. Without a way to search content across an enterprise, information is lost and then re-written causing similar products in current release to have different wording. If technical documentation is explained differently in different documents there is a potential for misinterpretation, incorrect product use, product failure, product damage or worse, injury. If updated in one document but not in all locations this content resides the problem can continue to haunt the company. The location of all content must be known to ensure consistent, reliable documentation and guaranty the reliability and trustworthiness of a company. Companies are built on brand, brand is built on trust and trust is not implied or expected, it is earned.

The CMS system is a tool required for this information age. Without this type of tool there is little hope of finding our way through the mountains of information we create every day.

Converting to XML - Some Point-form Pros and Cons

I have recently converted some user documents from MS Word to XML for a medical device company with the intent that they would be looking at authoring their future end-user documentation (printed, embedded, and online) in XML. I want to share with you some of the triumphs and challenges we had met along the way.

Pros

• Reuse becomes so much easier - The same 15 steps to 'prep' a patient were used in four different manuals and all we had to do was point to the content. When a change got made in the one manual, it was automatically updated in the other three.

• Editing process is shorter - Chapters or pieces of chapters that are shared between the different models are only edited once reducing the cost for editing.

• Updating for global changes are a snap - when content like product name, revisions, corporate names, logos, styles, etc. are saved as separate XML files that are referenced instead of embedded they can be updated in one place and changed in all documents that point to it.

  Imagine how valuable your company becomes as a salable entity when the purchasing company can re-brand all documentation in less than a few minutes and then republish everything with the new corporate image.
  

• Consistency is easier to enforce - If you are using an editor that validates DITA it becomes easier to uphold standard in authoring. Authors that must validate their content are more likely to follow the standards set by DITA and validated by the software. Note - Most authors know there are ways to work around validation error that do not fit a standard, but it is usually more difficult then following the standard in the first place.

• OASIS and DITA bring down the costs of using XML - A few years ago I wouldn't even consider suggesting to my clients to tackle XML unless they just happen to have an expert on staff with nothing better to do then write XSL and play with the DITA Open Toolkit or invest upwards of $100k for a great publisher and editor.

  With the advances in DITA, the general acceptance of the standard, the specializations that are constantly being improved on, and the new tools hitting the market that are priced for the SMEs the benefits of implementing XML can often outweigh the costs and time it takes to embrace the technology.

• Future cost saving - Once you have your XLST developed, your authoring standards in place, the process for authoring and editing understood, etc. there are so many cost savings that can be realized over MS Word authoring that it makes all the Cons worth the effort.

  When the client said they wanted one manual that had only common content in it, created from the four vertical market manuals, we returned to our publisher, set the conditions to remove all product specific conditions, added a short description to the introduction to describe the manual and then published. This took a total of 11 minutes and we had a reasonable manual. Try to do that with four 170 page manuals in MS Word.
  

Cons

• Painful - No matter how prepared you are there is going to be some pain. There are new processes, now tools, and new ways of thinking that must be embraced not only by the person looking after or authoring the documentation but also by all the people in the company that will touch the content as it moves to publication.

  Half way through the project the DITA standard for chapter books was released with DITA 1.1 and we had to go through a software upgrade for our editor and publisher as well as a second review of the manual styles, a second quote for style customization, and issues that were associated with any release of new software.
  

  DITA is by no means a mature standard and there will be many interations that will cause pain.

• Editing in PDF format was slower - If the content is published to PDF then edited it is very similar to editing each manual separately. There is benefit to having the content edited directly at the XML level in a content management system so that changes can be tracked and accepted or rejected. The problem with this is the person editing must have the ability to edit XML code or have the tools to view XML in a WYSIWYG environment.

• Tools add to costs - Yes there are loads of free products out there and many are feature rich and easy to use but if you were thinking you would publish using DITA open source easily you might be in for a programing ride. I had a software engineer look at the implementation for DITA Open Toolkit and claim he had "flashbacks to his Unix coding days", where only the people closest to the program could use the application.

• XSLT coding required - The XML authoring is the easy part and if you have determined how you will publish your content, the publishing is quite painless as well, but the styling can be very complex and somewhat expensive if you decide that the DITA standard for style does not suit your branded corporate image.

• DITA standards don't apply to all - If you are like most good companies you have a brand and image to uphold. Until just recently (August 2007) DITA did not provide chapter numbering as a standard in book publications. There are other features that your company may require for publishing a book or help file that are not part of the DITA standards.