4. Curate the information. Darren Gibbons suggested designating a “Wiki Gardener” for your company wiki. The gardener performs the task of weeding, or editing content that others have provided. This might include fixing typos, adding tags, reorganizing lists into a logical order, or ensuring that all of the links on a page work. Wikipatterns also calls this job a “WikiGnome.” This type of job might typically fall to a technical editor or writer.

Successful wikis will also have the position that Wikipatterns calls a “Champion.” This person is extremely enthusiastic about the wiki project. If you did a pilot of your wiki, this person might have been one of the pilot team members. An outgoing advocate for the wiki will encourage others to use it as a resource, and might possibly convince them to actually participate by contributing edits or even new pages to the wiki.

A wiki curator should use the wiki engine’s functionality to see what changes have been made recently. Again, this is a job that might fall to a technical writer, possibly with the title of “Information Curator” or “Information Manager.” Technical writers are especially suited for monitoring wikis, since an experienced writer can reorganize existing information to make it more useful, and has the skills needed to spot inaccurate information and either remove it or correct it.

Ellis at the Cherryleaf Technical Authors Blog summed this point up nicely: “A wiki should be treated in many ways like a teenage party. If all you do is provide a space for people to entertain themselves and you then leave them to it, you shouldn’t be surprised to find that, when you come back, the place is in a terrible mess or everyone’s left.” Every wiki needs at least one chaperone.

5. Ensure you have enough people participating in the right roles. Jacob Nielson conducted a survey in 2006 to examine participation in online communities. He found that in a typical user community, 90% of the people are “lurkers” (that is, they only read and never participate in the conversation), 9% will make a small contribution, and 1% will make a large contribution. His observations of these communities are easily shifted to wiki communities. While 90% of wiki users will only read the posted information, 9% will make small changes to the content, and 1% will make a large contribution by starting new pages and articles.

He goes on to say that while you can’t increase participation in a community by brute force, you can equalize the participation levels. He suggests making it easy for a user to contribute to a page by offering a start-rating system: a user can mark a page with good, useful information with four stars. This star ranking system might also be used to promote users who contribute quality information. This is a more equitable way of rewarding participation than just volume. If only the number of edits is taken into account for a reward system, users who make tons of little edits will quickly drown out users who only write a handful of quality articles a month.

Wikis are incredibly powerful tools if they are managed correctly. Alan Porter wrote an excellent article last week describing the typical hurdles that need to be overcome in order to get your company’s wiki off the ground. When I talk to people about using wikis, the cultural barriers he mentions are the objections I hear most often. So perhaps the first step in getting a wiki up and running would be to make sure that your company’s culture is ready for a wiki.

Next up: social tagging and bookmarking! This was the topic that melted my brain the most, simply because of the sheer about of information I found. However, I think I’ve come up with a list the top five things you should think about before deploying social tagging and bookmarking.

1. Start off with the right software and structure for what you need. As with any project, you need to ask yourself the basic questions before you start: Who is the audience? Who will be participating? What are we trying to accomplish with this wiki?

Choosing the right software to run your wiki is very important. Do you want to use the wiki as a place for single-sourcing your documentation? Then choose a wiki engine that will let you export content. Did you want to incorporate DITA into your wiki? Make sure your wiki solution can handle that. Do you have users who are more comfortable using a WYSIWYG editor than using wiki markup? Try one of the wiki engines that has a WYSIWYG editor. In the March 2007 issue of ABA Banking Journal, their Webnotes column described how the international investment firm Dresdner Kleinwort Wasserstein (DrKW) began using an internal wiki in 2004. When they switched to a WYSIWYG editor in 2006, they saw a 30% jump in the number of active users of the wiki. By using the right tool, they helped maximize the number of users.

You should also ensure that your wiki engine lets users find information easily with a good search engine. Ellis at the Cherryleaf Technical Author’s Blog pointed this out in the post “Six reasons why your wiki isn’t working.” If users can’t find the information in the wiki, it’s useless.

2. Start with a small pilot group made up of the right kind of people. Having a pilot group make sense. They are the testers, and they’ll help get the ball rolling. Darren Gibbons from Thought Farmer posted a slideshow called “Six Steps to Enterprise Wiki Success” on Slideshare. His idea to choose “keeners” is a good one, since they will already have the mindset that it’s ok to write, edit and rewrite other people’s work in a wiki. Your pilot group should be comfortable with wikis and the technology. Darren also suggests getting at least one senior employee in the group to help get things started.

3. Populate the wiki with a framework and starter content, rather than just leaving it an intimidating blank slate. I know how much I hate that blank page with just a blinking cursor at the top. It’s the same on a wiki: don’t intimidate your users, get them started.

Wikipatterns has a few examples, or patterns, on this topic. One of its patterns is the Scaffold, providing templates for your users to hang their content on. This would be especially helpful if people fret over how something should be formatted (“Should I put the date or subject first??”). An antipattern, or warning sign, that they mention is EmptyPages: people creating new pages for content, but then not filling in the content. Maybe they forgot, or maybe they are just stuck. Putting a scaffold or starter information may make it easier for someone to populate the rest of the page with information.

My next post will complete my draft of best practices for wikis.

3. Allow comments. This is a big one. If you do not allow comments on your blog, then it’s not really a blog: it’s an announcement feed. If that’s all you need for the application you’ll be using it for (for example, if you’re just pushing out revision notes and aren’t interested in receiving feedback), then that’s fine. But not allowing comments removes the social aspect of “social media.”

Social media is a method of communication, yes, but in order for it to be social you need to include your readers. Which brings me to the fourth point:

4. Encourage feedback and respond to feedback. I suppose I could have lumped this in with #3, but I like having them separate. It’s easy to allow comments on a blog and then just ignore them completely. Again, that doesn’t foster communication.

Paul Boag wrote a great post called “10 Harsh Truths About Corporate Blogging” at Smashing Magazine. His point #4 is “You’re not ‘engaging’ anyone.” He emphasizes the word “dialogue,” adding:

…you should be encouraging users to contribute to your blog through comments and constructive criticism. It is a superb opportunity to get free feedback from your customers, something many organizations pay market researchers for. Part of the problem is that most corporate blogs offer nothing more than rehashed press releases.

This is also important for internal blogs. Depending on what the internal blog is used for, comments can provide a place for employees to give feedback on a project’s progress and offer ideas for problems that the blogger has posted about. They can also, by extension, make a department or company seem more open and transparent by allowing anyone to comment freely on a blog topic.

What about negative comments? Paul mentioned this as well, giving the example of Flickr. Flickr had been having some server issues, which disrupted service for some users. In their blog, Flickr acknowledged the problem and explained what they were going to do to fix it. Negative comments from users turned into a public relations opportunity for the company to show how responsive they could be.

5. Be useful. Perhaps I should roll this one in with point #1, find a focus for your blog. I’m not sure; part of me feels like this should be a distinct point.

Basically, after you’ve found your niche, make sure you’re posting information that would be useful to your readers. Don’t just try to sell your newest product to your readers (Paul’s point #8), and don’t just post press releases (Paul’s point #5). Tom Johnson has a great list of useful things you could use a software product blog for, all of which would be very useful for both the readers and the authors.

6. Post regularly. This is probably more important for a public-facing blog than for an internal one, but I think it’s good advice for any blog. Every single list I’ve looked at for “tips for new bloggers” included this one, so I’ll just point at Paul’s “10 Harsh Truths” post again, with his point #2: “Good corporate blogs requires a long term commitment.”

Regular posts will keep readers interested in your blog. Going a long time without a post can get you bumped from their RSS reader. I’ve experienced this myself with my other blog. Being busy with school, my posting schedule has sort of gone to hell. Sometimes I’ll go a month or two between posts. This directly affects my traffic: the more I post, the more traffic I get. The less I post, the less traffic I get, even from Google searches.

My next post will list my best practices for using and maintaining a wiki. I’ve found so much good stuff out there on wikis, it has taken me a while to whittle it down to a manageable amount.

1. Find a focus for your blog. Companies are much better at this than they used to be. I remember coming across supposedly business blogs that would be equal parts useful information (support information, updates, new products, etc) and extraneous information (for example, how the company picnic went last week). How much “fun” information you put into a blog will obviously depend on your audience, of course.

In the September/October 2006 issue of Intercom, Tom Johnson suggested that blog authors need to find their niche and stick to it (“Corporate Blogging and the Technical Writer”). Staying on-topic will attract readers to your blog, and will ensure that they stick around. I used to subscribe to a food safety blog that wrote about food safety issues, laws, research and news. It was a really interesting blog until they started obsessing over every single time someone was portrayed in the media touching food without washing their hands, or meat was shown cooking without a meat thermometer sticking out of it. After the fifth post about a celebrity shown eating at a burger joint and the blogger wondering if the staff had cooked the burger thoroughly, I unsubscribed and haven’t been back. They had wandered too far from their niche, and drove away a reader.

2. Be authentic, both to yourself and your readers. It’s so annoying when you come across a supposedly unbiased review site for a product, only to find out that the blogger works for the company that produced the product. This became even more important, especially for companies based in the United States, after the FTC developed new regulations for bloggers, requiring bloggers and tweeters to disclose any compensation they receive from a company for blogging about the company’s product. In her excellent book Conversation and Community: The Social Web for Documentation, Anne Gentle explains how trust is a vital component in any form of communication, and doubly so for social media.

Tom took this a step further in his blog post about corporate blogs, saying that the transparency should extend to revealing the author’s unique voice, and not burying it under layers of corporate vetting. He expanded on this in a later post titled “Seven Deadly Sins of Blogging: #1 Being Fake.”

(Tom has written a lot of excellent tips and other material for technical communicators who are seeking to start blogging for their companies. I am halfway through watching the presentation he did at the 2009 STC Summit on blogging. If you have the time, I recommend you check it out; I’ve enjoyed what I’ve seen so far.)

I don’t want to get into the habit of writing massive missives, since I know those aren’t fun to read! So my next post will continue my collected “best-of” best practices for corporate blogging.

A technical writer who posts a document to the intranet can add some tags that she thinks will make it easier for someone to find the document. Later, when other employees find the document they can add their own tags, which might be more intuitive to them. That’s the basic idea behind a folksonomy: groups of people collaboratively tagging and labeling content. There have been some questions as to whether the term “tagging” should be used synonymously with “folksonomy,” with a distinction being made between people mostly just tagging their own work (like on Flickr) and people tagging the same resource with their own tags (like on Delicious). I agree with this: it’s hardly a work of the collaborative mind if you’re the only one tagging your photos!

In an enterprise situation, I can see how a free-for-all tagging system might give a technical writer the shakes. Cory Doctorow pointed out some examples of why metadata shouldn’t be trusted as a “fits everything” solution in his essay Metacrap. In “Folksonomies: Tidying up tags?“, Marieke Guy and Emma Tonkin have some tips on improving user-submitted tags, such as ensuring tags are spelled correctly and enforcing the use of plurals rather than singular words, for example.

The company where I did my summer co-op placement was just beginning to roll out a tagging system while I was there. To combat the problem of “bad tags,” they were going to use drop-downs instead of having a text box for tags. Tags would be chosen during an implementation phase, and these tags would be used to tag new documents. If users thought that a new tag was needed, they could apply to have the tag added to the system.

This seemed a bit complex for me. Sure, it solved the problem of having a tag stew on your intranet, but it also defeats (a bit) the purpose of having a folksonomy: people think in different ways. What I call “procedure” you might call “instruction.” What you call a “form” I might call an “application.” On the other hand, having the drop-down menus to chose tags from might make it easier to find things, rather than trying out words in the search engine and hoping I come back with a hit.

I personally lean towards having a free-for-all tagging system, even if it might require cleanup from time to time. Publishing a “Rules for Tagging” guide might help the situation, and I’d tag that with “tips,” “rules,” “guide,” “tags,” and “tagging.”

I’ve been using social media, in a variety of forms, since I first stumbled onto the Internet (or its precursor) in the early 1990s. I dialed into a local BBS using my parents’ TI-99. When I got into university I found MUDs and talkers, and eventually made my way onto USENET and IRC. (I freely admit that I first “met” my husband in an IRC chatroom in 1997.) As time went on, I started participating in more recognizable forms of modern social media: blogs, forums, topical networking sites like Ravelry, and on to Facebook, Twitter and Reddit.

When I started in the communications program here, there was an emphasis on social media, especially in the freelance marketing and public relations classes that we took. This made sense: these classes were all about knowing your audience, including how your audience got their information, how they communicated with their friends, how they decided what information to trust, and how to get your message to your audience in a way that ensured they would listen to you.

Social media has been enthusiastically embraced by the marketing, sales and public relations side of business. Businesses have really taken The Cluetrain Manifesto to heart. (The 10th anniversary edition of the Manifesto is now on Amazon, by the way.) But other departments, including publications, seem to be a bit slower in picking up these tools. “Everything works just fine the way it is; why change it?”

My worry about my project topic was that it wouldn’t be taken seriously, by either my instructors who had to approve the project, or by the industry representatives to whom I will eventually present my research. I was worried that it would be considered a fluff topic, not worthy of serious research. I was afraid that they would say, “Sure, you might be able to make a case for using social media in marketing… But what use would a technical writer have for it?”

I think that part of my worry stemmed from the fact that when people think of social media, they think of things like Facebook and Twitter… and then they don’t think much farther than that. People can’t think of a non-marketing use for Facebook or Twitter, and so dismiss social media completely as a business tool… Ignoring things like wikis, for example.

Business Week had an article in December about companies investing in social media and enterprise 2.0 software, decrying the “experts” and “consultants” who were selling nothing more than their opinions, and convincing companies to buy into social media before they were ready.

Yet the buzz around social media has led many companies to buy these systems before they’re ready to put them to work. Jennifer Okimoto, associate partner at IBM Global Business Services, says many corporations took the plunge into social media and now are sitting on loads of uninstalled software. “I’m working with a company that has made huge investments” in social software, she says on a phone call from Switzerland. Yet only a small number of employees at the company use it. A Forrester Research study shows that despite buzz around Enterprise 2.0, less than 15% of the knowledge workforce makes use of internal blogs, wikis, and other collaborative tools. “E-mail is still dominant,” says Ted Schadler, author of the report.

One of the things I’ll be focusing on in my presentation is knowing what your company wants to accomplish, and then making sure that your company chooses the right tool for the job. Saying “We need a wiki!” is fine, but unless you can articulate why you need a wiki, what you’ll be using it for, and how it will be implemented, you’re just going to end up disappointed in the results.

Mark Bradford wrote a great response to the Business Week article. (Of course, he’s also a “new media consultant,” so he is one of the people dissed by Business Week.) He said:

Let’s not confuse the use of Web 2.0 collaborating technologies within an enterprise to modern marketing.

Social media marketing tools are not one and the same as social media collaboration tools. There may be some overlap (for example, using a microblogging service like Twitter within a company or a department), but the distinction between the two types of uses needs to be made. I need to ensure that I made this distinction clear.

But my research on blogs feels a bit threadbare. Oh, sure, I have oodles of great information on using blogs for collaboration within a team, department or a company. Information on using blogs for documentation purposes is a bit sparse, though.

Anne Gentle pointed out that she often sees blogs used as places to post release notes. That makes a lot of sense, since you can subscribe to the feed. I’ve seen that myself with my Asus netbook. I can subscribe to receive just information on updates relating specifically to my model and version.

Blogs are very useful for the RSS feeds, letting a customer subscribe to the feeds that interest him or her. But why use a blog if you’re just releasing notes? The Asus feed I get for my netbook cannot be commented on – there’s not much point. “Wow, thanks for the new BIOS update.” It’s informational only, and feedback would be unnecessary.

But look at LiveJournal. This is a blogging community that has been around since 1999, and it has a large and very involved user base. LiveJournal maintains a blog called LiveJournal Code Releases, which informs the community about changes that have been made to the site’s code and information about the site iteself. These posts generally garner about 20-40 responses each, but occasionally some tidbit of information (usually a promotion) will collect a much greater number of responses.

Another blog is LiveJournal ChangeLog, which is strictly information about changes to the site’s open source code. This blog does not get nearly the comment traffic that the Code Release does (since these changes might not make it to a release), although sometimes there’s quite the response. For example, look at this post in which a change was suggested to require users to enter a gender upon sign-up. Even though this was a beta change, the post received 148 comments, mostly from people who were against this change.

So much of the information I’ve found about blogs has had a heavy marketing or public relations basis, and I’ve had trouble finding much more about using blogs for documentation, especially from a public-facing perspective. I’ll need to think about this some more.

My name is Sarah Brannan, and I am a student in the Technical Communication program at Red River College in Winnipeg, Manitoba. This blog, “The Liner Notes,” is intended to be a companion diary/notebook to my graduate project. My graduate project is tentatively titled “Web 2.0 and the technical writer: Strategies for using social media to improve collaboration and the technical documentation process.”

That’s a mouthful! I’m hoping to massage the title into something that will roll off of the tongue more easily.

For my graduate project, I will be looking at how companies are using social media for internal collaboration and for communication with customers, and ways for companies to use social media to their advantage during the documentation process. You can read more about the nitty-gritty details of my research project (and more about me) on the About page.

I do some of my best thinking while I’m walking, but sometimes I have to put my ideas down in a concrete form to help me see connections between things. I am hoping to use this blog to help me find those connections, toss around ideas, and – hopefully! – to get feedback on my project. Please feel free to comment on anything that I write here, even if it’s to tell me that I’m completely wrong about something. If I didn’t want comments I would have just started an offline notebook.

Thanks for visiting my blog! I’m excited about my project and I hope you are, too.