YK: Chapter 22: Running a successful wiki

22 Running a successful wiki

So you’re planning your wiki, and you inevitably reach the question that almost everyone who creates a wiki asks: will anyone use this thing? It’s a question common, of course, to nearly every website, and more broadly to nearly every new venture in the world, whether it’s a company, product, or blog post. For wikis, though, it’s in a sense double the uncertainty, because you’re hoping your future users will not only read the content, but create it. Which is a classic chicken-and-egg problem: if there’s little or no real content at the beginning, then people won’t read it, but if you have no readers, then you can’t expect anyone to start contributing. Thankfully, the situation is not as bleak as that might sound. There are two basic kinds of wikis: public, general-use ones; and private wikis, for internal use by companies and organizations. To this, we’ll add one more group that’s somewhere between these two: public wikis for loosely-affiliated organizations, where the content is meant to be edited mainly by members of, or people connected to, that organization. For all three of these cases, the dynamics of having a successful wiki are surprisingly similar. Still, there are important differences between the three, so, after some general thoughts on wikis, we’ll discuss each case separately.

So, how do you convince people to start contributing to your wiki? This can be a challenge, even if, for the case of organizational wikis, contributing is now ostensibly part of their job. Most people have never edited a wiki. The situation today is of course different from 1995, when wikis were invented, or from 2001, when Wikipedia was created ­ many more people have experience editing wikis now, but compared to the overall population the number is still tiny. So, whatever set of people you want to contribute to your wiki, a sizable number of them, and most likely the vast majority, have never hit an "edit" tab before.

So you’re facing an uphill battle. On the other hand, you have to your advantage the same thing that has driven the success of every other wiki, which can be summarized as a basic human need to improve things, to bring what’s on the screen closer to complete accuracy. If people care about the subject matter, they will inherently want the wiki to be better.

Getting people to contribute to a wiki thus basically consists of two parts: finding people who care about the subject matter, and eliminating all of the obstacles that stand in the way of their natural inclination to improve things.

Finding people who care about the subject matter, or making sure that the relevant people in your organization care about it, is a challenge that depends on the type of wiki it is, so we’ll cover that in additional sections.

Removing obstacles, then, is what we’ll focus on. In our experience, the biggest thing that prevents people from editing content that they might naturally be inclined to is simply fear: people are afraid to edit wikis because they don’t want to do the wrong thing. An incorrect edit could mess up the display of the page, or cause more work for others, or even bring complaints against them at some future time.

That’s why the use of Semantic Forms (Chapter 17) is strongly recommended. Forms let people edit pages with much more confidence, and with a type of interface they’re used to already. We really believe forms are a "game-changer", as far as getting new users to contribute.

Even the combination of MediaWiki and Semantic Forms isn’t perfect, though: one big thing that’s missing is a reliable WYSIWYG editor for the "free text" of a page. Editing-wise, that’s the big advantage that some other wiki applications have over MediaWiki. The VisualEditor, a tool that’s already in use on Wikipedia, will hopefully be the fix for this problem, and by the end of 2014 there may be a solution in place. (See here.)

Besides forms, it helps to have clear instructions. The front page is especially important, for explaining the purpose of the wiki, linking to the major sections, and pointing to where users can add additional data.

There’s all sorts of other advice out there in books and websites for increasing wiki contributions, both in MediaWiki and otherwise. That advice includes contacting people after their first edit to the wiki (on their talk page, or, if the software doesn’t include talk pages, via email) to welcome them; creating contests to reward people for the most or best edits; creating merchandise, like stickers, to promote the wiki (which can in theory be done for private wikis as well as public ones); etc. Other than the first one, we’ve never seen these done for a wiki, so we can’t comment on how useful they are. But they all seem secondary compared to two things: having a clear rationale for why people should read and contribute to the wiki, and having an easy (and ideally form-based) way to edit the pages.

As to the first idea, though, of welcoming users with a message on their talk page: it’s a popular approach, done on Wikipedia along with many other wikis, but there’s some evidence to suggest that it’s not effective: a study by the Wikimedia Foundation, presented at the Wikimania 2011 conference, found that Wikipedia users who got a welcome message when they first signed up actually had a lower editing rate than those who did not. Did some users feel patronized by the welcome message? Or was this just statistical randomness? In any case, the evidence is inconclusive that personalized welcomes are helpful.

Now, let’s get to some specific tips for the different kinds of wikis.

Public wikis

