Ever take a look at some slick wiki technology and think “Wow, that’s really cool…I want one”? I did, and the results (an internal wiki for the documentation department where I work) were…less than stellar. Here’s how you can avoid my mistakes.

I had been working on a continuing education SharePoint site for the department. There was a wiki webpart available in SharePoint, and I became intrigued. What better way to help department members increase their knowledge about the profession than by harnessing our collective brainpower and talents! We could create collaborative summaries of training we’d attended! The intern could create a “new hire” section! We could have a knowledge base! How cool!

Wiki Dos (and Don’ts)

I immediately set up the webpart, learned how to create and edit pages, and provided a training session for my coworkers. I gushed about the endless possibilities, and then sat back and waited for the quality content to roll in. It didn’t.

Where had I gone wrong? Through the power of hindsight—and the research I should have done before I launched the wiki—I’ve come up with a few guidelines to follow next time. Perhaps you’ll find them helpful, as well.

Start with a clear purpose (a.k.a. Avoid the “if you build it, they will come” fallacy)

If you get starry-eyed over a wiki and then try to come up with ways you could use it, adoption is likely to be weak, as was the case in our department. If, however, you have a genuine process inefficiency or lack of resource that a wiki could help solve, you have a much better chance of success.

This phenomenon is best described by Mark Shead. He defines two types of technology users. Members of the first group identify a problem and then seek a technology to resolve it. Members of the second group, on the other hand, start with a cool new technology and then look for a way to incorporate it into their lives. When members of the first group adopt a technology, they are more likely to stick to it. Members of the second group often abandon the technology after a short time.

Prove how the wiki can benefit users

To embrace a wiki, users must first see how it will benefit them. Provide examples of how their real-world work could be moved to a wiki, and show how it could result in more efficient processes.

Ease existing fears about the wiki

People unfamiliar with wikis may fear that a platform in which any person can edit or delete any page will be chaotic. They may feel concern that a wiki could easily devolve into a free-for-all.

In a company wiki, the accountability for contributions and edits is much higher than in a major public wiki like Wikipedia—no one could leave anonymous spam. And while a small company wiki would likely not have the system of checks that Wikipedia employs, most small wiki communities tend to be naturally self-regulating. Chaotic editing and questions of ownership tend to be non-issues.

Provide proper training

If members don’t understand the broad concept of a wiki or the specifics of creating pages and setting up links, they won’t use it. Be sure to train users on what a wiki is (its purpose and what it’s good for) as well as on the wiki tool itself (how to create pages and set up links).

Don’t make it a chore

Don’t force the wiki upon department members. A lack of posts or edits by a particular member does not necessarily mean that the member is not finding value in the wiki.

Nurture your wiki

A wiki needs care and attention. Having an official “administrator” could imply that content is being policed, but you should ensure that someone performs a few maintenance functions:

• Introduction of a loose organization or structure (perhaps in the form of a home page that links to broad categories).
• Periodic checks to ensure that all pages can be found easily through links to a main page.
• Periodic checks to weed out any spam or mean-spirited contributions.
• Acknowledgement of good ideas, sorting of feedback, and implementation of suggestions.

Use metadata

To keep your wiki well-organized and usable, incorporate metadata. Metadata allows users to sort by category to quickly find what they’re looking for. Many wiki programs allow you to require that metadata be selected and allow you to define your own metadata. Other possibilities for metadata include content stages (can indicate whether the page is new, developing, or complete) or audience tags (can indicate whether the page is primarily for management, administration, or developers).

Broadcast updates

A system that notifies members when information has been added or changed will remind users that the wiki exists, and it will help ensure that the content is current, correct, and relevant. Notifications could come in the form of an RSS feed, or they can be as simple as an email alert. Users may prefer to receive a daily or weekly digest of changes, rather than notifications about every single change.

Encourage participation

A good way to encourage participation in the wiki is to enlist the help of a select few. You may select the most well-respected and established veterans of the department, or the enthusiastic early adopters of each new gadget, or the department members most willing to share their opinions. Often these individuals can pave the way for the rest. Recruit them to help get the wiki started; the rest of the group may well be more willing to participate after ground has been broken.

Here’s what the Yahoo Pipes feed looks like at the moment.

Writer River Yahoo Pipes feed

It’s simple compared to other Yahoo Pipes feeds. Basically the pipe takes RSS feeds from as many sources as I add here, sorts the posts by the date published, filters out any duplicate titles, and then merges all the information into one RSS feed. Writer River then displays this RSS feed on its home page. When you subscribe to the Writer River RSS feed (or when you subscribe to Writer River’s email delivery or Twitter updates), you’re also subscribing to this same Yahoo Pipes feed.

I’m convinced that human-assisted aggregation and filtering, with the help of such tools as Yahoo Pipes, is the trend for managing the deluge of information online. Since everyone is an author, publishing on separate sites, RSS is the only way to keep up. And people are publishing like mad, pushing out about a million posts a day.

Post titles are often hit and miss in terms of quality, so some human filtering is necessary. We need people to pick and choose the good content from the poor. People are naturally doing this all the time. I’m just trying to leverage those efforts in an effortless way to pull all of this good information into one running feed. This is what Writer River is all about. It attempts to gather all of this worthwhile content and help you find better information more quickly. If enough people participate, the quality of content flowing through Writer River could easily surpass the quality of any print publication.

Here’s an example. I like UXMatters, but I missed the latest articles published on it because I have hundreds of feeds in my feedreader and I don’t sit there watching feeds all day. However, Alistair Christie saw an interesting UX Matters article by Mike Hughes and posted briefly about it in his What I’m Reading category. I saw it on Writer River because Alistair told me about his What I’m Reading feed, and I added it to the Yahoo Pipe that’s feeding Writer River. I checked out the article tonight and immediately felt it was a valuable post. Without this human filtering and aggregation, I would have missed the post.

Now imagine if not just one or two people submitted similar What I’m Reading or What I’m Bookmarking feeds to Writer River, but dozens, even 100 people. It would be like having 100 researchers scouring the Internet for you, looking for the best posts available.

Here’s a little more math. Let’s say on average, the 100 researchers post one article a day to their What I’m Reading feed — one article a day they feel is worthwhile. In one month, that would be 3,000 articles.

Now of course not everyone has the same interests and tastes as you, so let’s say that only about 10% of these “worthwhile” articles are actually interesting to you. That still means that in one month, you’ll have 300 worthwhile articles to read.

Compare that to static print publications like the Tech Comm Journal, Intercom, the Communicator, or other print publications, which only have about 10 articles per issue, and you begin to see how valuable and powerful human aggregated content can be. This is the rationale behind Writer River. We now need more people to add feeds to it.

The manual method of going to the Writer River site and publishing a link to your post is somewhat archaic. It takes time and is slow. It takes effort. But the RSS feed doesn’t take effort. It only asks that you share your what-I’m-reading RSS feed with the Yahoo Pipe (by sending it to me, so I can add it), and then you don’t ever have to return to the site again. Content will just flow through the feed, however you choose to subscribe to it.

It makes sense to somehow mark or tag or bookmark or post or share or tweet good content that you read, right? You want to hang on to that article somehow so that you can find it later. That’s the nature of reading. But for online content, you need a method for keeping track of it, because the World Wide Web is too deep and wide and slippery to find something again after letting it go.

For those people who don’t have a blog or Delicious account, or Identi.ca or some other way of posting or marking content, I recommend starting one. One of the easiest ways to keep track of your good reads is through a WordPress.com blog, which is free, requires no maintenance, and provides you with an easy-posting bookmarklet that allows you to quickly add a link in two clicks from any page you’re reading.

Let’s pull together these efforts. Rather than having everyone run in their own direction, which accomplishes little, let’s harness all these individual efforts (which people are already doing) and turn them into a massive collective effort that dwarfs anything one simple person can do alone. Send me your category-specific RSS feed or links page and we’ll build an information machine that churns out the best content of the web without requiring you to do much at all to find it.

Last week Google released Google Voice, a service that allows you to integrate all your phones into one number and includes a host of features, including voice mail, recording, conference calling, and other services.

To help users get started, Google Voice has a list of 20 short videos. Only the overview video contains animation. It’s certainly the video they’ve put the most work into, and it also functions as marketing collateral.

The other videos are fairly simple, with short looping background music, professional voice talent, and a read script. The defining quality is that each video is short, some as short as 25 seconds.

The videos aren’t integrated with the text help. So if you don’t feel like watching videos, you can’t easily read the same topic. Google Voice does have help text, but it’s on another page, only linked to from the videos with a tiny, hardly noticeable help link in the footer. It’s almost like one group produced text, another produced help, and they published them independently.

The video windows are small, under 500×500 pixels. The small video window allow you to easily move from one video to the next without losing your place in the site. If you click outside of the window, the window doesn’t automatically minimize, which is nice. You have to close the pop-up window to go back to the list of videos.

All the videos are pulled in from Youtube, so they’re shareable. After one video ends, you see a list of related videos, but the related videos aren’t other Google Voice videos. Instead they are other Google services. So the related videos somewhat fail if you’re trying to learn more about Google Voice.

