Differences with SharePoint wiki
This is an essay. It expresses the opinions and ideas of some mediawiki.org users, but may not have wide support. Feel free to update this page as needed, or use the discussion page to propose major changes. |
The purpose of this page is to describe differences between SharePoint's wiki and MediaWiki. They are quite different. Versions of SharePoint are different from one another; this page is not specific about the differences.
SharePoint's wiki has historically been intended to be edited from Windows machines and the Internet Explorer browser. MediaWiki was always intended to be cross-platform. SharePoint has become more cross-platform over time. It is common still to find that SharePoint works a little less well with Chrome, Firefox, etc, than with IE.
SharePoint does not have categories, which are quite useful in encyclopedia-building and to find related subjects.
SharePoint does not have templates for building pages in a standard format.
MediaWiki's search can find all main space, and with special advanced search can search other namespaces (user, templates, categories, etc)
MediaWiki coupled with Elasticsearch provides very powerful search features
In MediaWiki, an editor can edit a section of a page, and fairly conveniently link to a section of a page.
In MediaWiki, an automatic table of contents appears in a page with sections. It can be suppressed with a magic word.
Comparisons between past versions of a page are easier to read in MediaWiki than in SharePoint.
SharePoint has document directories in which it is often easy to upload a file. Thus it is easier than MediaWiki to use as a document manager. Additionally, SharePoint has the ability to checkout files, which makes it easier to have multiple people editing a file.
SharePoint pages can have multiple fonts. However, SharePoint's WYSIWYG editor may induce formatting changes in vertical spacing or fonts. This sounds like "just a bug" but in old versions of SharePoint it happened so much that one would routinely give up on choosing the font. In the current versions (13?) it happens less.
SharePoint has special handling of "Web parts" which does not have close analogues in MediaWiki. Some versions of SharePoint refer to "Master Pages" (meaning not known to this author)
MediaWiki has a vibrant extensions community. Most things you'd want a wiki to do, one or more people have attempted to create an extension.
MediaWiki has methods (via Semantic MediaWiki and Cargo) to store and query data within pages, minimizing duplication across pages. This allows a simple wiki with text and images to become a flexible structured database where users can query information and use it in countless ways. One simple use of Semantic MediaWiki allows us to link hardware pages to meeting minutes, operational constraints, lessons learned, mission pages, manifest data, lesson plans, crew procedures, and many other things.
Semantic MediaWiki also allows us to identify gaps in our knowledge (where data is missing) or to do specific queries like “give me a list of all pages that are of Category:Tool where the value of Mass is between 5 and 15 lbs, but instead of the page name, show me a picture of that tool”
The extension Watch Analytics allows for us to measure how well our users review our continuously evolving content so we can quantify the quality of our knowledge.
Another comparison list to combine
editIn MediaWiki
- Content in disjointed linked pages
- Edit online, and content changes are immediately visible
- No implied organization - Organization can be built (Navboxes, Infoboxes, Portals, etc.)
- Finer granularity - Fields, Subobjects, Reports
In SharePoint
- Content in word, xlsx, pdf, etc.
- Any duplication will become out of sync
- Data at rest
- Organized by site or metadata
- Can be set up by an office administrator
- Security by workspace -- very important in some applications. While this is appropriate for data that has more strict access constraints, it is important to acknowledge that MediaWiki's approach of site-wide permissions encourages users to share data that is not under tight restrictions. For example, there is no legal reason to obscure information about how to set up a printer or the high-level overview information about some hardware. By locking down this higher-level knowledge, Sharepoint encourages users to duplicate data, which then leads to divergence of facts. For example, one silo in Sharepoint might claim the date of an event is 2019-01-15 and another silo might have a more current value of 2019-02-21. By forcing users to store this value in a single source, the data is more likely to be current and trustworthy. You might summarize the difference as "need-to-know" (Sharepoint approach) vs "need-to-share" (MediaWiki approach).