Wikis: What, When, Why

What's a wiki? What makes them succeed? This post explores the mysteries of Web 2.0's Hawaiian son as applied to museums.

Wikis are websites that are extremely easy for anyone (even you!) to edit. The most well-known example is Wikipedia, a user-generated encyclopedia which boasts over 6 million entries written and edited by about 30,000 volunteer participants. While there are some criticisms of its consensus-based model for information-vetting, there's no doubt of its success as a collaborative knowledge-creation project. Wikipedia has become one of the top ten most-visited websites worldwide and is the only one in the top ten that is a non-profit initiative.

Wikipedia, like YouTube and Facebook, is a giant in the world of Web 2.0. Its success can distort understanding of what makes a wiki work. After all, if Wikipedia could succeed as a collaborative documentation of well, everything, isn't your specific wiki bound to thrive as well?

No.

Consider these two stories of museum-related wikis that struggled. In May of 2007, Woody Sobey released a wiki for science museum educators to share their demos. As the director of education at a small science museum, Woody thought it would be useful for his staff to share and have access to demos being offered by science museums all over the country. Ideally, the site would flourish, and any museum educator could log in to find great chemistry, physics, and biology demos to share with their own visitors.

Great idea, right? But from the beginning, WikiDemo suffered from a lack of participation. People went to check it out, but no one added their own demos. Woody had seeded the site with about 12 demos from his own museum, but the wiki never took off.

My second example is more personal and slightly embarrassing. This spring, I was a member of the advisory board for the New Media Consortium's 2008 Horizon Report on emerging technologies in museums. The convenors set up a lovely wiki and gave us specific instructions to answer research questions posed on a series of pages. On March 22, they released the wiki. In April, a few of us contributed to the wiki. And then on April 29, the conversation really got rolling... over email. We had 40 "emerging technology" professionals on the team, and we couldn't sufficiently self-motivate to do our work on the wiki instead of an antiquated email list. Our final task involved emailing a word document to the convenors. I don't know if that was their original plan or a reaction to our poor use of the wiki, but it certainly didn't reflect our supposed digital chops.

Do these examples mean you should never use wikis? Nope. But wikis are a very specific tool. They require more of their audience in terms of participation than other Web 2.0 sites and don't offer traditional rewards. The participatory "ask" is high--to create original content. Wikis don't explicitly acknowledge individuals with "profile power"--content is prioritized, not identity.

So when do wikis work?

Wikis work best in situations in which content, not socializing, is primary. They work when the individuals involved are motivated to assemble and co-create content. They are best-used in situations when a team of people is working together on something and needs a central place to document their efforts, or when a group of people come together to share lots of content in parallel and want to document it (i.e. a conference). The wiki has to be the best tool for the job. Otherwise, people won't contribute.

When is a wiki the best tool for the job? Here are two cases with related examples.

1. Wikis are great for documenting events with many parallel content tracks.

In August, I attended a one-day Freelance Camp in Santa Cruz. There were about 200 participants who self-organized 26 hour-long discussion sessions around a variety of topics. We used a wiki to document all of the sessions so that after the conference, participants (and people who weren't able to come) could access the notes from session they missed. The organizers set up the wiki and posted the schedule, and then told everyone that each session had to have a "scribe" who would keep the notes and post them on the wiki, linked from the schedule. It was an extremely easy way for multiple people to document parallel sessions and make them available to everyone.

Why did this wiki work? Because the ask was immediate and specific, and everyone saw the value of having notes from sessions they couldn't attend. After the conference, the wiki switched from being a participatory site to a useful record.

In a more museum-focused environment, check out the wiki for the Tate Handheld Conference held last week in London (for more on this event, check out this blog post by Nik Honeysett). While the wiki appears to have relied on a core leader instead of randomly selected scribes, the result is the same: documentation of a very interesting event, featuring keynote slideshows, resources cited, and discussion topics. Imagine if every major museum conference had a related wiki with volunteer scribes' notes from each session. It would be a great way to extend and memorialize the conference without putting undue burden on the convenors.

2. Wikis are useful when a distributed team is designing a project together or managing a changing set of projects.

This is the most basic reason to use a wiki. If you are writing a report with other people, creating the content directly on a wiki is much simpler than endlessly emailing around partial documents. Wikis allow you to create the content in discrete segments--pages--and then decide how to organize the content. For example, imagine you are creating a multi-chapter planning document. At the beginning, you can create pages for known components, like schedule, budget, etc. As time goes on, you can easily add new pages and then figure out in the end how to organize and prioritize all of the segmented content.

This ability to organize content segments, like moving post-its around on a table, makes wikis more useful than other collaborative document creation tools like Google Docs. Google docs is good if you are writing a single document or creating a single spreadsheet. But if you are initiating a larger, less defined project, a wiki can help you organize the content as it is generated in parallel by the team members. There are several museums that use wikis on a department-wide basis internally to keep up with projects going on on multiple tracks, share files, maintain staff and volunteer contact information, and generally coordinate work.

A great public example of a wiki-based project is WeAreMedia, a wiki with the goal of creating a "social media starter kit for non-profits." Funded by the Nonprofit Technology Network and led by Beth Kanter, WeAreMedia is similar to the Horizon Project in that it brings together professionals and asks them to share their expertise towards the creation of something greater for the field. Unlike the Horizon wiki, however, WeAreMedia is a bottom-up project that asks the participants to lead the design and conception of the individual modules. That goal means that a wiki is useful, because participants can contribute segmented content and then work with facilitators to decide how to organize it.

For the Horizon Project, we were asked to use the wiki to answer questions. And while a wiki is useful for answering questions, it was not sufficiently MORE useful for the advisory board than answering the questions via email. We wanted to have a discussion--and the wiki wasn't the right place to do it. WeAreMedia, however, is a wiki to create content for an overall project. There are other places on the Web (like Beth's blog) to have discussions about the content, but the wiki is specifically a place for putting it all together.


