Initial considerations[edit | edit source]

The first place to start, I think, is comparing the popularity of the various Wiki packages available. Search engine popularity is a an indicator of the level of activity of the development and user community, how well and widely-supported a package is, and how many other folks have settled on a package because it suits their needs. The number to the right of each package name indicates the number of google search results that search query returns as of Jan 1, 06:

  • MediaWiki- 26 000 000 (2006.1.1)
  • TWiki - 16 300 000 (2006.1.1)
  • TikiWiki - 6 100 000 (2006.1.1)
  • PukiWiki - 3 500 000 (2006.1.1)
  • PhpWiki - 2 060 000 (2006.1.1)

(from http://web.archive.org/web/20160829120521/http://c2.com:80/cgi/wiki?WikiEnginePopularity)

Why I eliminated TikiWiki and PukiWiki[edit | edit source]

TikiWiki looked quite robust, but actually too robust in some ways. The demo and videos showed an impressive, almost overwhelming number of different options available to average users. The overall look-and-feel of the package was technical and not very pretty, with a cluttered interface of annoying little buttons and backgrounds of drab greys. Demos showed the softwares use for content management and message-board features rather than featuring simple document collaboration.

PukiWiki is a Japanese language piece of software, with more limited English support.

And then there were three[edit | edit source]

MediaWiki, TWiki, and PhpWiki.

PhpWiki was super easy to install using the Plesk control panel that HolisTech (now Sustainable Hosting) offers. No hassle whatsoever.

Thing is, it's so basic and amateurish looking that it just doesn't seem to be right for the kind of big project you've got planned.

And then there were two[edit | edit source]

MediaWiki and TWiki.

These are the two most popular packages, and for very good reason. They both support plug-ins and offer many features out-of-the-archive, so to speak.

Comparison, feature by feature of MediaWiki and TWiki[edit | edit source]

Web notification[edit | edit source]

TWiki has universal notification features built-in, meaning that an administrator can receive a digest of every change made in a certain "web" (this basically means "wiki" - I gather that one TWiki application installation can support multiple wikis)

MediaWiki is designed for large wikis, so the number of changes which could be expected on a daily basis would be too numerous for a single person to go through. Instead, individual contributors add pages to watchlists, and they are notified when the page changes. You could be notified any time a page you created changed . But users can watch whole categories of pages (see categorization features), and the "related changes" feature lets users watch the pages that pages in their watchlist link to.

I think there is a plug-in available for MediaWiki that provides universal notification functionality.

Content locking[edit | edit source]

TWiki has many robust features built in. TWiki allows page-by-page settings for who can edit.

With MediaWiki, you can't control who has access to change specific pages on a user by user basis — I can't even find a plugin that offers this functionality other than to cut non-authorized users out of viewing pages all together.

With MediaWiki version 1.10.1, you can control which user(s) can read and which user(s) can edit on a user-by-user basis by using the namespace protection feature. What you do is to assign a group of users to each namespace. Then for each namespace, you allow the corresponding specific group of users to read or edit the pages belonging to that namespace.

You can, however, limit modification privileges just to registered users, who have to verify their email addresses as part of the registration process (this is disabling anonymous edits). I believe, also, that it is possible to lock specific pages from all changes (a feature which became necessary because of politically-sensitive Wikipedia pages being vandalized or modified to be politically partial.

You can also control new-user registration, approving each registration request individually.

Sites for both packages emphasize that the more locked-down a wiki is, the less it is a wiki.

WYSIWYG[edit | edit source]

TWiki has this option as a download extra beta feature. It works in Firefox and Mozilla, and possibly IE.

MediaWiki does not have this feature yet. However, an experimental plugin is available that offers this functionality in the current version (http://meta.wikimedia.org/wiki/WYSIWYG_editor). Also, the in-development version, 1.6, will include this feature in its default configuration.

Just like on wikipedia, however, users are presented with buttons that insert code snippets into the textarea for editing. This isn't WYSIWYG, but it at least means that, at least for basic formatting needs, users don't have to remember code.

graphics and caption text in tabular form[edit | edit source]

TWiki and MediaWiki will both do this equally well.

Tables are easy to create with similar markup formats, and can easily include images.

Images are, for the most part, easily uploaded with the web-browser, as attachments to a page in TWiki, and to a media library with tagged information about each file with MediaWiki. The uploaded files are then included as in-line graphics in wiki pages with special markup. Examples:

Twiki - %ATTACHURL%/Smile.gif

MediaWiki: [[Image:bayyati.jpg]]

It is unknown how easily the WYSIWYG editing features will allow the user to upload and include images.

Wrapper front pages[edit | edit source]

It's easy to create pages that link to other pages in both, possibly functioning as central project starting points or TOC's with both packages. MediaWiki includes a "What links here" on each page, Twiki offers the same thing as "Backlinks."

Math Equations[edit | edit source]

MediaWiki supports this function by default. I'm not positive, but I think that equations are entered the same way they are entered into Tex typesetting software, meaning that if students are familiar with one, they'll be or become familiar with the other. Students can also look at the source code and copy out Tex markup to use in their printed documents.

With TWiki, math equations can be handled by downloading a plug-in. Most of the math equation plugins take equations entered as Tex markup.

Piece-meal editing[edit | edit source]

MediaWiki gives users and edit link at each section header in a document, allowing a user to quickly update a brief section instead of look through the whole document to find the one part that needs to be changed. This also streamlines the watchlist process, because document histories prominenty show the sections in which changes were made.

Discussion and talk pages[edit | edit source]

MediaWiki has a feature for discussion and talk pages (check out wikipedia). These are a sort of wikified salon where people discuss the article topic informally before committing changes on the document itself. MediaWiki can be configured so that unregistered users can contribute on talk or discuss pages even when they can't make changes to the article page itself. TWiki has a commenting feature which shows comments at the bottom of the wiki page. Comments themselves don't act as wiki-style pages, though. That is, you can only add additional comments, not edit existing ones.

Examples[edit | edit source]

I found a similarly-themed Wiki, on Permaculture: (http://permaculture.wikia.com/). This site uses MediaWiki.

Other considerations[edit | edit source]

Wikipedia and the whole host of WikiFoundation projects all use MediaWiki. If students learn to use a MediaWiki textbook for their class at HSU, they will be able to contribute to many other popular Wikis with no additional learning.

Resources[edit | edit source]

An amazing resource to help with choosing a wiki
(includes something called Wiki Choicetree)
http://web.archive.org/web/20160828013406/http://c2.com/cgi/wiki?ChoosingaWiki
Allows side-by-side comparison of various wikis on the basis of feature-sets
http://www.wikimatrix.org/

Documentation[edit | edit source]

Both applications are supported by wikis for their documentation. Of the two apps, TWiki has better documentation, even though the documentation for both packages is not current with the software. Twiki's documentation is for the 4.0.0 release, but the current release version is 4.0.1. A support network of forums and chat rooms which I haven't used yet appears like it could be a great help.

For being more popular, I am surprised that the official documentation for MediaWiki is not as good. Yes, all topics I was interested in are covered, but there are some sections in the documentation files that are included just as placeholders to be filled in later. Documentation is definitely an in progress project for this one.

Installation experience[edit | edit source]

I've spent a lot of time trying to install Wiki packages on my web-hosts server. Now, I realize it might have been wiser to have tried doing the same thing on my local Mac's apache based PHP-supporting server, where I would have more control.

I was able to get Twiki working some, but not perfectly. To work, it needs at least one addition perl extensions installed on the server that isn't installed on HolisTech's server. Overall, though, I was still impressed by the install process even though I couldn't get everything to work in the end. I think it's mostly my inexperience and inability that's screwing things up.

MediaWiki also appears as though the install process is pretty straightforward (like Twiki it has really good user-friendly error reporting, so that's a great sign), but I can't get past the first step because of a certain setting in HolisTech's PHP software. I tried uploading a new php.ini file, but to no avail. This is not a problem with MediaWiki but an issue with the server I'm trying to install on.

Overall impressions, summary[edit | edit source]

TWiki is, in most ways, much more robust than MediaWiki. Check out the application sandbox <http://web.archive.org/web/20210506094814/https://twiki.org/cgi-bin/view/Sandbox/WebHome>. It has news and commenting applications, meeting minutes, editorial systems, and a whole bunch of specialized applications. It seems to me that TWiki is designed to be more than just a collaborative document space, but be useful for managing collaborative process. It is much closer to Moodle than MediaWiki is.

Perhaps you might find this useful, but my suspicion is that Moodle works well for class process and project collaboration, but that this wiki should be geared more specifically to publishing content.

TWiki is a prettier, and in most ways, a more polished application, with an apparently impressive developer community and many plug-ins available for it. It is indisputably the more flexible of the two packages.

However, MediaWiki still has a lot going for it if it's to be used to create a collaborative document space. It has just enough nice touches perfectly tailored to this application, such as editing content by section, and talk/discuss pages, as to make it better adapted to some of these needs. Also, even though the markup that MediaWiki and TWiki use is essentially the same in its general features and principles, the specifics of these markups are different, and I think it is a benefit to use the same markup as Wikipedia.

One may compare software based on its feature sets quite easily, but it is also important to compare software on the basis of its overall design philosophy, its purposes, its intentions. On this count, both TWiki and MediaWiki have a lot to recommend them. TWiki tries to be slick and beautiful but still adaptable.

MediaWiki is slightly less slick, but it shows its developers stalwart interest in creating smart collaborative content systems. It is geared specifically towards scholarly applications, as its built-in support for TeX shows. It is probably because of its academic orientation that it has been chosen by similar projects such as the earlier mentioned budding permaculture wiki (http://permaculture.wikia.com/). It's less flexible nature can be explained in part by the creator's wish to design software that reflects their values and principles — such as the the limitation that WikiMedia cannot be used to restrict page-modification access to specific users.

Hopefully, this outline of differences between the two leading wiki packages will allow you to further clarify exactly what your needs and priorities are for this project. Undoubtedly, both of these software packages are excellent and could function well in an academic context. Personally, I am partial to MediaWiki because of it's overall style, which shows great attention to the purposes of academic users. I feel that its admittably less flexible suite of features is actually an advantage because the software reflects certain values of scholarly pursuit, and open access and participation more readily than TWiki does.

And then there was one?[edit | edit source]

(Updated: MediaWiki!)

- Aaron Antrim

Delivered to Lonny Grafman and John Wu on 12 March 2006

Cookies help us deliver our services. By using our services, you agree to our use of cookies.