Peter Seale's weblog

I write about programming and don't take myself too seriously. Read my standard disclaimer. Follow me on Twitter at @pseale and be inspired.
Thursday, May 08, 2008 8:00:07 PM UTC #

UPDATE 2009-09-01: People Are Apparently Still Finding And (presumably) Reading This Outdated Article

First: I'm sorry. In the post below, I took a fun little journey comparing SharePoint's built-in wiki with MediaWiki. After some first-hand pain with wikis and reading the comments I received on the post, allow me to flip-flop my position and clearly state: SharePoint 2007's built-in wiki will impede any attempt to build a real wiki.

To put this statement in context, your main problems when deploying a real wiki will be to get critical mass. This means, you'll want to get hundreds or thousands (or tens) of individual contributors on your wiki. And you won't want them getting frustrated with the software. You don't want them trying to figure out the 4-step process to uploading an image; you don't want them attempting to build an HTML table (or anything really) using the source view; you don't want them to lose data when someone 'deletes' a page to the Recycle Bin and no one notices for 4 months. Preferably, you don't want them thinking about anything but 'how do I best contribute to this group knowledgebase?' And SharePoint will get in their way.

So, my new statement is: if you need MediaWiki, or something like MediaWiki, invest the time and effort to do so. Don't try to build on top of the minimalist SharePoint wiki. But…

But, with the most basic of needs, and given the assumption you already have SharePoint, and that Integrated Windows Authentication works for everybody, SharePoint is your best bet. Once you start doing 'fancy' things like adding images or attempting to go beyond the built-in WYSIWYG editor, you'll experience pain. Even with some pain, SharePoint's a good choice for small wikis. The original article (starting in the next section) lays out this argument in heavy detail.

Second: The new SharePoint will be out soon, invalidating whatever points I made in this article. Consider yourself on notice: this article is about the 2007 version, folks.

Third: I'm really trying to stop writing these "op-ed" pieces that really don't help anyone. I don't think I introduced any valuable concepts here, just pushed a lot of hot air into the atmosphere. How does this article (and those like it) help? They don't. So, I'll stop.

Final note: I've also flip-flopped on Wiki syntax. It's not that bad after all. WYSIWYG is much more important than markup. And while you're at it, everyone just copy PBWorks, because they have a sweet setup.

Original Introduction

A while back I came across this direct comparison of MediaWiki, the wiki engine powering Wikipedia, and SharePoint's built-in wikis.

As you might imagine, the comparison favored MediaWiki. And, as I left an embarrassingly passionate comment rebuttal (in which I link directly back to this address), I feel compelled to write the following post.

Summary first: because I meander quite a bit

The summary is: you probably don't need MediaWiki's extensive featureset for your corporate intranet. Assuming limited needs, SharePoint's wikis are a great, no-maintenance, small-learning curve solution to the "informal team wiki" problem. You can do better feature-wise, but why would you want to? Plus, you already have SharePoint—this is a no-brainer.

Well, let's get with the details.

Wiki syntax: unnecessary

