Why A Wiki?

Going to do a couple of articles around the technology of this site because, well, I can. And because it might be useful for people looking to set up their own projects.

This one is called, “Why a Wiki?”

A good friend of mine asked me what the benefits of including a wiki on a site already running a content management site was. I’ve discussed this briefly in my post about why open source is amazing, but I think it deserves a special rundown to understand what a wiki brings to the table that a standard content management system doesn’t.

Technology

The technology being discussed here is being referred to as a “wiki”. On the Unified Republic of Stars, I used the MediaWiki software that powers such sites as Wikipedia among others but practically everything that I will discuss applies to the myriad of wiki packages available for nearly every software platform imaginable.

In brief, a wiki is (according to Wikipedia):

Ward Cunningham, the developer of the first wiki software, WikiWikiWeb, originally described it as “the simplest online database that could possibly work.”

And that’s a pretty good description I think.

Features

As I said above, most of the features of any wiki package are shared, so while different packages may refer to them in different ways, chances are everything here can be found there to, if even under a different name.

The main feature of a wiki that content producers should be aware of is the ability to create links to content that doesn’t yet exist and track the number of links to what will be a content page in the future. This can be seen most clearly in the “Wanted Pages” list generated by the wiki.

Additionally, it tracks the number of links to pages that already exist, as well as to categories, files, and a myriad of other reports.

Beyond this, through simple tagging, a wiki gives the ability to categorize pages onto an auto-generated category listings.

Lastly, like many content management systems, wiki software also has the ability to track edits to content by user as well as a full user management system. This allows editors to rollback content based on edit or user and block some users entirely.

Benefits

So what does all of this mean to you? Why a wiki over a more traditional post-based content management system?

In the end, I believe it entirely boils down to the link tracking features. Without any input from users or editors, a wiki displays links that exist and highlights those that don’t, allowing those who follow the latter with the proper permissions to begin editing immediately from the same screen they were just reading on while alerting those that don’t that there is no page while not returning a 404 error.

Once the article is finished and saved, all the links to that content will show as valid on the wiki, ensuring that link integrity is maintained regardless of who created the linking posts.

This can further be expanded upon if there are dozens of articles linking to a similarly named article. If the intent was to link to the article that was completed, then the article that was linked to can be turned into a “redirect” with a simple piece of markup to direct those dozens of links to the content that was just written in a second.

This is reflected in the “What Links Here” link included with every article, so that editors and readers can see what links to a particular place. Take the entry for the Universal United Human Authority on this wiki. Links are driven to the page by the redirects “UUHA”, “United Nations”, and “Earth” to the one article. And all of this is invisible to the reader.

On top of link integrity, these reports can help drive what content should be written next on the wiki. After all, why do an entry that one page might link to when an entry can be done that over one hundred pages link to and clear all those red links in one go.

To compare these features against a publishing system like WordPress, also proudly used on this site and to be discussed in a later post, creating a link in a blog post to content that does not yet exist would result in a generic error message, otherwise known as a 404 “File Not Found”. No indication given to the reader that if they follow this link no content is waiting for them and WordPress doesn’t track the number of links made to various places, leaving creators and editors unsure of what content should be created next.

Which is not to say wiki’s don’t have their downsides, too.

Drawbacks

There are two major drawbacks to a wiki as a content management system as I see them. The first depends entirely on how a site owner intends their site to be used and the other is just in the nature of a wiki.

Wiki’s are designed to be open collaboration tools. As such, there is little difference between an anonymous user, a registered user, and an editor in terms of article creation and modification. While there are various configuration changes and extensions that can be added to address this, if the intent is to create a “top down” system where information is released to readers while restricting their ability to further edit it, a wiki may not be your cup of tea.

If a user has the ability to edit, then they can create as many pages as they can press “Save” for which, like all powers, can be used for evil as well as good.

Secondly, a wiki has no “unpublished” state, meaning even the most basic shell of an article is available for public consumption once it’s saved. On a wiki where content is entered piecemeal, this may result in a fair number of pages being incomplete or little more than placeholders. In the case of the latter, this makes using the “Wanted Pages” feature difficult as the page exists but is far from complete. (Fortunately, the creators of wiki software have also included a “Short Pages” tool to list the pages with the least content.)

Without the ability to hide incomplete articles, a wiki can frequently take on a much more “raw” state in which spelling errors, problems with formatting, and half-finished articles can be seen more than the typical blog software driven website.

Wrap Up

Like all software, a wiki is intended to solve a particular problem, in this case the cross linking of content and managing the links between those pieces of content.

If a site of potentially hundreds of articles that forward link to content that doesn’t yet exist isn’t what you need, then what you’re looking for is probably more of a traditional “publishing” model based content management system like WordPress, which I’ll discuss in a later (non-forward linked) article.

Comments