Newsletter of the Society for Technical Communication, San Francisco Chapter
August/September 2010
| Newsletter of the Society for Technical Communication, San Francisco Chapter August/September 2010 |
Paul Zimmerman talked about the next paradigm shift in technical writing -- collaboration and communities. He pointed out that the expectation of customers drives the need to make content more collaborative, and the availability of new tools, from PDF commenting to Web 2.0 tools such as wikis enable the move. More than ever, customer relationships are key to customer retention.
The evolution of content can be described as going from one way communication (print and static web sites) to collaboration (enabled by tools like wikis and distributed workspaces) to communities organized around content, where the same person can play the role of consumer and creator. Paul suggested that the landscape can be captured in three Cs and three Ws:
Paul pointed out that not all content should necessarily be made collaborative. Some content may need to be fixed due to regulatory, contractual, or other legal reasons. However, some types of content may not be well-suited for collaborative environments. Paul's team found that command reference, release notes, and installation information were best kept static. Deliverables that benefited from a collaborative environment included design guides, training aides, quick-reference material, examples, and configuration information.
An engagement strategy is key:
Different levels of collaboration exist, each with their strengths and challenges.
Forums allow a community to discuss topics and hear from experts. They are easily and quickly created, but can be difficult to organize. Enabling comments on content created by the technical documentation team ties customer feedback to the content, but doesn't allow the community to change or create new content. In a truly collaborative model, any member of the community can add or change content. This requires much more governance and moderation (curation) to keep the content valid and useful.
Paul suggests that when choosing a collaboration model for a set of content, you consider whether you want a content-centric model (for example, Wikipedia) or a contributor-centric model (VMWare community and Intel OpenPort community are two examples).
You can start with a small pilot to test the waters. Choose a collaboration model, a set of content, and don't forget to advertise! Plan for the changing role of your team. Although most of the content is still originally authored by technical writers, they will be responsible for monitoring and moderating new content. Writers have most of the skills required already -- they are familiar with the technology, they know who to ask when difficult questions arise, and they understand the importance of style and consistency in readability. Writers become the facilitators or curators becuase they understand the content architecture and have a cross-organizational focus.
Rewards include giving the customer a bigger stake in the product, and delivering more content because of validated customer contributions. Additionally, global perspectives may surface as customers in remote locations contribute comments or content. The risks include building something that no one uses, an investment in governance and moderation (or a degradation of content quality). The whole issue of intellectual property and ownership can be distressing, because companies must open up traditional ownership boundaries in a collaborative environment.
Paul provided links to two types of collaborative projects: