There’s no question: Wiki is officially a corporate buzzword… and as with most buzzwords, a lot of people will say they need one without understanding what makes a wiki a Wiki.

So… what makes a wiki a Wiki?

  • A Wiki is flat. As in, one great, bit massive folder with millions of things in it. This design is key to several other features/goals of a Wiki… but for now, suffice it to say, a Wiki is flat… no folders. Period. Folders break Wikis. If you want folders, subsites, or anything that deviates from a flat structure, you don’t want a wiki.
  • A Wiki creates pages. A LOT of pages. One could argue that the primary goal of a wiki is to create more wiki pages (to contain more knowledge). This means that anyone editing a wiki can create a link to a page… and wiki’s automatically attempt to create a page when someone browses to a page (presumably through a link) that doesn’t exist, a wiki will offer to create it and allow that person to edit it. So, anyone that can create a link to a page can create a page in the wiki.
  • A Wiki has one page per topic. There are never two topics/concept on a page, and there should never be more than one page per topic. When a wiki page is being edited a link is generally created to another page that focuses on the topic that is being linked, and it is (always?) within the same wiki. So, if I link to a topic that doesn’t exist, I’m going to be prompted to create it… even if it already exists in another wiki (see last bullet). There is a possibility of link/page/name collisions… for this, Wikipedia offers “Disambiguation”… which is really a fancy way of saying that the overlapping topic will have a landing page, and from that you must select the page that is more specific to the page’s focus on that term, and is named appropriately to match.
  • A Wiki has flat permissions. If I can see one page, I can see all of them. If I can edit a page, I can edit any of them. This is important for readers because clicking a link and being denied access can be frustrating. It’s important for authors/editors because if I can’t see that a page exists, I may unintentionally try to create it again. This ties into the fact that…
  • A Wiki should have only one version of the truth. This is related to the second bullet, but is also trying to say that if a page exists on a specific topic, there should only be one page on that topic because if there are 2 distinct pages on the topic, we have no way of knowing which of them is authoritative, and neither is likely to be providing complete information. (I have a friend that works on a wiki product that supports this capabilities… multiple views of the truth… and while I understand responding to business demand, there is a reasonable question about whether the business should be demanding it, and whether they’re trying to tighten a bolt with a hammer).
  • Finally, whenever possible, there should only be 1 Wiki. This is the most questionable… so lets say that there should be REALLY good justification for a separate wiki, or a completely distinct topical area, or a completely distinct security need. The real drivers for this are all of the reasons listed above, and the fact that although a wiki is great at linking to itself, it’s not so great at linking to other resources… and there’s a high likelihood that a page I create in this wiki is duplicating information in another wiki… which is bad.

What ties all of this together is a change in viewpoint: a wiki is a tool… but it is also an ecosystem of collaborative and open knowledge sharing… and just like any ecosystem, if one piece of it is changed, the rest of it must also fundamentally change, or it will die.

For example, creating multiple wikis means that the automatic linking will cause people editing pages in one wiki to unintentionally create pages that duplicate or present different content from that in another, more authoritative wiki… so it fails because people cannot find what they’re looking for and feel like they’re doing duplicate work. Or, if there are “two versions of the truth”, people may make good decisions using the information they can see, and yet must do rework to solve the problems that misalignment created.

Simply put, SharePoint Does Wiki. Period. No question. And it’s pretty darned good at it. But it can’t protect you from the business decisions you may make which decrease the value of the functionality offered. SharePoint will do what you tell it to… for better or worse… and you have to understand the technical, political, and sociological impacts that come with that decision.

IMPORTANT NOTE: In the SharePoint 2010 product, the “Collaboration Portal” template has been removed. This was the “biggest bang for the buck” starting point for an intranet-style deployment… but it was complex to brand and sometimes facilitated some not-so-great decision making. In 2010, the best option is the “Publishing Portal” template, which is easier to brand (as is the purpose of all publishing portals), and you can relatively easily build in all of the functionality that was previously available in the collaboration portal. What I would NOT recommend (and was the driver for this post) is the use of the “Enterprise Wiki” for an intranet homepage. The needs of the intranet are generally not a wiki… but fairly controlled presentation, approval processes, separation of roles, ease of content creation, page layouts, etc… these are not wiki elements… they’re web content management elements… and the two should not be confused. It would, however, be perfectly plausible to create an Enterprise Wiki at the root of the portal that anyone can edit together… and this is a strategy I would strongly support. :)