So, let me start off by saying I hate wiki syntax. Actually I need to clarify: I hate any markup syntax built on top of HTML, and that includes MediaWiki's wiki syntax, the FlexWiki syntax I've used, whatever syntax ScrewTurn Wiki uses (it's different from FlexWiki), and the perennial favorite, [BBcode] markup. I hate all this for two reasons:

  1. It's annoying to learn a new syntax for bolding up a word when <strong></strong> works just fine in HTML thank you, and
  2. It's totally unnecessary.

We are now presented with the question: but Peter, what alternative do we have?

Just use HTML

Just use HTML! Allow me clarify in the next section:

You can parse the input and allow only a subset of HTML

I'm not saying to throw wide the gates and allow everything. It's perfectly reasonable to parse input and allow only specific markup, negating any and all security concerns! And when I say "parse", I don't mean some kind of abomination involving substring searches or even regex.

So if someone types: "Hey, I like to <strong>bold me up some text!</strong><script><!— some nasty js virus bomb —></script>", you know what? You can figure out which parts are legitimate and which parts are no-no! Don't just give up and say "oh forget it, let's just change the <b> to [b] and make our 1 billion users learn this new, inferior syntax." You know what? YOU CAN FIX IT, DON'T GIVE UP! 

It's possible; look into it—it's better than inventing Yet Another Markup Language. [[Insert your own awesome YAML joke here!! Ha ha, good one!]]*
* for the purposes of this bit, YAML stands for "Yet Another Markup Language"

Back to wikis

So with Peter's Fundamental Law #14 ("Don't invent yet another YAML") out of the way, let's get back to the comparison.

It's all about context

What are you looking for in a wiki—are you attempting to build "wikipedia for my global enterprise"? If so…I don't actually believe anyone's attempting to do this. Leave me a comment if you are, and if you have implemented MediaWiki in a corporate environment to accomplish this goal. There probably are people attempting to do this, which is fine. I haven't met them, but I'm sure they're out there. Maybe.

But I'm here today to tell you that most of you don't need MediaWiki. You may think you do, but if you actually go out and talk to some of your users, you'll find out: you don't. Your corporation is not filled with anonymous trolls—the trolls are still around, but [[insert your own boss joke here]]. Ow, my sides!

Anyway, MediaWiki is built to work with the semi-anonymous internet, and on a massive scale. You, on the other hand, have a grand total of 30 people in your enterprise who are clued into the fact that the mouse sitting on their desk has a right mouse button, and have a solid understanding of how a folder can contain other folders, and files. There's 30 of you.

The corporate intranet is not the same as the raw, unfiltered wilderness of crazy that is the internet.

What crazy world do you live in anyway

Let's just state this as a fact: your IT department does not have linux admins. Or if they do, they're hidden so well you may not recognize them. The point being: when you ask someone to install MediaWiki, you'll be asked: does this thing run on Server 2003, or does it require Server 2008? Um, gusty* gibbon or newer? That sort of answer will not register; please try again.

Oh, and while we're talking corporate IT politics, you may want to avoid using the words "Open Source" or "free" or "third-party" or "custom" or pretty much anything. Also, try and somehow pretend MediaWiki is made by Microsoft. If you say the wrong word, or fail to say the correct ones, you may alert your IT group to the fact that this software is unapproved!

* this is hilarious, think about it

Who becomes the admin?

Something else to keep in mind: if IT actually goes off and actually installs the thing, how are you ever going to get access to it? If you haven't learned by now, the easiest application to support is the one with the fewest users. And a good approach to keeping your user count down is to prevent them from crowding in too much in the first place. Zero is the best number!

SharePoint Time

Let's get down to business: actually comparing SharePoint's wikis to MediaWiki, head to head. I'll take the SharePoint perspective:

SharePoint PROS:

  • SharePoint wikis take a grand total of two minutes to install and configure. Two minutes.
    • Infrastructure concerns, like high availability and security, are covered.
    • As Don King would say, it's "supportatudinous!" IT supports it already! It is backed up like the rest of your SharePoint data! You'll get upgrades for free!
    • You didn't even have to fill out the 8 page online help desk form, followed by a 10 page project request form, followed by a 3 page departmental project request form, followed by 2 security forms, followed by a third "surprise!" security form. You just made the wiki, all by yourself! Like a grownup! It was so simple I didn't even have to use fancy words like "provision"!
  • SharePoint wikis use Integrated Windows Authentication*, emphasis on the word Integrated. The point is: seamless security. Footnote: security is configurable, maybe you're not using Integrated Windows Authentication specifically …but you should be.
  • SharePoint wikis have minimal wiki syntax, instead relying on the rich text edit control. What's the syntax to bold up some text? Oh yeah, click the bold icon. Awesome. *tiny footnote: many wiki implementations have a WYSIWYG edit control, not MediaWiki specifically.

SharePoint CONS:

  • SharePoint wikis are relatively feature-thin. I'm totally okay with this, but I'm sure the grizzled internet wiki veteran will be angered by, for example, SharePoint's extremely easy-to-delete pages, and lack of discussion pages, etc.
  • SharePoint wikis are lists, and as such, should probably remain smaller than 2000 items. Yeah, there's a whitepaper on the subject; after too many items, performance of operations on a list slows to a crawl.
  • SharePoint costs money, somewhere down the line—either for SharePoint itself, or for SQL Server, or just the server license, SOMEWHERE down the line, you're paying.

Intranet NOT Internet

If there's one thing you get through your skull—actually, if there's one thing, let's make it Peter's Fundamental Law #14 ("Don't invent yet another YAML")—okay, let's try for two things. If we have room for two things, the second one should be: the intranet is not the same as the internet. When comparing wiki engines, keep this in mind! The intranet is not the same as the internet!

Thursday, May 08, 2008 8:00:07 PM UTC  #     |  Comments [16] Tracked by:
"SharePoint Kaffeetasse #64" (Mirrored Blogs) [Trackback]
"Links" (Shared Points for SharePoint...) [Trackback]
Wednesday, May 14, 2008 7:47:42 PM UTC
Hi Peter,

You seem to know what you're talking about, so I'm hoping to solicit some free advice from you.

I'm a super-beginner MOSS 2007 user (in fact, so super that IT hasn't even installed it yet) on the communications end of the company intranet. We're planning to use the wiki to keep track of team descriptions. (i.e. who these people are and what they do and how it connects to the bigger picture).

