Recently, someone commended me on my ability to log into an application and update content without receiving any training. According to his email, I was one of the very few people who had figured out how to do this. In my response, I thanked him for his confidence but asserted that my skill wasn’t all that unique. That’s what separates technical writers from other writers, I stated. They’re the ones who can figure out any product that’s thrown at them, mainly because there are no instructions — they’re the ones that write the instructions in the first place.
In our profession, we’ve had to be extremely adaptable, and the resilience that makes us suitable for the writing tasks at hand also makes us suitable for the changes in methodology that have been thrown our way. First, we moved from typing and paste-up to entering content into a desktop publishing system, which required us to learn the basics of typographic principles and visual communication. We learned WordPerfect, Ventura Publisher, MS Word, FrameMaker, and all about SGML, which contained concepts much different from the typewriting methods we’d used for ages. We went from being technical writers — who dealt with only text — to technical communicators who had to understand how to lay out our pages, add screen shots, and sometimes do the technical illustrations, as well.
The next killer app — a term used to describe an application that dominates the competition or becomes industry standard — for technical communicators was the Web. When the Word Wide Web, as it was then known, took the world by storm, the way we did business drastically changed. Aside from the few cynical folks who predicted that online information was a fad, we embraced the new technology and upgraded our skills. We learned FrontPage and Dreamweaver, RoboHelp and WebWorks. We learned about HTML and hyperlinks, and learned to think about documentation in a non-linear way. We soon found that our skills were transferable to related media, a small leap from structuring books to Web sites, from document “field tests” to Web site “usability testing.”
Since the mid-1990s, we’ve spent some time learning new technologies, but mostly learned more about adapting our craft to the new media. The profession inhaled deeply and we became part of the expanded field of user experience. Savvy user-experience professionals can still recite the structures of user guides for hardware and software products, online Help, Web sites, product sheets, and white papers. They can also tell you when hybrid communications are more appropriate than traditional ones, and can adapt content for each medium. They have expanded their skills into the broader realm of usability, information architecture, and interaction design, tackling the ever-increasing complexity of content and its variations in a multitude of translations.
Now, the next killer app has struck. As the world “flattens,” (see The World is Flat, by journalist Thomas L. Friedman), and playing fields are leveled, companies that have survived despite mediocre to chaotic documentation processes, (hey, when was the last time your company encouraged investment in the technical documentation department? … I thought so), are scrambling to gain the types of efficiencies that will give them a competitive edge. That edge is being provided by content management. I’ll admit that many of the readers of this article will assert that they haven’t been stricken down … yet. And to them, I would say: Don’t look now, but that large shadowy figure behind you is rapidly gaining ground.
Content management (CM) is comprised of three separate concepts. First, it is a technology that consists of a database connected to a workflow engine, usually with some sort of XML editor on the front end in which the content is authored, and a publishing engine on the back end to generate the content in the template of choice. There are many types of content management systems (CMS), too many to go into in this article, but it’s important to distinguish between CMSs designed to handle technical documentation; CMSs designed to handle Web content, product information (such as catalogues), digital assets (such as photo libraries), and rich media (such as video clips); and document management systems that manage content once it’s been generated as documents.
Second, the concept of CM is a way of authoring, reviewing and approving, storing, retrieving, archiving, and publishing content from a single source. In its simplest form, a user logs into an XML editor, creates a topic — no need to worry about format; that gets applied later — and, upon clicking a Submit button, notifies a predetermined person that a new topic is available for review and approval. The reviewer approves the content, and it becomes available for use by whoever else has permission to use it. Pointers to the topics are placed in order of the table of contents that form a publication. When finished, the author chooses a template and the Generate function. The template is applied to the content, and all authorities are created: table of contents, index, cross-references, and so on. When a topic is updated in the database, any publication that uses that topic can be updated. No more searching for content chunks, latest versions, approved revisions, or the right graphic variant; the CMS allows writers to search, include, and exclude to numerous variations, including language variants mapped to the source language document.
It may sound complicated, but understand the concepts of creating online Help and you’re halfway to understanding CM principles. More importantly, you’ll understand why companies are flocking to the promises of CM. The ability to bring a product to market faster than the competitors, to increase accuracy of content, to reduce rote task time and increase intellect time, and reduce the cost of production are strong business drivers. Producing documentation with traditional methods in an increasingly fast-paced market often results in so much corporate pain that a CMS seems like an extra-strength pain killer with codeine.
Third, but not least, is CM as a profession. There are several distinct aspects of CM that require completely different skill sets: requirements analysis, content analysis and design, technology analysis, integration, and training. What does this mean for our profession? Well, in some ways, writers have come full circle, having to worry only about the content and letting the CM system worry about the formatting. But the types of content continue to grow, and the contributors to a CM system are content developers. Our skill sets continue to morph and grow, and we need to understand things like structured authoring, taxonomies, and content design. Of one thing I am confident: the professionals-formerly-known-as-technical-writers, no matter what title is attached, will figure out how to embrace and master the new technology, and use it to improve the user experience even more.
