By Nicky Bleiel, Senior Information Developer, ComponentOne

image“Convergence Technical Communication” (CTC) is technical communication that provides information in several forms, including Web 2.0 delivery mechanisms, to improve the user experience. Most of the content is generated by technical communicators; a portion by users.

Web 2.0 makes it possible to create additional deliverables that enhance the user experience several different ways. First, it engages the different learning styles of our audience. Second, it improves user satisfaction with your product by creating communities of practice that allow users to participate in the conversation. Finally, any feedback and suggestions obtained can be used to improve the core deliverable set.

CTC Traits

Multiple Deliverables that can include:

  • Traditional core documentation set: online Help, manuals, quick reference materials, training
  • Videos
  • Podcasts
  • Blogs (including microblogs such as Twitter)
  • Social networking sites (LinkedIn, Facebook, etc.)
  • Widgets/Gadgets

User Participation

  • Comments (to blogs, etc.)
  • Forums (questions/answers/suggestions)
  • Wikis (gathering best practices, etc.)

Continuous Publishing Model

  • Traditional content updates, plus social media (blogs, social networking sites, wikis) must be monitored and nurtured. New relevant material must be generated consistently.

Developing Web 2.0 deliverables provide opportunities to work with Training, Support, Marketing, and Product Management to use documentation in new and different ways. In addition to being a piece of your deliverable set, wikis, blogs, etc. can also promote your product and increase the search engine optimization (SEO) of your company — which are goals of Marketing and Product Management. Software demonstration videos and podcasts can be utilized by Training and Support to teach customers about the product.

Web 2.0 deliverables can also be used internally to manage projects and knowledge. Wikis are a great way to store information, gather feedback, and plan projects. Blogs can be used to distribute information throughout your company in an informal and compelling manner. Web 2.0 doesn’t always have to be customer facing.

Traditional vs. Web 2.0

The core deliverables set (which includes online Help, manuals, quick reference materials, etc.) is a very important piece of your documentation library, but there are some distinctions between these traditional deliverables and Web 2.0 efforts.

Characteristics of traditional deliverables:

  • Comprehensive
  • Controlled
  • Defined Organization/Structure
  • Taxonomy
  • Content has one author – One to Many

Characteristics of Web 2.0 deliverables:

  • Not Comprehensive
  • Not Controlled
  • Organic Organization/Structure
  • Folksonomy (user-generated taxonomy)
  • Content has many authors ― Many to Many ― “Crowdsourcing”

Some myths about Web 2.0

Myth 1: Users want to edit documentation.

Truth 1: Users want to join the conversation.

Myth 2: You must participate in all social media, or none of them.

Truth 2: You can’t deliver everything, nor is it necessary.

Myth 3: Social media grows organically.

Truth 3: Social media requires a plan, and constant nurturing.

Myth 4: A successful social networking effort will have 100% of users contributing content.

Truth 4: Everyone participates differently. Some write, some comment, some read – all contributions are valid. See the Social Profile tool on the Groundswell: Winning in a World Transformed by Social Technologies website for more information.

Wikis versus Blogs versus…

Since there are many different Web 2.0 deliverables (and most can be combined), it is important to choose the options that are right for your product. The important thing is to find out the best way to get your users involved in the community and participating in the conversation (whether posting ideas, commenting, or reading). A strategy is important, and you don’t have to do everything at once. Set a goal and then develop the right strategy to achieve it. For example, if you’d like to gather “best practices” for using your product, a wiki may be the ideal format. Wikis are easy to set up and easy for users to edit. However, you need to have a realistic scope — while a wiki is a great way to gather information, it is probably a bad idea to post your entire documentation set to a wiki and expect the user community to edit it for you.  That is unlikely because you are expecting users to take on a large project, rather than a small task. (The exception to this is documentation for open source products, but those communities work and grow differently than those for proprietary software products. See the FLOSS Manuals website for an example of open source documentation.)

Delivering information via podcast or video may be the ideal learning medium for some audiences. If so, gather the appropriate talent and produce the podcasts/videos. If you decide to do a product blog, create links to the podcasts and videos (also create links to these resources from your Help files).

If you decide to do a blog (they are a great place to discuss features informally), make sure to link “feature” posts to more detailed documentation. Also ensure that comments are enabled and that any good ideas are acknowledged.  (Useful information should be incorporated into your core deliverables.) Of course, opening the door for comments and contribution also opens the door for criticism and abuse. Your strategy also needs to address how you plan to handle this when it happens. It is possible to close comments, but keep in mind that the idea is to encourage conversation, so it is best to only do so in extreme cases. If you decide to screen forum posts and other forms of commenting before they go live (which is a good idea to keep spam posts off your site) you may not want to filter something out simply because it is negative. On the other hand, wikis have “soft security” — offensive material is easy to delete after the fact — so you can’t prescreen information. You can lock pages to prevent edits, but that violates the spirit of a wiki.

Creating and distributing widgets (sometimes called gadgets) that users can embed on their desktop, web page, or mobile device can be a great way to broadcast updates.  Adoption is an issue — the widget must be compelling enough that the majority of users will want to install it. For certain applications, a widget may be an ideal solution for internal use. For example, you could broadcast updates to sales and service people in the field using a widget. If you don’t have the resources to develop a widget, you may want to broadcast updates via the microblog site Twitter.

Ways to Leverage Web 2.0

Often, proprietary concerns can limit your full participation in Web 2.0. If that is not an issue, you can use some websites to simplify distributing and serving up content.

You can then embed any of these on your website, blog, etc. with the code provided by the website. Of course, if you have proprietary issues, you can still provide these deliverables, but need to host them locally and authenticate users. The system should be as user-friendly as possible.

Best Practices

There are four best practices for Convergence Technical Communication:

  • Analyze often
  • Know your audience
  • Keep up with trends
  • Tie Traditional/Web 2.0 efforts together

For core, traditional deliverables, leverage:

  • Single Sourcing
  • Continuous Publishing

For Web 2.0:

  • Encourage Communities of Practice
  • Explore non-documentation goals, such as SEO
  • Gather champions/product evangelists

Your ultimate goal is to give customers what they need, balance customer needs and company needs, and steer deliverables appropriately and continuously.

Technical Communicators have core deliverables – online Help, manuals, quick reference materials, training. Not all are always necessary for every project. Adding Web 2.0 to the mix adds to the list of possible deliverables, but the same principle applies – all are not necessary for every project. Analysis is key – know your product, your audience, and what the possibilities are. Then deliver.

Additional Resources




Podcast on Tom Johnson’s “I’d Rather Be Writing” blog Analyzing Your Users and Needs Before Creating the Help Deliverables”

Using Journalistic Principles to Improve User Assistance

About Nicky Bleiel

Nicky is a Senior Information Developer at ComponentOne. She has been a technical communicator for more than twelve years. She started her career writing books and producing them in hardcopy format, but she has since embraced online help and user assistance, Web design, single-sourcing, usability, e-learning, and knowledge management. She has experience writing for software products in a variety of industries; including media sales, industrial automation, simulation, and pharmacy.

She has given talks at the STC international, local, and regional levels, and has presented at other conferences (WritersUA and LavaCon) and local meetings as well. Topics have included various tools and technologies, user assistance design, single sourcing, and wikis for knowledge management. She has been published in conference proceedings and on the Web, as well as in STC’s Tieline and STC Pittsburgh’s Blue Pencil.