There is a billion and one wiki engines out there. Some are very simple, others have many advanced features. And almost every single one has it’s own idea on what a wiki syntax ought to be. There is really very little consistency between these engines. Yes, there are 3 major wiki “languages” which are fairly widespread out there:
All of these have strong proponents. For example, Google likes Textile which is used for their Google Code wiki engine. MediaWiki is naturally the syntax used on Wikipedia, so it’s popularity should not even be questioned. And there is some love for Markdown in the Ruby camp as evidenced by projects such as Instiki which I blogged about some time ago. But these are by no means the only lightweight markup languages used out there. There are dozens of them in active use – both in and outside of wiki engines.
Better yet, some wiki developers eschew established standards altogether and invent their own. I’m messing around with DokuWiki right now (which btw is astonishingly full featured for a “lightweight” flat file engine) and it basically uses some sort of Markdown like syntax which nevertheless seems to be quite unique.
In my mind this poses two problems. First one of course is picking a markup language you can live with. I personally can get used to anything – I mean, I hack in Perl and PHP for a living, I write a lot of stuff in LaTex and I actually like lisp. So switching between markup languages doesn’t bother me. But I will say that while they are all simple and easy to learn, they are not all equally intuitive.
For example, the I like the MediaWiki syntax for headings which seems more readable and easier on the eyes to me than the Textile or Markdown syntax:
==This is MediaWiki Heading==
h1. This is a Textile Heading
# This is a Markdown Heading
This is also a Markdown Heading
========================
The MediaWiki creates a fairly unique visual clue, while the Textile syntax is sort of a throwback to HTML which your average wiki user may or may not know. Markdown is somewhere in between, the two but the two different methods of accomplishing the same thing may be confusing to novice users.
On the other hand WikiMedia has kinda ugly syntax for bold and italics:
WikiMedia '''bold''', ''italicized''
and '''''bold italicized''''' text.
Textile *bold* and _italicized_ text.
Markdown **bold** or __bold__, *italicized* or _italicized_
and ***bold italicized*** text
Here Textile is arguably the simplest one, with each style having it’s own unique character – and MediaWiki the worst one, requiring you to count the tiny quote marks. Ugh.
And of course Textile can do something the other two lightweight syntax language can’t – add custom attributes to certain elements. For example to produce an H1 heading with the id of “my_heading” all you need to do is to write:
h1(#my_heading). This is my heading
Which makes it great for people who know what they are doing. All are equally straightforward, but MediaWiki tend to be “clearer” and less scary at the first glance – or rather more plain-text centric. Textile on the other hand lends toward HTML like complexity in some places. So when I’m picking a wiki that is to be used by non-technical folks I usually tend to gravitate towards MediaWiki/Markdown like syntax – since they probably won’t be able to fully utilize all the attribute magic embedded in Textile.
Second problem is migrating from one wiki to another. Migrating data from one platform to another is always a pain so let’s not even talk about that. Let’s assume there is no data to migrate – you are just setting up a new wiki, and it is a different engine than the old Wiki or something like that. Unbeknown to your users and perhaps even to you the markup language in this new wiki may be subtly different from the one they are used to. This issue can be mitigated by picking a popular syntax and then just sticking to it. The little graphical formating buttons on top of the text box also help a little bit to ease users into the brand new wiki environment.
Which syntax do you like? Which is the one you would recommend for clueless users? And of course which wiki is your favorite? If you had to set up a wiki for your personal project, which one would you use? How about for non-technical staff that nevertheless wants to jump on the internal wiki bandwagon? Let me know in the comments.
[tags]wiki, markup, lightweight markup language, textile, markdown, wikimedia[/tags]
What are you developing a wiki for?
It seems like wikis always fight the battle of whether the syntax should be intuitive and simple enough for average Joe, forcing the “web guys” to learn another language, or based on HTML, making it a pain for average Joe but much easier to learn for those who know HTML already. It’s funny, with languages (of any type) consistency seems impossible.
I think markdown is very easy to read but completely unintuitive for me to write, thus, I don’t like it for wikis. Textile is probably my favorite, though I haven’t used it as much as MediaWiki. I think MediaWiki is mostly good, but it relies heavily on HTML entities and I run into the trouble of various wikis using similar, though slightly different, syntax. That’s a pain when going from a pure MediaWiki syntax to something like Trac’s syntax.
I had the “pleasure” to write a program which parses MediaWiki’s text into xml, it was hell… Too many odd variabilities and nuances.
As a python person, I kinda like the ReStructruredText syntax (most of it’s syntax is self-explanatory) but I haven’t seen a wiki which uses it (well, Trac and MoinMoin allow you to use it, but it’s not their default syntax)
ReST does get a big minus point for tables which are too damn hard to write in it…
I have to say that in general, all these wiki syntaxes are bad…
[quote comment=”9414″]What are you developing a wiki for?[/quote]
Internal knowledge base… Or something like that. And not really developing more like shopping for one. :)
[quote comment=”9415″]It seems like wikis always fight the battle of whether the syntax should be intuitive and simple enough for average Joe, forcing the “web guys” to learn another language, or based on HTML, making it a pain for average Joe but much easier to learn for those who know HTML already. It’s funny, with languages (of any type) consistency seems impossible.[/quote]
Yep, I think you nailed it. We can have either simple, intuitive and very limited or complex HTML-ish and hard to learn. Can’t have both in the same language, but everyone is trying to achieve that.
[quote comment=”9416″]I had the “pleasure” to write a program which parses MediaWiki’s text into xml, it was hell… Too many odd variabilities and nuances.[/quote]
Actually I’d say parsing most loosely structured markup languages is a pain. At least in HTML you have a DOM tree – so at least there is some structure there. These languages have no structure at all.
I’ve used MediaWiki for a couple of years, so I’m used to doing things their way, although in the ideal world, I’d prefer a combination of MediaWiki’s and Textile’s markup syntax: Textile’s bold/italicisation syntax, and pretty much everything else using MW’s.
However, I did a quick search on MediaWiki’s Meta wiki and found this: Extension:AlternateSyntaxParser – if nothing else, it should mean you could just copy and paste the raw (unformatted) code and markup for existing wiki pages to import them manually into MediaWiki (if no automated importer exists).
For lusers/idiots/n00bs goes, why not try a WYSIWYG editor extension – this one, for example?
(Off-topic: not updated your Ubuntu install to Firefox 3 yet? :P)
I thought firefox 3 was default on the new Ubuntu… it was for me.
I don’t think WYSIWYG wikis are only for n00bs. I develop a WYSIWYG personal wiki called Luminotes at http://luminotes.com and many of my users are familiar with both WYSIWYG and traditional wiki syntax. But they prefer WYSIWYG for the reasons mentioned in the post above: There are simply too many incompatible wiki syntaxes out there.
[quote comment=”9423″]I thought firefox 3 was default on the new Ubuntu… it was for me.[/quote]
I’m still on Gutsy. Kinda scared that an upgrade to Hardy will wreak havoc on my work laptop which I need for working and work related stuff. :P
@Dan – hey, nice! Very Gmail like in appearance. :)
@Luke – This… coming from you? Mr “blah blah blah, thats half the fun about linux is if you break it… you just have to fix it.. .blah blah blah, never be afraid to experiment blah blah blah” guy?
and have you tried:
http://moinmoin.wikiwikiweb.de/
I dig it
Yeah, tinkering and breaking things can be fun. But I’d rather not have to fix a b0rken system it while under a deadlines. I nothing should really happen but then again I’d rather not risk it. :)
@Luke: I’ve been told that Luminotes looks like a cross between Google Notebook and TiddlyWiki. I’m not sure whether that’s a good thing. :)
We use Confluence, from Atlassian. Very nice, has a WYSIWYG interface (that none of us uses) and is lightweight enough. Also, it integrates with various other applications, which is a major plus in business use. The only thing I don’t like, it’s their way of entering links, which is reversed from other Wikis I use (title first, URL next).
I’ve used Mediawiki, Trac’s wiki, and some ultra lightweight wikis (the kind that use CamelCase… ugh)
I love mediawiki, it just feels intuitive to me, and although the ””’ thing is daft, the rest of it feels right. What I love about it is the bullet/numbered points thing. I write a lot of dot point how-tos and troubleshooting guides, and mediawiki just seamlessly nests them along with some other simple formatting. It just makes sense to me.
Trac is like a bastardised, harder to use mediawiki. To make a numbered bullet point in mw, it’s just “#”. In Trace, it’s ” 1. ” – you have to have a space before and after and a period… one wonders why they bother to even manage the numbering for you…
As for Heron, I was on Gutsy on an nvidia card. Everything was working and I had Compiz working nicely. Having had backups I decided a totally fresh install was a better way to do the Heron install… which left me with a 640×480 screen. After two hours of troubleshooting, dpkg-reconfiguring, determined to ‘end-user’ fix it without manually editing the xorg.conf, I finally gave up and looked in it… and it was nearly empty despite several attempts at regeneration. Pulled across an xorg.conf from a debian box and it all worked magically at that point.
You haven’t lived until you’ve been limited to 320×240 on a 24″ screen in gnome… with it’s mandatory wharves…
Oh, my! I wish I had the luxury to debate wiki-syntax at work! As for now, I still fight to convince my colleagues that we do indeed need a wiki (for internal knowledge base too, working on GIS system)…
Wait, no… I’m still trying to make them understand what a wiki is, in the first place! Jeez!
[quote comment=”9436″]Oh, my! I wish I had the luxury to debate wiki-syntax at work! As for now, I still fight to convince my colleagues that we do indeed need a wiki (for internal knowledge base too, working on GIS system)…
Wait, no… I’m still trying to make them understand what a wiki is, in the first place! Jeez![/quote]
LOL! Actually my coworkers don’t know they want a Wiki. They just want, you know – like a collection of knowledge. Like an information thing, where you can like click and expand things in more detail. They want like huge, huge amount of documents, writeups, files, samples in there and have it like organized and linked and searchable. And make it so that it can be expanded by anyone – not just programmers. They are leaving “implementation details” to me cause I know stuff.
To me they are describing a wiki – but then again, this may just be a temporary insanity or something.
Oh, and I believe they are sort of expecting me to wave a magic wand and populate the wiki with (and I quote) “unbelievable amount of information” without actually allocating time and man power to contribute to it. Unfortunately there is no way for me to do it, because I do not possess the information they want to organize or catalog, because my expertise is in IT/Software Development and not in the inns and outs of Asset Based Lending related stuff (whatever they want to put in the wiki).
Oh, you want a wiki for work? Been there before — here’s a quick summary:
MoinMoin — very nifty indeed (use it for my personal wiki)
PROS: WYSIWIG
CONS: slows to a crawl with 100+ pages — this is bad for a work wiki. Trust me, you’ll get to that many pages very quickly on a work wiki.
Twiki
PROS: WYSIWIG editor + tons of extensions
CONS: many of those extensions don’t work. Hard as heck to set up and it seems to be dying.
You may want to try MindTouch — it looks really sweet — that’s going to be my next work wiki…
As for textile vs markdown vs mediawiki… I used mediawiki in the past with moinmoin (it’s similar). I now use textile because it’s way more readable. (When you read an article, *bold* interrupts a lot less than ”’bold italic”’ … As for the h1, h2, headings — most people are already familiar with them if they use Word or OpenOffice.)