Click here to edit contents of this page.
Click here to toggle editing of individual sections of the page (if possible).
Watch headings for an "edit" link when available.
Append content without editing the whole page source.
Check out how this page has evolved in the past.
If you want to discuss contents of this page - this is the easiest way to do it.
View and manage file attachments for this page.
A few useful tools to manage this Site.
See pages that link to and include this page.
Change the name (also URL address, possibly the category) of the page.
View wiki source for this page without editing.
View/set parent page (used for creating breadcrumbs and structured layout).
Notify administrators if there is objectionable content in this page.
Something does not work as expected? Find out what you can do.
General Wikidot.com documentation and help section.
Wikidot.com Terms of Service - what you can, what you should not etc.
Wikidot.com Privacy Policy.
I didn't know that.
Nor http://www.wikimatrix.org/ …
I don't think so. It's rather a CMS AFAIK.
Piotr Gabryjeluk, Wikidot Inc.
visit my blog
The version I report here is 2.5.7 of August 2007.
Quick summing up current experience on making this comparison:
What I suggest is to divide the comparison not by sections (General, Syntax, Files, …), but by application:
Also in each application only list a few features, that really matter, not going too deep in them.
What do you think?
Piotr Gabryjeluk, Wikidot Inc.
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:
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.
Portfolio
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.