You can’t comment on the videos, or upload your own, or do anything other than watch them. Unlike the Michael Pick videos on WordPress.tv, Google’s videos are somewhat boring. Except for the overview video, which contains an animated stick figure, they lack a sense of being cool. They feel a bit corporate.

Similar to the length of the videos, the help content is also short and to the point, but the help topics are too text-heavy, with almost no illustrations, diagrams, or screenshots. The pages are embedded on the web, and navigating the topics is somewhat tedious. A search field appears at the top of the help, but if you search for the word “videos,” nothing appears.

Glaringly absent is any printable manual. You can print a single page, but not a group of pages in a PDF manual format. Additionally, Google does not provide any kind of quick reference guide to get started.

You can’t comment below the help topics, but there is a forum. The forum allows you to be notified by email and see the most popular discussions. You can also read a Google Voice blog, but the blog, like the help and the videos, isn’t well integrated with the rest of the help materials. It somewhat lives on its own. Google’s blog also takes the backward position of disallowing comments and only allows linkbacks to the posts.

One interesting characteristic of Google Voice help is a lack of parallelism in the topics. Here’s a list of video topics:

• Call screening – Announce and screen callers
• Listen in – Listen before taking a call
• Block calls – Keep unwanted callers at bay
• SMS – Send, receive, and store SMS
• Place calls – Call US numbers for free
• Taking calls – Answer on any of your phones
• Phone routing – Phones ring based on who calls
• Forwarding phones – Add phones and decide which ring

The help topic titles are similarly unparallel. Usually help contains all verbs or nouns in a more parallel list.

My Analysis

Google puts a lot of effort in the overview video. That’s a smart move. When people want to learn about Google Voice, the overview video communicates the service in a catchy way, with more of Google’s branding. This video is probably watched thousands of times (a lot more than any other video), so it makes sense to go to the effort of including animation.

What I don’t like about Google’s help is the lack of integration between the video and help content. Not every topic deserves a video. Many times I’d rather read the help. And sometimes I’d rather watch a video. Separating the two formats so strongly is a poor usability move. The forum and blog also need to be more closely integrated with the other help materials.

Additionally, the lack of any printed manual makes me think Google has no single sourcing strategy. The help content is probably just written as regular text on each page. I would have appreciated the opportunity to print a quick reference guide or short manual, only because reading on the web is a nonlinear experience, and moving from one topic to another without any logical sequence can be tiring.

I also think Google chose the wrong voice for its videos. Google is playful, young, and irreverent. But the voice they chose is professional, corporate, scripted, and somewhat ordinary.

I’ve been thinking a lot about voice in videos. Professional voice talent is not necessarily engaging. It sounds professional, but a professional voice isn’t always what users want, even if it’s what they expect. Users want a voice that is friendly, engaging, conversational, and real. I wouldn’t even mind it to be a bit spontaneous.

In the past, I’ve recommended that beginning writers create documentation for any open-source project they can find, such as WordPress, Audacity, or projects on SourceForge.net. However, our organization now has about ten open source projects that would provide an ideal opportunity for entry-level writers to gain real experience in technical writing. These projects are located at https://tech.lds.org/wiki.

The open source projects are designed to allow members of the Church of Jesus Christ of Latter-day Saints (aka the Mormons) to participate in some of the technical projects of the Church. However, you don’t need to be Mormon to help out. In fact, not being Mormon may provide a more realistic technical writing experience, as you’ll be working in a world of terms possibly unfamiliar to you.

In contrast to other open source projects, working on the open source projects at the LDS Tech Wiki will allow you to interact with designers, testers, developers, and project managers. You won’t just be writing help documentation for a stagnant application coded long ago. Instead, you’ll be able to create real documentation for a handful of active, interesting projects that you can showcase to employers.

What kind of projects are available? Here’s a page where all the projects are listed. The projects include the following:

• EBuilder Application
• Church Historical Timeline
• Coda
• Bishopric Scheduler
• EBuilder Application
• Home Teaching / Visiting Teaching
• IPhone Scriptures Application
• Local Unit Website Project
• Mormon Channel iPhone Application
• Recreation Properties Application

You can include any help materials you write for these applications in your portfolio. Trust me that a strong portfolio can trump years of experience as a technical writer. I landed my first job as a technical writer because I had a strong portfolio, which didn’t even include any real technical writing projects. Imagine how persuasive your portfolio would be if you actually had several technical writing projects you could highlight and discuss.

If you’re interested in getting involved, complete the requirements for participation. And then contact Tom Welch, the director in charge of these open source projects. (Alternatively, let me know and I’ll point you in the right direction.)

If you’re interested in learning more about the organization managing all of these open source projects, see Mormon.org, listen to audio at Mormon Radio, watch videos on the Mormon Channel on Youtube, or check out the resources at lds.org.