After reading this post and the SlideShare post that started it all, I'm starting to get scared. It seems like the wiki will be limited to being housed on one team page. The problem with this is that we need our entire staff to contribute to the wiki in order to make it 1. successful 2. possible. However, we can't possibly give our entire staff reading/writing rights to any one team's page. Do I have to ask IT to set up a "public" team page just for the wiki? or can I somehow place the wiki somewhere public, like the homepage?

Wednesday, May 14, 2008 10:13:46 PM UTC
First, let me tell you your biggest pain will not be technical problems (i.e. what you've listed above) but instead, human issues. Getting people to contribute quality content will be your biggest challenge.

That said, the quick answers to your questsions are:
1. You can set up a wiki library on the root site or set up a wiki site somewhere underneath the root site, or even deploy a wiki site as the root site itself. Root site, meaning, e.g. "" is a root site, "http://corporate-wiki/" is a root site. So even though I've implicitly stated SharePoint's wikis are for individual team use, they're flexible, and you can make it work.

2. Security-wise, SharePoint can handle what you're asking, yes, just ask your IT or site admin to do this.
Peter Seale
Tuesday, May 20, 2008 1:51:53 PM UTC
Good writeup, hits most of the points. A couple of things...the YAML of other wikis can make their way into SharePoint. For instance, I'm in the middle of extending the MOSS wiki to cover this functionality as we're bringing a typically Linux-based group into the fold...they expect that sort of thing. Might not be a major concern for anyone else :) And as for the "click the bold icon" argument...well, the rich text editor doesn't work in FireFox unless you do something like dynamically attach fckeditor.

But really the wiki's integration with everything else SharePointy outweighs the cons.
Wednesday, May 21, 2008 4:47:42 PM UTC
"SharePoint wikis have minimal wiki syntax, instead relying on the rich text edit control. What's the syntax to bold up some text? Oh yeah, click the bold icon. Awesome."

you fail to mention that every decent stand alone wiki product also includes a WYSIWYG editor, just like SharePoint. From your description, it appears that all non-SharePoint wikis must be constructed using solely this "unnecessary" wiki markup language.

Although I agree that wiki markup is yet another syntax to learn, it is certainly much easier than SharePoint's generated html which produces such "awesome" lines as ...

<p class=ExternalClassD53E711B8A5D436EBBDD5AFDF85A7C05><font size=4>You text here</font></p>

ExternalClassD53E711B8A5D436EBBDD5AFDF85A7C05 is quite an intuitive naming scheme
Wednesday, May 21, 2008 5:07:05 PM UTC
You make a good point Chris Re: WYSIWYG editors, unfortunately none of the wikis I've tried (FlexWiki and ScrewTurn wiki on the .NET platform) do this. Neither does MediaWiki.

But yes, if there is a WYSIWYG environment that hides the wiki syntax from me, it would be much appreciated and I would remove that criticism of traditional wikis.

I had to search around, here is the specific page talking about MediaWiki's (nonexistent) WYSIWYG support:

As for the last point, if you need to worry about the underlying HTML for any reason, then by all means stay far far away from SharePoint's built-in WYSIWYG HTML control. Instead switch to design view and type/paste in your HTML raw.

This is a perspective shift: try to pretend that your wiki pages are Word documents instead of actual web documents--they're not meant to be accessible, XHTML-compliant markup, they're just the simplest thing that works.
Peter Seale
Wednesday, May 21, 2008 5:25:41 PM UTC
I believe there are many wikis that contain WYSIWYG editors ...

A custom search for wikis with WYSIWYG editors on produces the following:
"The following 56 Wikis match your search criteria:" ... which includes excellent wikis such as Confluence, Clearspace, Socialtext, Wetpaint, and XWiki. This is not a feature that is limited to SharePoint.
Thursday, May 22, 2008 2:11:44 AM UTC
Noted, I'll put a tiny disclaimer, but the criticism stands for MediaWiki specifically. Plus it was a pretty weak point to begin with, so I'm not too worried about it breaking my case.
Peter Seale
Friday, August 22, 2008 1:34:58 PM UTC
Hi Peter,

You seem to have some expeirance with smaller companies and their policies so let me enlighten you a bit on how this works in one of the biggest companies in the world.

The IT department(s) are about 10000 people in size, and no this is not an IT company. All IT work is just supporting the systems and applications used to execute the actual business.

So most support groups have their own WIKI setup on a machine in a testlab or on some other non production server. The corporate intranet contains tens of thousands of pages and there are at least 5 different document reposetories in use in various parts of the company. Some of these reposetories are regionaly restricted others are business unit restricted but all overlap and contain similair or identical data in parts and locations.

