technical solution

Draft version
Author: Jean-Pierre Redonnet

Many wiki engines are available. But very a few wikis are free and open source and offer:

  • A fine grained permission control that can be set for each page, group of pages via an access control list. This feature is very important to avoid the risk of vandalism or to prevent students to modify the wrong pages.
  • A wysiwyg and a math formula editor to simplify the page edition and to avoid to enter html codes.
  • To upload and attach files to a page.
  • To embed a flash and video player.
  • To be mobile friendly.

TikiWiki seems to be a good answer regarding these constraints. Its stengths are the 300 to 400 developers, the good documentation, a very complete application with weblogs, forums, quizzes, polls, surveys and calendar, all included in the application. It is written in PHP, a programming language easy to learn. The main issue seems to be the lack of fine-grained permission control for the wiki pages; a trial on a demo hosted on opensourceCMS did not show the possibility to give the group permission to edit only some pages. Note: This problem needs to be verified! Another problem is the complexity of the code with about 1,000,000 lines (the counterpart of a feature rich application).
AulaWiki developed in Spain is an extension of TikiWiki, in order to add some features specially designed for the education.

MediaWiki is very robust and is a standard de facto. Unfortunately, it does not have a permission control. There are some extensions to add this functionality but they seem unreliable. It is clearly specified on their website // that MediaWiki was not written to provide per-page access restrictions. In conclusion, MediaWiki is not the right choice here. is interesting in several points. It has a good access control lists mechanism. It accepts plugins, and is written in Python, a very clean language. Its main drawbacks are the flat files storage limited roughly at 100,000 pages and the page search performance. is another interesting wiki. Like moinmoin, it has a good access control lists mechanism, accepts plugins (named recipies), and use the flat files storage, so with the same problem as moinmoin. Pmwiki is written in php and its philosophy is to only include the essential features in the core. pmWiki is used by several colleges.

There is the possibility to create a wiki farm too. With one wiki per topic, the 100,000 pages limitation is not a problem anymore, the search should be faster because words will be searched inside the pages of one topic, and the permission should be easier to manage too.

phpWiki uses a database and offers the features I need (ACL, flash, video, upload files… ), it can be a good solution, but some developers critic its complexity and the mix of html with the php code. So, this point should be verify.

MinTouch Deki Wiki could be interesting too. It uses a database and offers all the features needed. But apparently, it mixes php and c# and I don't like this approach.

JspWiki seems a good solution too. It has many features and new ones can be added easily with plugins. It is written in Java, a good language too. Its main inconvenient is the flat files storage.

Preliminary conclusion

Perhaps, the point the most important to verify is the code itself! A well structured and well documented code source, with plenty of comments, descriptive variable names and function names will be the major criterion.

Database or flat files?

Both solutions have their pros and cons that I tried to summarize in the table below.

Pros cons
* * * Database * * *
Scale up very well +
Require a DBMS (mySQL, SQLite…) -
Require knowledge of DBMS -
Search faster +
* * * Flat files * * *
File can be edited manually +
File can be copied, moved, deleted manually +
Common linux tools 'find, grep, wc…' can be used +
Require a filesystem performant -
Lost of performance when the number of files increase ?
Files number limited ?
Search slower -

Practically, the flat files storage use the filesystem as database management system (DBMS). We can suppose that because the primary job of the filesystem is to manage the files with their physical locations on the disc, A filesystem is not especially well optimized to retrieve quickly one file in the middle of thousands of files. In other hand, we can suppose that a DBMS will be more efficient because it is designed to retrieve quickly any data in the forest of bytes and don't have to take care of the physical locations of the data.

It is very difficult to convert thousands of flat files into a database, so it is important to choose the right storage format when choosing the wiki engine.

Concerning the Academic Wiki, the number of pages will grow over time, theoretically limitless. It will grow when new courses, new topics and student contributions will be added. It is certainly prudent to choose a wiki able to scale up easily and without limitation. It is better to decouple the file system of the data management too. In conclusion, a DBMS is the best choice.

Extra features required: change core code or create plugin?

Changing the core code is certainly much harder to maintain than plugins, and will require the agreement of developer community of the wiki. There is the possibility to create a fork, but it is the last solution. Forks tend to dilute the developers effort. So the goal is to use plugins to add the new features to the pedagogical wiki.

List of traditional features required:

  • Fine grained permission control.
  • Wysiwyg and a math formula editor.
  • Uploading and attaching files to a page.
  • Embedding flash and video players.
  • Being mobile friendly.

List of new features required:

  • Author name, creation and date and last update are displayed in the margin the article.
  • Icon indicates if the article has been reviewed or not.
  • Article ratings (level of difficulty, of interest, of accuracy, of references…) are displayed in the margin.
  • Only the instructors or the reviewers can update the ratings.
  • Reviews and comments can be displayed.
  • Auto-corrected exercises and quizzes can be easily created and included in the page (html form entries and javascript are automatically generated, the user doesn't need programming skill).
  • Survey is added at the end of each page.
  • Contributions of each students over a period of time can be listed, student activities are quantified.
  • Pages can be compared, similarities searched and quantified.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License