The very successful public wikis tend to follow a standard model: other than the Wikimedia ones, plus wikiHow, WikiDoc and a few others, they tend to focus on pop culture themes. The average successful wiki focuses on (usually) one entertainment franchise and its manifestations in books, television, movies, video games etc., offering intricate detail that often can’t be found elsewhere. This is by far the easiest way to start a successful wiki: find a popular entertainment franchise (ideally cross-media, and ideally having to do with science fiction or fantasy), that doesn’t have a wiki for it yet, or at least doesn’t have one in your language, and create it. That is the basic business model of the (MediaWiki-based) wiki farm Wikia, and it is the reason why Wikia is by far the most popular wiki farm, and currently among the top 200 websites in the world.

Let’s say, though, that you have an idea for a wiki that doesn’t involve a pop culture topic. Say, for example, that you want to create a wiki all about yoga (at the moment, there doesn’t appear to be such a thing, though that could of course change). The idea would be to capture more detailed information than Wikipedia allows ­ information about all the aspects of yoga, plus all the notable teachers ­ and maybe even a full listing of every yoga venue in the world.

All the previous advice about creating user-friendly help text and the use of forms applies here. But beyond that, how can you get readers and editors?

Pre-seeding the wiki helps. Few people want to start editing a newly-empty wiki, because it seems like an endless task ahead. You can copy information from Wikipedia, since all its text is freely licensed for copying. But that’s a potentially risky step, because then you have what’s known as "forked" content. Any improvements to the Wikipedia article from that point on won’t be reflected in your wiki, so unless you think your wiki’s users will do a better job of uploading that content than Wikipedia’s users, this is a risky thing to do.

On the other hand, if you plan to have more detailed information than Wikipedia does on those topics ­ if you can point to specific information about, say, Hatha Yoga that the Wikipedia article about it doesn’t contain because it would have been too trivial for an encyclopedia ­ then copying over content seems like a fine starting approach.

And, for directory-style information like a listing of all yoga schools, there may be other sources that you can copy from; just make sure that you can copy and publish such information legally. If you’re planning to use templates for such wiki pages (and possibly Semantic Forms as well), the Data Transfer extension might be useful for doing the data import ­ see here.

In addition, of course, you can start manually adding in information yourself.

What about marketing the wiki? Mailing lists related to the topic are a good place to advertise the wiki; chances are that if you’re interested enough in a topic to create a wiki for it, you’re already part of one or more online communities for it.

Beyond that, there are all the usual communication and self-advertising channels of the 2010s. Various wikis have their own blogs, mailing lists, Twitter accounts, Facebook pages, etc.

Private wikis

To get usage on a private wiki, like an internal wiki for a company, is of course different from for a public, general-user wiki, but not as different as you might think. On a private wiki you have a captive user base, and users who in some cases may be required by a company directive to contribute to the wiki; so getting people to edit the wiki might seem to be easier. On the other hand, if users find the interface confusing, or decide they prefer their old way of communication (which may involve emailing Word and Excel files back and forth, or putting such files on a shared network drive), then the wiki may just die quickly. We’ve certainly heard of that happening, company directives or no.

The previous advice on making the wiki user-friendly definitely applies here. Beyond that, it may help to arrange meetings for staff, to give demonstrations of the technology and to let people try it for themselves in a context where they can ask questions and get help.

At heart, though, getting the users to switch to using the wiki in place of whatever they were using before is just an example of the strange alchemy required to get people to adopt a new technology. It could be that tactics like handing out prizes, distributing stickers to advertise the wiki, and the like are helpful; we’ve never seen them in use, so we don’t know.

Public, organizational wikis

Finally, there are the wikis that are public, but are specific to one organization: one example is a wiki meant to be used by the local chapters of a non-profit organization, and another is a wiki of documentation for the software produced by some company. Such wikis combine elements of both private and public wikis: like public wikis, the aim is to reach a large and distributed audience, but like with private wikis, people are using the wiki in furtherance of work-related goals, not as a goal in itself.

These sorts of public, organizational wikis might actually be the easiest to get readers and contributors for. That’s because there’s usually no alternative to it. For a standard public wiki, you’re competing against every other relevant data source on the web, including Wikipedia. For a private wiki, you’re competing against the previous methods people used to store and collaborate on information, most likely including email. But for a distributed community that needs to exchange information, there’s likely no way to do it other than the centralized tool(s) that are given to people. So if a wiki is the available tool, and it’s clearly explained how they should use it, chances are that they’ll use it.

Still, setting up forms wouldn’t hurt.