MS SharePoint as a Wiki: Few Functions, less Compatibility

Siehe auch den deutschsprachigen Artikel zum Thema.

Update from 2009/07/31: This article was intensively discussed. Evidently there are some factual errors in it, that concern Sharepoint as a product apart from the Wiki features. No one doubted, that Sharepoint cannot cope with state-of-the-art Enterprise Wikis. And that's important here: "Sharepoint is a great and beneficial product for a lot of companies. But Sharepoint is not a good Enterprise Wiki."

The basis for this article were recently constructed under the leadership of Martin Seibert at an open-space session at the WikiSym in Portugal. The original document is available in English under the title “How good is MS Sharepoint as a wiki?”

Without professional knowledge management, companies are losing potential, wasting resources, and acquiring unwanted competitive disadvantages. Along with many other companies, the industry giant Microsoft has rolled out its own application, SharePoint, which allows data to be centrally deposited and edited.

But is MS SharePoint really a good alternative to a fully developed company wiki application? Our answer is a definitive “no”.

Microsoft SharePoint as a Wiki

Microsoft isn’t offering more functions than would be necessary for a completely rudimentary wiki. Pages can be created, edited, and given links. If Internet Explorer is your browser of choice, the page can be augmented in a way reminiscent of MS Word. That’s it. But it’s just not enough to become a really helpful company wiki. 🙁

Working with SharePoint is extremely problematic, especially when the system is divided among several locations: Data of office must sometimes be downloaded onto the local server before it can be edited. Afterwards, you have to upload it again. Incomplete processes create annoying waiting times.

User productivity
Even just the downloading of a big document from the WAN costs time, even if it is only a minute. If the user then also notices that it is the wrong file, this is not only an annoyance but also a reduction of productivity that must be taken seriously. To give one example, SharePoint doesn’t have any full-text search function, which is why the quality of the search results is often relatively low, as these are often directly dependent upon the error-free classifying and naming of documents. Sixty seconds may not seem to be much in a one-case scenario; many minutes per month, however, may be a different story. Multiply this by 500, 1,000, or 10,000 employees, and you have a serious waste of time.

Lack of compatibility
MS SharePoint is based on Microsoft products. Every computer needs MS Office Professional Edition, and Microsoft Clients are absolutely required. Moreover, de facto only Internet Explorer can be used when working with SharePoint.

Here is a screenshot of MS SharePoint with a Firefox browser:

Screenshot of MS Sharepoint without Internet Explorer

It is especially problematic when the user – even in a standard document – is confronted directly with source text and HTML code. This does not contribute to good usability. To give an example, documents may become perfectly unusable after having been vigorously formatted or subjected to copy and paste processes. Beyond this, the program does not allow all of the functionality that should be expected from a serious rich-text editor.

SharePoint is complicated, and not all of your employees will immediately be able to use the system without training. Training and unproductive practice time will therefore be necessary.

Data sharing
SharePoint was first and foremost developed to collect data in a central location. Active knowledge management with shared texts and web content is not part of the plan. Also, everything focuses on MS Office documents. At the least, the system is clearly missing many necessary components for a professional enterprise wiki.

SharePoint looks – at least superficially – professional. At first glance. But which MS product doesn’t? And yet, here lies the disadvantage: The development of company-specific expansions is not so easily possible as with comparable wiki systems. Unfortunately, the wiki functions of SharePoint are very basic, so an expansion would be of the essence.

Hide instead of share?
In MS SharePoint, new elements are often published and available only for the user themselves – in the name of “safety”. The standard configuration only allows this user – or at best the user with a couple of colleagues looking over his or her shoulder – to access these newly published contents. That is the exact opposite of what a wiki should actually allow. “Everyone participates in the wiki, and everyone can see new contents” is part of the mantra for success shared by successful wikis. Only those contents that others shouldn’t see are protected and hidden. MS SharePoint is no product of the interactive and user-driven Web 2.0.

