Skip to main content

Fredrickson Communications

Josh Welsh

Josh Welsh has a variety of experiences writing and editing scientific and technical documentation, and he also works on usability and user interface design projects for Fortune 500 companies and the public sector. Before joining Fredrickson Communications, Josh worked as a technical writer and a public radio reporter, and he has taught English to German high school students.

Josh is finishing an MS degree in scientific and technical communication at the University of Minnesota. His research interests lie in the nature of asynchronous, “low-structure” online collaboration. In his research, he asks questions such as, “How do contributors to wikis and open-source software projects work together?” and “How does the changing relationship between author and audience affect the work of technical communicators?”

References
  • Social Learning Technologies Matrix(.pdf) – A concise guide to social learning technologies and their applications.
    By John Wooden, Fredrickson Communications Director of Usability Services.
  • Glass, R. L. 2007. “What’s with this blog thing?” IEEE Software. 24(5), 104-103.
  • Leadbeater, Charles. 2008. We-think. London: Profile.
  • Weber, Steven. 2004. The Success of Open Source. Cambridge, MA: Harvard University Press.

Firefox® is a registered trademark of the Mozilla Foundation. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

Crowds, Wisdom, and Work: Do’s and Don’ts for Documentation Through Online Collaboration

by Josh Welsh, Usability Analyst

Wikis and other online collaboration tools have been around for several years now. Wikipedia is the best-known example of a wiki, and its growth has been nothing short of tremendous. From the time it was launched in 2001 until 2007, Wikipedia grew by an astonishing 19 million percent. As wikis have grown on the World Wide Web, businesses have looked for ways to implement this tool at the enterprise level. Several of our clients use wikis for collaboration, as do my colleagues here at Fredrickson Communications.

But how can you cut through the hype and make the best possible use of this tool? Is it enough just to install wiki software on your intranet and tell your employees to start writing? Unfortunately, all of the benefits and challenges of enterprise-level mass collaboration have yet to be fully explored. However, based on research I’ve done at the University of Minnesota, I can offer early adopters of enterprise-level mass collaboration tools some do’s and don’ts when implementing these technologies in the workplace:

  • Don’t expect large numbers of collaborators to solve everything.
  • Do provide structure for your collaborators.
  • Do remember that the 80/20 rule still applies.

Don’t expect large numbers of collaborators to solve everything

I analyzed 50 random Wikipedia pages to see if there was a correlation between the number of editors that worked on an article and the article’s readability according to the Flesch Reading Ease scale. I was surprised to find almost no correlation between these two factors. On the organizational level, these two variables may not be significant, since readability can be judged in a number of ways and the organization may have a very limited set of potential contributors. However, the takeaway is clear: a large numbers of editors will not necessarily create consistent, readable documentation. If consistency is a goal, you’ll have to follow the tip below.

Do provide structure for your collaborators

In the popular mind, wiki collaboration is sometimes thought of as completely without structure. Anyone can make any change they wish, at any time, completely anonymously. This may leave readers of wikis asking themselves, “Do I really trust the writings of a wiki contributor, knowing absolutely nothing about his or her qualifications for instilling some semblance of expertise into a wiki?” (Glass, 2007)

However, successful open collaborations do not develop without structure. When people collaborate on a large scale using tools such as a wiki, they self-organize into certain roles, such as author, editor, tester, and user. Likewise, in successful large-scale open source programming projects, such as the development of the Linux kernel, the contributors organize themselves into roles and responsibilities. Some people work on bug fixes, approve those fixes and send them out for testing, and others make the final decision on when the fix is ready to be put into the next release. Still others work on the cutting edge, creating new features for future releases. Since you are not likely to have the critical mass required for this kind of self-organization, you need to help create this structure. Who will write? Who will edit? Who will review and approve? Who will maintain the resource over time?

Do remember that the 80/20 rule still applies

Finally, realize that work in open environments does not distribute itself evenly. Following the Pareto principle (the 80/20 rule), it’s likely that 80 percent of the work in an open collaboration project will be done by 20 percent of the people. Don’t expect that once you set up a wiki and establish a structure for your collaboration team, all of the team members will put forth the same amount of effort. The strength to truly open-source projects comes from their flexibility: team members contribute however much they want, whenever they want to do so. This may not be practical for the goals you have for your wiki, but ignoring the 80/20 rule won’t make it go away.

Conclusion

Online collaboration does promise a great deal. And it has a proven track record, as evidenced by the success of open-source software projects such as the Firefox® web browser and the Linux® operating system. But to make the most of it, organizations need to remember that it is not a panacea. You’ll still need to provide structure and leadership for it to work to its fullest potential.

In part two of this article, we’ll take a look at some specific best practices that have been proven by the success of the open-source software movement:

• Make it interesting.
• Make it meaningful.
• Make it transparent.

This site occasionally provides links to websites operated by other parties. These links are provided for your convenience only. The presence of a link does not imply any endorsement of the material on the websites or any association with the website's operators. We do not operate, control, or endorse any information, products, or services provided by third parties through the Internet. We are not responsible for the content and performance of these sites. Use of linked sites is strictly at your own risk including any risks associated with destructive viruses.