Skip navigation

Monthly Archives: May 2009

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.

This meeting’s theme: Programming

Eclipse IDE presented by Dan Juliano

  • UI layer runs on top of SWT libraries, so it should be more responsive.
  • Engineered differently than most other IDEs
  • Fairly memory-intensive. Just launched, it took 135 MB of RAM on Dan’s demo system (an Intel Mac).
  • IBM has put a lot of support behind this project.
  • Primarily supports Java development, but there are versions and plugins for other languages.
  • Aptana is an online web dev environment that fits nicely with Eclipse.
  • Good code validation plugin which will validate various languages.
  • Standard IDE stuff like syntax highlighting.
  • Has a large undo feature that remembers every change made since you started the session and can revert to any point. That causes a lot of the memory usage.

Several random discussions took place at this point in the meeting.

Hudson ( presented by Dan Juliano

  • Billed as an “Extensible continuous integration engine”
  • Tons of plugins.
  • Dan exploring using this for automated scheduled jobs as a replacement for doing the same with cron.

Several members of the group adjourned to Hessen Haus for food and beverages.

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. 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.

My 4:20 Picture Of The Day project is now up to 35 posted photos. With captions. Yay!

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?