Then someone high up the tree has a brainfart and there you go boys and girls we will now be using sharepoint for all our documents, and the best part is all business units and groups will have their own wiki to work with.

Me being the lucky one in my small little group of the global orginization gets to update the part of the wiki for our business unit, and guess what... Sharepoint sucks hairy donkey balls!
You are wondering why?
- No linking to anchors in a document
- No table of contents generation
- No deadlink checking
- No way to create a link back to the refering document
- No way to import existing pages
- No way to export pages
- All inline CSS code is blown up as much as possible
- Produced HTML code is depricated

All in all if there is one thing I can say for sharepoint's wiki implementation it is a very sorry excuse for anything trying to resemble a wiki. The only point of your write up that I do agree with is the silly way every wiki wants you to learn a new markup language which is quite iritating.
Wednesday, March 11, 2009 8:15:39 PM UTC
This is a pretty disappointing post. This is actually the reason the wiki is such crap in the first place (sharepoint in general actually). Its the reason Msft slept on the internet in the early/mid 90s and its the reason there is no longer a single sliver of innovation coming from IE. This bone-headed attitude whereby real innovation is disregarded as being some sort of annoying little pet project, something real, paying enterprise customers will never be concerned wit, just because historically it hasn't been. People like you are killing Microsoft. Shame on you.

And yknow the lack of wiki syntax wouldnt be such a bad thing if the wysiwyg editor ACTUALLY WOKRED. But it doesn't. The end result is that even if people REALLY REALLY want to make a corporate wiki work, there are so many impediments to use that you're really barely any better off than you would be using docx and etc. This is probably at least an unstated objective among Sharepoint PMs: "building a proper wiki will make peopel much less likely to use Word, so lets not go there. Wiki's are just a silly trend anyway, its not like any of our fancy enterprise customers will give a damn, if we tell them they shouldn't."

Embarrassing case in point: an microsoft wiki created by msr for documenting projects at Microsoft uses MediaWiki.

Some other things SP wiki lacks: discussion pages: actually quite critical to a healthy community wiki; simple attachments (haven't found it yet, don't feel like making a list).

If you want a good enterprise wiki: consider Jira.
Wednesday, March 11, 2009 8:17:33 PM UTC
Wednesday, March 11, 2009 9:05:50 PM UTC
Drew, ha, noted.

I agree with you in general, and maybe I need to update my post to reflect that. SharePoint wikis are USEFUL COLLABORATION TOOL, but they're not an ENTERPRISE WIKI.

If I don't update my post, it's not because of any malice on my part, it's just because I'm lazy :)
Peter Seale
Wednesday, March 11, 2009 9:20:11 PM UTC
And I should separately address the "shame on me" point:

First, thanks for helping me reach a personal milestone with your passionate blog comment response :)

Second, yes, I agree that I put forth an attitude of giving up on wikis, which is probably fatalistic and I shouldn't be doing this. I do think that they're incredibly useful, when there's a critical mass/engaged community. This is the key point where I'm giving up in an enterprise. But I shouldn't be. And yes, I agree that, if your goal is to set up a vibrant community, then the SharePoint wiki implementation will be a problem.

And no, I don't expect SharePoint wikis to improve significantly in vNext; I'm pretty sure they're using the MS partner channel to provide better wiki solutions, assuming you want to use SharePoint for wikis at all.
Peter Seale
Thursday, July 16, 2009 9:38:43 AM UTC
There are many companies that have used MediaWiki and other non-Sharepoint tools for a corporate enterprise wide wiki (even when they have Sharepoint in use globally anyway) - e.g. Pfizer, Schlumberger,ConocoPhillips, CapGemini, Novell, Gartner, Siemens and more I'm sure I don't know of.
Jon Harman
Tuesday, June 29, 2010 6:47:17 PM UTC
What's with the yellow spots all over this site? It makes it hard to read.
Wednesday, February 01, 2012 11:00:23 PM UTC
To Jack: I had the same problem. The yellow spots are your search words you used to find the page. I cut and pasted the URL in the address bar so I could read it without them.
Monday, February 06, 2012 8:41:08 PM UTC
Yall, I'm in the process of moving my blog so the yellow text from incoming searches will no longer be an issue.

In the meantime, why are you still reading this post!?!?!?!?! I recanted the bulk of it a long, long time ago, and that was for the (now out-of-date) 2007 version. Please don't take my early (bad) advice about SP wikis, and form your own opinions. It's been almost 4 years, and this post has aged...poorly.
(will show your gravatar icon)
Home page

Comment (Some html is allowed: b, blockquote@cite, strong) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

[Captcha]Enter the code shown (prevents robots):

Live Comment Preview

© Copyright 2015, Peter Seale