This is a fabulous post and discussion by Tom Johnson and Mark Baker about the use of wikis. I’d almost call it “the good, the bad, and the ugly” of wiki usage. To paraphrase Tom’s paraphrase of Mark…:

  • “[Wikis] eliminate the distinction between reader and writer.”
  • “Readers prefer unblessed content that addresses their task and is available now over blessed content that does not cover their task or will not be available until next year.”
  • “People need gratification. If the content they contribute disappears into a black hole of moderation and curation, they don’t get the immediate gratification of seeing their work published.”
  • “The old contract between the writer and reader of technical content, that the published content had been vetted and could be relied upon uncritically, cannot be sustained in a crowd-sourced world.”

My comment on the post is as follows:

Mark / Tom – Thanks for this very informative post. I want to make a comment about community-based (crowdsourced) content versus traditional tech writer-to-reader content. As you point out, we often turn to the community to find information that the vendor has not provided for us. Unfortunately, this information is often operational or support information that we often desperately need to get a product working.

Scott Abel makes this point in his latest article in eContent Magazine:

http://www.econtentmag.com/Articles/Column/Flexing-Your-Content/Content-is-King-but-Context-is-What-Makes-it-Useful-78810.htm#.Tspm408qBJ8.facebook

In this article, Scott talks about looking for support information for his Canon all-in-one on the Canon website and not being able to find it. Instead, he finds exactly what he needs by Googling the problem and using the community.

In my humble opinion, manufacturers need to take heed of this trend. The fact that a great deal of the support/troubleshooting information is being crowdsourced and not controlled by the manufacturer can be problematic.

I think that companies can lose control of the brand and the message, if they are not at least monitoring the support boards for their product. It’s funny, on the one hand, I love getting real troubleshooting information from Joe User who has the same problem as me. On the other hand, I really do think it is the responsibility of the manufacturer to provide people with the troubleshooting information they need to use the product.

Of course, in addition to the brand, there is the entire accuracy factor. Shouldn’t the manufacturer being helping their customer (who presumably paid good money for their product) to get that product to operate properly?

One of the things Scott says and I also suggest is that manufacturers should be carefully listening to the community. They should be monitoring the crowdsourced boards, listening to what customers are saying. They need to know the actual terms people are using to search for and discuss their product. (I’m sure everyone knows Scott’s Yankee Candle story, so I won’t repeat it here.)

Finally, and this has nothing to do with the rest of my comment…I have seen a real difference between what I call internal user generated content and external user generated content. When wikis are used internally, you can get a lot of very interesting information all in one place. For example, engineering might start a topic and QA might chime in that things aren’t working the way engineering thinks they are, and so on. I think that promoting this type of exchange in an easy to use environment, such as a wiki, is a great use of collaborative tools.

Once we go to external user generated content, I think we are venturing into the “I don’t really know if this is accurate world.” In that case, lather, rinse, repeat and see the start of my comment. Thanks again for the discussion!

Join the discussion here.

In my last post on wikis, Mark Baker added an astute comment:

I’m not a wiki fan myself — I’m a structured text guy bred in the bone — but I am fascinated by the trend, and by the variety reactions to it.”

Via idratherbewriting.com

Val Swisher
Latest posts by Val Swisher (see all)