I didn't know that.
Nor http://www.wikimatrix.org/ …
The version I report here is 2.5.7 of August 2007.
Quick summing up current experience on making this comparison:
- Good Wikidot-to-other-wikis comparison is published at wikimatrix.com
- Wikidot CAN be compared to non-wiki software (like Drupal)
- because Wikidot is more than wiki
- Long comparison is boring (and would be a copy of wikimatrix eventually)
What I suggest is to divide the comparison not by sections (General, Syntax, Files, …), but by application:
- Wikidot as wiki
- comparing to MediaWiki, other wiki engines
- Wikidot as CMS
- comparing to Drupal and other CMS platforms
- Wikidot as blog
- comparing to Wordpress and other blog systems
- Wikidot as bug tracker
- comparing to Trac, Mantis, JIRA
- Wikidot as …
- comparing to …
Also in each application only list a few features, that really matter, not going too deep in them.
What do you think?
Piotr Gabryjeluk
visit my blog
While I appreciate the matrix, sometimes pure feature list comparisons can be counter-productive because they don't take into account that different types of project need different things. I.e. they don't say why we need certain functions.
A better kind of comparison might come from users with experience of Wikidot and another overlapping product, who can explain precise advantages in one or the other based on their use.
Or, we could look at typical tasks and see how they compare in different products:
- Installation and configuration
- Starting a new project
- Creating a custom look and feel
- Adding participants to a project
- Creating private areas
- Workflow on project pages
- Integration with email
- Uploading files
- Extensibility of core product
- Creating reusable blocks
- Custom listing and sorting of pages
- etc.
This would help drive Wikidot to becoming more useful. Adding features just makes it more complex.
It is also useful to try to understand the target market for different products. For instance, Confluence is more aimed at business users, while Wikidot is more aimed at smaller, more flexible groups.
Wikimatrix tables are …. not very clear. List pages in mediawiki doesn't exist, not by default. There is the dynamic list pages extension but no wiki farm has it enabled because it's heavy and slows down everyone. And all farms running mediawiki has the default 3 columns category pages, which are really bad for many scenarios, specially when categories are categorized and categories listing over 1000 pages.
I think that there is a missconception of considering a wiki anything that has an edit this page button.
http://moinmo.in/WikiEngineComparison
http://mojomojo.org/documentation
Lots of "this wiki has this, that wiki lacks that".
there is one thing that I find it curious, all wiki engines support some features that add functionality to wikis, such as count pages or list all categories. Netcipia runs xwiki, which calls such things "mini-applications". Other wiki engines call them macros, sometimes scripts, or like mediawiki, extensions. Wikidot itself refers to them as "modules" for instance.
I'm testing wikispot, they support tags like wikidot but their implementation is reverse. In wikidot you tag pages and list pages by tag, in wikispot you link a page to some kind of master page, which can act as hub for all pages that link to it. Damn, sycamore lacks html tags, which I really depend on… Sycamore has a different concept, there are no inline styling like mediawiki or mediawiki template definitions, they use css classes instead.