Information Management News
A monthly e-newsletter from The Center for Information-Development Management (CIDM)
If you would like to receive the CIDM e-newsletter in plain-text format, visit http://www.infomanagementcenter.com/subscribe.htm and choose the plain-text format.
Information-Development Purchasing Guide: CMS Buyers Guide
In an eight article series for the e-newsletter, CIDM will be discussing buying tips for typical services and products that you, as an information developer, might be interested in buying.
This is the fifth in our e-newsletter series of purchasing guides for purchasing information-development products and services. In this issue we look at content management systems.
Content Management Systems (CMSs) are databases designed to store and manage content that includes documents of all types, as well as images, audio, and other media. In most cases, various types of CMSs are specifically designed to handle particular types of content better than others. For example, you will find CMSs designed for website content, corporate records, proposal content, training material, archives, and entire comprehensive documents. For this purchasing guide, however, the focus is on CMSs that are specifically designed to assist technical information developers in managing content that supports technical products and services. These CMSs are referred to as “component” content management systems because they are especially designed to handle many small pieces of content effectively. You should be particularly interested in CMSs that are designed to handle structured content that has been developed using XML, SGML, or related content markup systems.
Engineers hold the key to much of the information that our groups document; yet, few of us tech pubs folks know how to work well with them. Even in the best of circumstances, the relationship between engineers and doc groups can be tricky. Writers are more than their scribes; engineers are more than our “subject matter experts” (SMEs). We depend on them and — much as they might not like to admit it — they depend on our documentation.
So let’s look at a few ways we can all work more productively with engineers — and vice-versa. Surely our customers would appreciate the fruits of our improved communication.
If only content management systems came with “how-to” manuals for content analysis and conversion. When on the brink of a move from an unstructured writing environment to DITA and a CMS, we sure could have used one. So, what’d we do instead? We panicked a little, and then we dove in, learning from our mistakes and working together to develop processes and guidelines.
For our pilot project, we chose to tackle most of our end-user content. How did we survive the content analysis and conversion of this content? Two key things immediately come to mind: we determined early on what we wanted to accomplish during content analysis, and we worked collaboratively to solve problems and discuss possibilities.