Building a Collective Brain with a Wiki

For the Want of a Training Manual

Cerebral lobes of human brain illustration

Sink or swim? Trial by fire? You may have used these expressions to describe seeing a new hire flail about because no one had the time to train him or her properly. Heck, you may have been that new hire on an occasion or two.

Oh, but for a training manual! It’s not just the new hire who needs one, however. A manual or three-ring binder of all the things we need to know or reference frequently to do our jobs would be ideal at every desk. But, hmm. … That would mean we need copies for everyone and someone needs to keep them up to date. Furthermore, our margin notes might be threatened one day by updated pages that don’t have those hard-won bits of knowledge scribbled in them. Or those sticky notes marking our most-used pages.

So, it seems that what we may really need is a collective brain. By “we,” of course, I mean all of us pitying the new hire and pitying ourselves when we don’t have the information we need at our fingertips.

Wiki as Collective Brain

Luckily, just the type of collective brain we need is available, and it’s open-source. … At least many of them are. Take a look at a comprehensive list of them at the “Comparison of wiki software” page on Wikipedia. Numerous wiki engines are available to serve users needing a powerful knowledge base in their organization, whether it be a be a business enterprise or a nonprofit.

Okay, I’ll admit: it’s not so much a collective brain as it is a collaborative one.

Wikipedia is the most visible example of a wiki. Wikipedia is not news to anyone. The free encyclopedia is editable by anyone with an Internet connection. The small staff and many volunteers help steward it’s bazillion articles and keep wiki vandalism out. Its success is evidenced by staggering statistics on its use. You have no doubt experienced its benefits first hand.

But there are many other wikis, and wikis in the workplace are another powerful, focused variety of wiki that solves real problems in common situations. These are not wikis that are open to the public. Instead, they are behind firewalls and have restricted access customized to the needs of the organization.

My workplace stands to benefit greatly from a collective brain wiki, so I proposed one based on the following wants and needs:

  • Central source (i.e. no multiple-copies with version-control problems)
  • Secure
  • Limited to internal use
  • Backed-up frequently and restored easily
  • Minimal cost
  • Accessible quickly and easily
  • Instantly available updates when content is changed or created
  • Editable with all previous versions of content archived
  • Detailed comparisons of previous article versions
  • Customizable levels of user access (protected pages, etc.)
  • Bookmarkable entries
  • Ease of collaboration

We decided to explore the possibilities. I chose to use MediaWiki, at least for a trial. It was free to use and experiment with, but it came with the drawback of not being true WYSIWYG. I installed MediaWiki with a little help from MAMP. We were up and running with a trial wiki shared by the department, and I entered a few articles from our collection of how-to documents on our server. Suddenly, a small collection of articles became more easily searchable and usable.

As I presented the wiki and my proposal, I could see glimmers of hope among my peers. The project caught on in surprising ways. One group found a use for the wiki beyond what I had anticipated. There’s nothing like a hands-on experimentation to make the light bulbs of innovation start going on.

The Problem with Wikitext

MediaWiki and many wikis suffer from a usability problem. Or perhaps I should call it a usability wet towel: “wikitext” or “wiki markup“. Although an editing toolbar makes adding the markup easy, there is a minimal vocabulary of code that the user needs to use and understand. Think of wiki markup as a super simplified version of HTML. To the new user, it can be a bit put-offish. Kind of like needing to dust off your high-school French to help you get by on your vacation to France. Only wikitext isn’t as much fun as a vacation to France. I dislike giving users even small hindrances when it can be avoided, and wiki markup can be avoided with some wiki engines that incorporate true WYSIWYG. I hope to delve into one of those soon.

Converting Word Documents

Most of the documents needing to populate the wiki were short, but with one of the longer documents, I chose to try a conversion tool. Not having access to a Windows computer, I was not able to try Word2MediaWikiPlus Macro (Windows Only). But I was able to use an OpenOffice alternative. Unfortunately, I needed to do a fair bit of cleanup for characters that did not convert properly.

Other conversion tools are discussed at these links:

Tables are perhaps the most difficult wikitext to work with for users unfamiliar with text markup. Online tools for converting Excel tables such as excel2wiki come in very handy in these instances.

The Power of Collaboration

Wikis exist for collaboration, and everyone typically has something to contribute. In our department, it is common that whoever has the knowledge of a topic or procedure is the person who writes the how-to document on that topic.

Now, in a wiki, once the article on that topic is written, it’s alive. Anyone has the ability to edit that topic. Anyone can add to it, and now with the functionality of the wiki, each of those changes is recorded and can be reviewed easily. Write away. Edit away. Make a mistake and revert away. A detailed history of all changes is kept by the wiki. That’s invaluable when trying to remember why a change in procedure was made and who made it.

While “collective brain” may be over-hyping just a bit, a wiki serving an organization and its members is a tremendous tool in making knowledge easily accessible.

Other Resources

 

Comments are closed.