Nothing I’ve presented in this series has been particularly earth-shattering. Wikis are just another Web-based tool out there for collecting and presenting information. Wikis are well-suited for some types of data, ill-suited for others, and there is a huge gray space in between.

Some examples of well-suited purposes are:

• Encyclopedias.
• Reference manuals.
• Infrastructure guides or references.
• Collaborative writing or other creative projects.

Some examples of ill-suited purposes are:

• Large databases with somewhat static or homogeneous formatted data.
• Content Management System (though it could work, just not ideal).
• Web log or blog.

With proper research and some time taken to think about your community and purpose, you may find that a Wiki fits the bill. Just keep in mind that it will become an on-going project requiring a fair amount of care, feeding and community cultivation. Be ready to dedicate the necessary time to get it off the ground.

The main advantage of a Wiki is that it is a free-form database.

The main disadvantage of a Wiki is that it is a free-form database.

Being a free-form database, a Wiki allows contributors to format their pages and create their content almost without limit to form. This is both a good thing and a bad thing at the same time.

Without the constraints of a traditional forms-based database, contributors can build pages which better suit the data which they are trying to present — especially if that data differs slightly from the “standard” presentation. For example, in a structured database that catalogs computing devices in an environment you may have it set up to catalog various types of devices such as printers, workstations and laptops. What happens, however, when you get an influx of new devices which don’t fall under those categories or have additional properties which cannot be captured under one of the existing categories (let’s say, a bunch of new iPhones)? Well, you need to spend some development time to create a brand new form for the new devices which accounts for their special attributes (like an extra field for the iPhone’s GSM SIM card number). In a Wiki, there is no development effort required. Because the Wiki is not constrained with forms and fields, the person entering the data can simply note the relevant attributes directly and immediately.

On the flip side, though, you do need to enforce some semblance of structure or else it will eventually become impossible to locate any data at all — even with a good search function. Extending the example above, consider ten different contributors documenting new devices. If each one places their notes in a different section in the Wiki there will be ten different places to check if you want information on the various devices. Even a good search engine will lead users astray if the information is scattered across the Wiki like this.

The solution is to enforce firm, but flexible style guides for organizing information. The style guides should only go as far as to tell where various types of information should be located within the Wiki and what information should be captured, but they should not dictate exactly how it is presented (unless the volume of information requires it). Templates for new pages can assist with ensuring the rough “outline” of the Wiki stays consistent, but still allow individual contributors to be flexible with how they present data.

Community enforcement of the style guides becomes important, too. You should encourage contributors to edit each others’ work when they notice that something isn’t in quite the right place. If there are any disagreements on where something should be placed, be sure to resolve those as a community so you can all agree to a standard.

Think of the Wiki as a very large reference manual with many writers contributing (because it is, really). When writing papers for college, you typically had to conform to a style guide such as the AP Stylebook or one of the MLA Handbooks. Similarly, professional writers are often issued a style manual particular to the publications or projects to which they will be contributing. Your Wiki style guide does not need to be as formal as those, but it does need to exist in some form or another to prevent (or at least minimize) total chaos.

Next time: Final Thoughts.

So, you’ve picked out a Wiki platrform, successfully beta-tested it with a small group of users and have rolled out your final production version. Unless you are an exceptional individual possessing an encyclopedic volume of knowledge which you can dump into the Wiki, you will need other people to help you.

Building that community, however, could prove to be the most difficult task. In a business environment, it is important to get management to buy in to the idea of building the Wiki, but it is most important to build a base of content contributors. Without that content, the Wiki will have no value at all.

In my experience, I found that the “old guard” was a very large obstacle to implementing a Wiki as a documentation system. Most people, by nature, are averse to change. Change requires them to learn a new way of doing what they already know how to do the old way. At first, they won’t be proficient at the new way so they will be strongly tempted to revert back to the old way. And they did. For quite some time, I felt I was the sole contributor to our Wiki.

It took an influx of new employees before the Wiki really came into its own at our company. These new employees were able to see both the old ways and the Wiki way in action. From that experience they were able to experience the virtues of recording and sharing information through the Wiki. Most of them enthusiastically adopted the Wiki as their preferred method for documenting their activities.

Did that leave the “old guard” behind? Yes, it did. That is a challenge we need to deal with going forward. Hopefully, building a critical mass of usable documentation within the Wiki itself will eventually bring them around. Eventually, they will have little choice left as the old methods become impossible to maintain and others start asking, “Why isn’t this information in the Wiki?”

Next time: The double edges of the Wiki blade.

OpenSourceCMS.com lists nine Open Source Wiki implementations. Three of them are based on ASP and six on PHP. That is by no means a comprehensive list, but OpenSourceCMS hosts live, working demos of each Wiki listed. A more comprehensive list (but without the live demos) is available from Wikipedia (which runs on MediaWiki).

Another technique for identifying which Wiki is best for you, is to think about the goal of your Wiki and look for existing Wikis which have a similar goal. A good way to find existing Wikis is to perform a Google search with the term wiki.

Between the two techniques listed above, you should now have a very short list of candidates. Now is the time to download and install a beta test of each one on your own server. Load it up with data similar to what you that which you will put in your production Wiki. If you can, get some actual users to help with this process and get their input on which Wiki they like best.

After all that, you should have it narrowed down enough to pick your final candidate for a production Wiki. Get it installed and running on your production server, then work on getting that Critical Mass needed to make it a success.

Next time: Building your Wiki community.

There are many well-known examples of Wikis in action. There is, therefore, little argument against Wikis presenting a viable, living document to any size community.

A quick Google search with the simple query wiki returns over 400 Million results as of this writing. Many of the results on the first few pages are long-standing Wiki-based sites.

From gigantic Wikis such as WikiPedia to small personal Wikis, this technology has been adopted and adapted by a wide variety of users. Because most Wikis are (and are built on top of) Free, Open Source Software technologies, they are not going to fade away any time soon.

Next Post: Which Wiki Works for You?

Why use a Wiki to document your IT infrastructure (or your clients’)? What are some of the Good Things about using a Wiki, and how can you amplify them to your advantage? What are some of the Bad Things inherent to using a Wiki and how can you tame or control them?

With this series of posts, I hope to help answer a few of the above questions, perhaps bring up (and answer) a few more questions, and recount my personal experiences using a Wiki to document IT infrastructure for my employers and clients over the past five or so years.

Keeping with my site’s informal theme, I’m not going to draw up an outline or try to structure this. Instead, I intend to think about these questions and tie them to some personal experience which illustrates them.

While my personal experience lies in documenting IT infrastructure, I hope the ideas I present here are general enough that you can apply them to your own experience.

Next post: The Wiki is here to stay!