Talk:Documentation

Old documentation tree

moved to Technical documentation

Comparisons with CMS

One of the challenges is to get people adopting MediaWiki as a CMS system not just a collaborative article clearing-house. Though MediaWiki is a collaborative tool, not a lockdown CMS, it rates well as a CMS. It shares many abilities of main open-source CMSs such as Joomla and Drupal. Mediawiki offers the following advantages:

• Scaleability (Wikipedia)
• Simplicity of installation
• Full history
• Image and media handling
• Ease of use
• Enthusiastic developer community
• Well established extension writing procedures

User Observations

The CMS test and comparison site Opensourcecms rates Mediawiki 4.3 out of 5 and has a comments section which includes the following user observations:

• Mediawiki is great. I especially like the fact that it keeps all the changes so that you can few the history of every page (and roll back if you are the author or admin)
• It's just great for my simple Hebrew, utf8 & multilingual editing requirements. easily installed (web config)
• Very easy to use wiki but hard to customize. What i miss is a better management to disable public page edit.
• Arguably the best wiki out there, however it falls short in many other areas. For starters, if you do not like coding - stay away from Mediawiki. It is extremely user UN-friendly as it has no backend control panel, and creating your own skins is like pulling teeth. Content wise, you can't beat its functionality.

Online marketer Dan Katz finds MediaWiki too difficult for his clients:

I have been working with MediaWiki for a couple of years. I even have my own best practices Wiki running on MediaWiki. This experience matched with reviewing most client capabilities has led me to the belief that MediaWiki requires far too much technical awareness to recommend as a platform for clients. I have found applications such as SocialText to be a far more attractive package.

Why not MediaWiki for my clients?

• While a fabulous Open Source package, the benefits of commercial package with its support, product roadmap and dedicated team to fix issues is probably the most important reason to go with an alternate solution.
• My clients are all non-technical and have little if any knowledge of any markup language. Even with the best WYSIWYG and other helpful extensions I have found that the users need to know Wikitext. This really kills the popularity of the Wiki. For example, creating and managing categories is a dog in MediaWiki. My clients expect a far more sophisticated taxonomy solution that is simple for a non-technical user.
• MediaWiki out-of-the-box does not offer features that most clients desire. We then need to install numerous extensions. This is fine. However, we then get into a maintenance cycle that requires upkeep of these extensions. Going with a commercial (or open source alternative) package that has integrated items for this functionality removes this overhead. For example, one of the constants in my clients’ needs is to upload files to articles. MediaWiki without extensions expects you to host files someplace else and to link to them. The preferred method is one where you can browse and upload files easily right when you work on the page.
• MediaWiki templates are a bear. Compared to SocialText or other Wiki products MediaWiki requires a higher level of skills. Others that are available build more off of the more common HTML and CSS skill sets.

Comparisons with Joomla and general user comments about MediaWiki from a Buddhist perspective can be found at Emptiness

CMS Matrix

The CMS matrix widely referred to in the literature does not even refer to MediaWiki. There is a home-spun version featured in a simplified way on an education website that plugs Drupal.

There is also a specialised Wikimatrix.

From a Drupal-centric perspective

Drupal in Education, in its article on Mediawiki (http://elearning.psu.edu/drupalineducation/mediawiki) makes the following observations:

• This is great for making sites that community members can edit, nothing more. Wiki's all look (relatively) the same so if you need theme support this isn't the place to find a flexible one. It's also very simplistic in terms of permissions / access restrictions so if you're a control freak and need lots of different permissions you'll probably want something more advanced too.
• MediaWiki is a great platform for building a Wiki-site and doing it quickly. It's relatively easy to install and setup and once it's up you're done. Mediawiki is based off the same platform that powers Wikipedia, the worlds most well known / visible wiki-site. It allows you to get into creating Wiki-sites quickly, much faster then any of the other CMS compared here.

Meanwhile, another Drupal enthusiast notes:

The MediaWiki system had been chosen for a couple of reasons:

• Easy Editability: Wikipedians like myself are familiar with its markup language, which is easier to use than HTML
• Collaborative Wiki Culture: Wikipedia culture has developed elaborate and clever ways of dealing with large-scale problems through cultural processes that take its simple page editing scheme and category tracking to new organizational heights. Most of these processes aren't hard-coded into the MediaWiki software at all. Wikipedia runs mostly on informal policies and practices that Wikipedians have developed through trial and error.
• Community Momentum: MediaWiki enoys a large install base and the ongoing development efforts of the Wikipedia organization.

I created my wiki and saw that it was good. But in biting the apple of Knowledge of MediaWiki Good and Evil, I discovered a pile of problems that set my article tower teetering:

• MediaWiki Is Hostile Towards HTML: As an experienced designer, I found it frustrating sometimes not being allowed to use full HTML without hacks. I used an extension called ABSHTML to allow snippets of code to go unmolested by MediaWiki's parser and this worked for a while.
• Markup Is Still Painful: Even Wiki's simple markup is a pain to teach would-be contributors with a lot more knowledge to share than time to invest learning how.
• MediaWiki Layout Is Simplistic: MediaWiki is designed for long, sprawling encyclopedia article in a single column. As a designer, I hacked it into multiple columns by making templates called

  {{2coltop}}, {{2colmid}} and {{2colend}}

  that injected ABSHTML-wrapped table tags. Editing this became annoying quickly.
• MediaWiki Editability Is Inverse To Article Size: The bigger and more complex an article gets, the less fun it is to edit. I find myself hunting through markup language when what I really want to is think and write about ideas.
• Wiki Culture Is No Substitute For Code: As great as Wikipedian collaborative culture is, it's not a replacement for the ability to provide hard-coded user experiences that follow explicitly programmed paths and workflows.
• Wiki Culture Is Alien To Outsiders: Wiki culture alienates newcomers because cultural processes are not easily discoverable and require editors to learn to apply hand-written markup conventions. For example, Wikipedia has no comment boxes, only a convention of hand-editing comments onto discussion pages followed by --Jack which produces a username timestamp signature.
• MediaWiki has no menu system: I built my own horizontal hierarchical menu system in MediaWiki out of embedded templates. Some other wiki engines have menuing systems built in, but this is a laughable problem to have.

The criticisms with regard to security and interface are no longer quite as warranted, due largely to work done by Organicdesign.

Web 2.0 Features

Some CMSs specialise in the blogging/social networking area. CMSCritic notes that some CMSs offer the following features, only some of which are implemented in MediaWiki:

• Blogs
• Internal message system
• Forums (inkspot)
• Chatrooms
• File sharing
• Profile / pictures rating
• Profile views
• Private photo gallery
• Nudges (kisses, slaps, ...)
• User comments
• Events calendar
• Personal events
• Profile
• Dashboard
• Activity feed
• User preferences
• Comprehensive administration tools
• OpenSocial applications
• File repository
• Forums
• Social bookmarking

Progress towards CMS

The issues that are raised in the literature identify the following challenges:

• Insufficient permissions granularity (addressed by SimpleSecurity)
• Interface too dfficult (Addressed by RecordAdmin and WYSIWYGs)
• Other CRMs do better in terms of forum, blog, chat, gallery, social networking, tag clouds, polls, ratings, search engine optimisation, e-commerce, noting the Web 2.0 features above.
• The lack of user-skinning capacity, and template availability and user-installability, is problematic. It is also an opportunity for developers to earn a living by providing absolute customization, thereby making the site suitable for the user's public site.

This section is about ready to be categorized and made into a new article --Jack 13:29, 18 December 2008 (NZDT)