Further disadvantages
In addition to all of the above, the technical restrictions alluded to result in further challenges, which deserve specific mention here in a list:

  • SharePoint cannot – as a wiki – be implemented as an extranet because there will definitely be other browsers in use than just Internet Explorer.
  • It is probable that Microsoft is fighting many (for it) more important battles, which will likely lead to the result that the weak wiki in MS SharePoint will remain weak. A couple of examples:
    • Microsoft Office is competing with numerous offline- and online alternatives, such as “Open Office” on desktops or Google Docs, Zoho and Adobe Buzzword on the internet. All of these are well-developed alternatives and have become widely available and used.
    • Google Chrome has also ruffled the all-important browser market in the recent past. In addition, Firefox offers a widely distributed and – in many technical areas, superior – alternative to IE.
    • Regarding operating systems, Apple with its Mac OS X is a competitor to Windows Vista that cannot be taken lightly. Finally, the development and popularity of Linux operating systems is increasing.
  • We believe that Microsoft is currently not focusing on the field of enterprise wikis. This is also shown by the collaboration with Atlassian (see below).
  • Only one MSS SQL server may be used to operate Sharepoint. Especially in larger operating environments, this can quickly lead to performance problems.
  • There is no comments- or discussion function, which is the norm in well-developed wiki systems.
  • If you wish to bring a file into the system, you need a sensible depository place within MS SharePoint. You cannot simply load the file from your hard drive (which is normal in other systems), but must first locate it within SharePoint.
  • It is basically a simple and limited whiteboard-wiki without the advantages of a structured wiki. There are no hierarchies and no assistance regarding navigation through the wiki pages.
  • MS SharePoint isn’t even referred to by Wikipedia as an “enterprise wiki”. The system also isn’t even included in the comparison chart by the comparison service WikiMatrix. The operators will tell you – if asked – that Microsoft has no interest in having its product compared on a wiki-comparison page. This would probably be – regarding the comparison of functions – a somewhat sobering experience.
  • In e-mail notifications of changes, you don’t see merely the changes but rather the entire article. This is not very useful.
  • There is no overview of changes in which you can also see what was actually changed. Whoever expects to be able to track changes like in Microsoft Word is going to be bitterly disappointed.
  • This list was still more thoroughly supplemented in the discussion at WikiSym2008. Nevertheless, since this discussion often revolved around plausible suppositions without proof, these will not be reproduced here. The rumors may be read here, however.

Safety anchor: Confluence
If you – for political reasons – still must insist on implementing MS SharePoint because it is required by your internal guidelines or company decisions, you should try to install a fully compatible enterprise wiki through the proverbial backdoor by using Atlassian’s Confluence and that company’s SharePoint Connector. The advantages include a uniform search function and the possibility of embedding contents in Confluence – and the partial imbedding of Confluence contents in SharePoint. Additionally, the connector allows a shared user management in both systems. If you would like to learn more about this, please contact us. We would be happy to advise you.

SharePoint’s problems are obvious. Therefore, MS SharePoint is nearly unusable as an application for knowledge management that I envision and is no alternative to a real enterprise wiki. In summary: SharePoint is only suitable for the collection of data, especially Office documents. Thus, in our opinion, really efficient knowledge management cannot be executed using SharePoint.

Further information:
Wikis in an intranet: TWiki in actual company practice
Wikis are the glue holding intranets together

Mehr über die Creative-Commons-Lizenz erfahren

Diese Confluence-Schulung richtet sich an Einsteiger ohne Vorerfahrung. Es werden die grundlegenden Funktionen und Arbeitsweisen im Tools veranschaulicht.
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