Ok, so now we know when to use wikis. But what makes them work well? Since wikis are about content, not socializing, you have to find ways to motivate people to participate. But that involves more than just getting them in the front door.

Here are three rules of thumb for "working wikily":

1. Wikis work when participants are invited in on familiar terms.

The entry point to wikis is steep. Sure, you can start slowly by just joining the wiki community, but in most cases, you have to actually write something on a public pag to be considered a participant. It can feel daunting to edit or add to something that someone else--especially someone else you admire--has created. And if it's not something you've done before, not part of your daily practice, you might want to avoid learning the technology, no matter how simple it is.

WeAreMedia has several entry points that attempt to make participation more comfortable. When you go to the site, you will see many ways to participate, on and off the wiki, along with the anticipated amount of time each contribution might take. I didn't want to add to the wiki directly on my first visit, but I did take their easy suggestions to join a swarm (2 min) and add a slideshow to their slideshare list (1 min). And I did these things without having to register as a member of the wiki.

2. Wikis work when they draw content from a variety of locations.

The goal of a wiki is to aggregate content of interest. If you run a huge wiki, like Wikipedia, you don't have to worry about finding desired content and pulling it in--people think of Wikipedia as a go-to place. But if you are starting a wiki, it is the new kid on the block, and needs to be integrated into pre-existing conversations accordingly.

There are many ways to do this. You can do it physically at an in-person event like a conference. Think back on the WikiDemo example. Woody launched it with an email to the ASTC listserv--a good group to target for his content. But people who read a listserv aren't necessarily incentivized to contribute to the wiki. He had the right people, but not the right time. Imagine if he had instead launched the project at the ASTC conference, and had spent the conference walking around with a laptop, asking people to contribute a demo. There are sessions related to science shows at which he could have reached a hundred science demo performers with a right-time, right-place interest in sharing their demos.

For the WeAreMedia project, Beth has readymade online spaces in which she can do this same kind of targeted solicitation of content. One of the nice things about WeAreMedia is that Beth Kanter is blogging the experience of running the wiki, sharing her observations and experiments. This week, she wrote about the balance between participation on the "homebase" (the wiki) and "outposts" (blogs, twitter, discussion forums). As she puts it:

In facilitating this community discussion to get at the curriculum, I've used blog posts that point people to the wiki page, one-on-one emails to specific people who self-identify, tweets, FriendFeed NpTech Room posts, and a little on Facebook. I'm not trying to control where the conversation takes place - I want it to be as easy as possible for someone to make a contribution and if that happens off the wiki, that's okay. As the wiki gardener, I just need to be able to gather up these valuable nuggets of insights from nonprofit technology professionals, and add them to the wiki curriculum or do some light editing of what's there.

Beth is a very active "wiki gardener," and she realizes that many valuable contributors are not necessarily compelled to go to the wiki and edit it themselves. So she reaches out to potential participants in a variety of ways and gets their content on the wiki in their own terms. My guess is that once you see your thoughts reflected on the wiki, as written by Beth, you feel affirmed and accepted as a participant, and thus more likely to contribute directly.

3. Wikis work when they are organized in a way appropriate for their content type and volume.

This sounds obvious, but it's not as easy as it sounds. Think of how Wikipedia works. There's one primary way to navigate to pages: the search bar. Since Wikipedia has so much content, that's fine--you don't need an outline of the articles to find what you want. You want to search, find, and go. But most wikis don't have enough content that a search bar is sufficient to find the points of interest within. The wiki from the Tate Handheld conference does a great job addressing this by listing every topic on the right sidebar for easy navigation. The Freelance Camp, however, is lousy at this. You have to know to start from the conference schedule to go to each individual session page, and you have to use the BACK button to navigate to other sessions.


What project or event would you consider coordinating and documenting via wiki? What wiki questions and tips do you have to share with others?