The ups and downs of MediaWiki

By September 27, 2010 March 22nd, 2016 General

mediawikiWikis are great tools for collaborating on ideas and storing information. But I’ve found that Wikis can create as many problems as they solve. Much of my experience has been with MediaWiki so here are some things you may want to consider when investigating if MediaWiki is right for you.

Usage: many companies use Wiki’s to host their documentation. The upside is that most Wikis are free, and all employees can maintain them using their web browser; no software to install, no license seats to worry about. However, I’ve found you must assign a gate keeper to watch over the content, otherwise you will end up with duplicate or out of date information. These issues occur because many employees don’t have the time to understand what content already exists on the Wiki or to keep it up to date.

In terms of presentation, the Wiki can be customized to a fair extent if you have access to a skilled PHP programmer. On one of the Wiki’s I’ve used in the past, we had it customized to look similar to Microsoft’s MSDN style of documentation, with an expandable treeview on the left, complete with different icons for books, articles or both. The downside is that every time we added or removed a page, we would have to remember to update the TOC. Plus, locating the TOC page to update wasn’t always obvious and editing it required cryptic text entries which were error-prone to fill in.

Partitioning and searching: Behind the scenes, Wikipedia content is stored in a database and then rendered on the fly using HTML. This means there is no physical partitioning of information although you can logically partition articles by namespace, which is basically a way to categorize them by name. This lack of partitioning becomes an issue when users search for keywords, because the Wiki will simply return all articles from all namespaces which match the search criteria. For example, if you have namespaces for Product A and for Product B, users searching for information on Product A might also get information for Product B. This can create confusion for users especially if Product B is a replacement for Product A. Another nasty situation is when you have another namespace dedicated to hosting design ideas for Product A because these pages will also show up in the search results and can appear to users as actual product documentation.

While users can filter by namespace when searching, the Wiki’s UI doesn’t make this obvious and many users don’t understand namespaces. And if you have dozens of namespaces, it’s not very user friendly to have to click on each and every namespace to filter. I suppose one work around would be to have separate Wiki’s for different products; I’d love to hear what others have done.

Content management: Wikipedia only stores the text and image files. What I really want is to be able to store other content like Word documents and embedded videos. If this is the level of publishing you are after, you may want to see if other Wikis can accommodate this or switch to a system like Madcap Flare which will manage your all of your content and output articles in a variety of formats.

One nice feature is that you can easily add hyperlinks between pages without writing cryptic HTML code. The downside is that when you move a page, you have to locate each link to that page and manually update it. Luckily Wikipedia tracks all pages containing links to the page you want to move. But you have to have the discipline to record all of those pages before moving the content, and then go back and manually update the links after the move. And if there are hundreds of links to update, you could be there a while. Again, a dedicated documentation system would handle this for you automatically.

There are lots of other areas where the benefits of a Wiki feature will also have some corresponding issue, but hopefully this gives you a bit of an idea of what to look for. I’ve found that generally the low “up front” costs of Wikipedia tend to show themselves as expenses on the backend, as more content is added and people start using the system for more purposes than it was originally intended for. As a quick and dirty collaboration tool it’s great, but I would be careful about using it as a documentation system. It can definitely work, but requires a close watch and lots of maintenance.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.