25 thoughts on “MS SharePoint as a Wiki: Few Functions, less Compatibility”

  1. The article title may be an acceptable criticism of SharePoint’s wiki capability(remember SharePoint is much bigger than wiki) but the details of this article are way off. Considering the lack of SharePoint specific jargon in this article I seriously doubt the author(s) spent more than a day with the product.

  2. Hi Mike,

    I will be happy to incorporate your corrections and the correct terms. Please see my disclaimer on this issue here also:

    “That said, I also have to admit and to disclose, that I have been criticized for it just as well as I received praise for it (see here in the German post: Everybody should know, that a lot of things in the article, do not stem from my own expierience but from an open space session on WikiSym 2008 in Portugal, that I led. There were a lot of people, that were talking out of frustration about Microsoft Sharepoint as a collaboration and enterprise wiki solution and I picked up their complaints in my blog post.
    Then I was passed a MOSS 2007 account, to test MS Sharepoint myself. I only did in an empty “space” and for not more than 90 minutes. That is, why some of my criticism might be wrong or shallow.
    But the message remains stable: “Do not use Sharepoint as an enterprise wiki!” 🙂
    And yes, it has been a reaction to clients that are pushing for Microsoft Sharepoint, but wanting an enterprise wiki. Hear my words: You are better of, when you keep your Sharepoint instance and enhance it with Confluence and the sharepoint connector. There are lots of good consultants to help you with that out there. 🙂
    I hope, that my contents will be picked up, analyzed and discussed to clear out errors in my argumentation. I am looking forward to joining this discussion.
    I envision, that eventually, Microsoft will come up with a reasonable solution. But I do not expect that anytime soon. :-)”

  3. I realy dont see how thw downloading and uploading of data effects Wiki’;s with in-brwoser editing.

    It seems like a cheap stabe, as Mike said on a product they used for lass than a day.

  4. If you work with office documents you have to open and close them before and after editing. If they are new in the network they might also have to be downloaded. That costs time. For a wiki, there is no such waiting time. A lot of things are done in Office-documents with Sharepoint. Nearly everything is done on the wiki in confluence.

    Did I get you wrong?

  5. Incorrect.

    A Wiki in SharePoint does not require office. As it supports in-browser editing and is the recommended approach. Nothing to do with office.

    As for opening and closing a document before editing, how would one edit a document before opening it?

  6. Daniel: I agree. You can use Sharepoint as a wiki and inline edit content. But the features the product offers are so poor and limited, that I saw our customers, that are using Sharepoint merely upload Office-documents instead of using the wiki.

    The same customers use confluence completely different, as it is more intuitive and powerful from the wiki-perspective.

    Do you really doubt that?

  7. I’m Sorry, but your article draws attention how you HAVE to use office to use a Wiki in SharePoint.

    However you just stated that this isn’t the case and people have chosen to just upload office documents. Feature poor or rich, your information and statements are wrong. I would suggest doing more research before making a article under the guise of an expert when you have only spent 90mins with a product.

    Also, which was pointed out to me, you state “Moreover, de facto only Internet Explorer can be used when working with SharePoint.” And then back it up with “Here is a screenshot of MS SharePoint with a Firefox browser”, making your statement that it only works with IE completely false.

    Under the term “Usability” You criticise SharePoint for needed business user training. However if I put Confluence in front of a user, I would sure bet that they need training also! Compared to SharePoint, it would be a lot more as SharePoint draws on existing Office Skills which people already have. My point here is any product needs training.

    It seems you have got some very separate and different functionality confused and all rolled it into one as there are several flaws with your article. Very little material relates to the Wiki, but rather other functions and features.

  8. Firstly SharePoint is not a wiki engine. But it does have the ability to support and expand on its wiki functionality if required.

    Second, when you weight in and consider the benefits of having a SharePoint within your environment, then nothing in this article matters.

    It’s extremely interesting to note, that whenever people use SharePoint as a comparison gauge, they always fail to mention the alternatives that are supposedly better!!!

  9. Daniel: The screenshot of Firefox is directly connected to the argument of the incompatibility of Sharepoint from a browser-perspective. All rich text elements disappear, if you choose firefox as a browser. That might not happen in a controlled environment. But if you want to integrate customers, that is part of daily life.

    On training issues you are right. Every software needs training. The question is how much and for what. A wiki is generally very successful, because the first edits are quite straight forward. A lot of wiki users are drawn into wikis without any training. What I hear from our customers, they experience quite the opposite for Sharepoint at their workplace.

    If you want real measures for usability ask yourself: How intensively do you use your Wiki in your Sharepoint instance? How many edits do you have? How many employees use the wiki already?

    I would bet: the average Sharepoint instance will look very poor on these KPIs.

  10. Harish: Thanks for your acknowledgement, when saying “SharePoint is not a wiki engine”. That is exactly what people that I talk to care about.

    I think that a lot of criticism here and also yours is confused as general Sharepoint critique. I like Sharepoint as a solution and it has its place in a lot of companies. But if you are searching for an enterprise wiki, you should rather choose something like Confluence. That is the better alternative, that you were requesting.

  11. Oh yes! That is a very good example. The problem that we have is: “A lot of our clients think, they could use Sharepoint as an Enterprise Wiki.” None of our clients ever suggested to use Excel as a database. But I fully agree, that those situations are both nonsense.

  12. The problem with this article is that you are mostly comparing the Document Management component of SharePoint with the requirements of a Wiki.

    Having used SharePoint as document management tool and non sharepoint wiki’s (media wiki, flexwiki and moinmoin) I cannot comment on the Wiki extentions – but I know that wiki’s do not handle the versioning of office documents. SharePoint is a reasonable document management system designed to incorporate Office documents for structured data. Wiki’s are designed to allow the quick and easy capture of unstructured data. Until recently SharePoint did not offer Wiki functionality.

    The Wiki extensions to SharePoint do not stop SharePoint being a document management tool. If you expect the doc management properties to do Wiki tasks then you are setting yourself up to fail.

    I would like to see a comparison of the Wiki components of SharePoint against a standard Wiki as a proper comparison. I expect they would be no where near as mature in functionality, but at least it would be a meaningful comparison.

  13. Hi Kevin,

    thanks for taking your time and offering your help. I would love to get in touch with you and work out, what is actually wrong in my current post and what changes Sharepoint will see in the 2010 version and beyond. I will reach out to you via email soon and hope for some more of your time to be able to publish a much more balanced view.

    Thanks for dropping by

    Martin Seibert

  14. Thanks Martin for this post, it sure seems to trigger some debate. We at WordonWiki saw an opportunity in all this. There are many organizations standardized on MS Office that would like to use wikis but find it hard to push it because of the poor editing feature. Certainly in Sharepoint environments, people quickly revert to plain ol’ documents in some shared folder.

    WordonWiki is a online wiki product that lets you create pages and edit page content using MS Word. Any browser can be used for reading and the editing happens with MSWord on the client.

    I commented your article my blog on

    Thanks again for the insightful article and the fine debate that resulted from it.

  15. Microsoft SharePoint Development helps you to design flexible sites so that you can customize it based on the user requirements.

  16. Kann MS SharePoint 2010 verwendet werden, um ein Wiki, das für alle zugänglich über das Internet ist standardmäßig erstellt werden, nicht nur die Teil einer bestimmten Gruppe oder lokalen Intranet?

Schreibe einen Kommentar