Here's the comment I posted on the article:

My main complaint with most markup-based wikis is the excruciating edit/save cycle. You go and tweak the markup syntax just the way you like, you hit save (or if you’re lucky, preview) to view the result. You find a typo or another change to make, which means you have to hit edit, scroll back down to where you were, and start the process all over again.

WYSIWYG editors, for all their faults, have the ability to do away with this cumbersome edit/save cycle completely. You just edit your page directly (ideally with some good key combinations in order to approach the speech with which you can enter formatted text with traditional markup).

So I actually tried to tackle the problem of making a decent, simple, fast WYSIWYG wiki editor. The result is called Luminotes, and you can check it out at http://luminotes.com/

Let me know what you think.

Dan I replied on my blog, pasting it here too:

@Dan I don’t know - honestly, editing and hitting save didn’t disturb me in the past - like you said there’s always the preview available (and the “only small change” checkbox).

And while I like the experience of editing in Luminotes, there are also some things missing that come with the standard edit-save cycle like comparing versions (diffs) of pages - but, well, perhaps I didn’t find it?

In my experience most people argue against wiki markup from the experience of a try at editing a Wikipedia article - and Mediawiki markup is seriously limited (to say it very friendly). This problem of “oh no, it’s code” needs to be tackled with easy and powerful WYSIWYG editors in time, Luminote sure is an interesting thing to watch.

@Corey I agree with you, how data is stored is important - exporting, migrating and importing (from Word docs, ftw) would profit from standard interfaces - XHTML is very OK with me

sebastian,

  I definitely recommend a wiki that has a WYSIWYG editor on the front, and if the user desires, html on the backend.  As I think you'll find that most business users have a basic understanding of HTML to customize the formating to their liking.  This also decreases the training and adoption of learning a new syntax like wiki markup.  The WYSIWYG editor that we are in the process of implementing in MindTouch Deki is FCK editor and it works well. The editor we are currently using is xinha which is pretty good too.  We are moving away from it for support for browsers like Safari and because it handles formating of pasted content better. I'd encourage you to try a bunch of different wikis and see how the editing experience works for you.

RE: Samepage,

I haven't tested same page but I've looked at the images shown on the WYSIWYG help page it reminds me of the first picture I saw on the www.frogpond.de page given by the opener. This might seem to judgemental and to quickly but I like having less and concentrate on the essential part. I assume that the editor can be reduced in the number of buttons as needed or depending on the features used.

I will though give it (samepage) a try as I like the PDF export capability which seems to exceed most print-CSS to PDF conversions I came across by now.

In early versions of our (yet-to-launch) wiki product, we used wiki markup, but the feedback from our testers, who were mostly experienced computer users but not 'techies', was that they found this a bit tricky and clumsy to use. When we switched to a WYSIWYG editor, everyone was much happier.

We're using TinyMCE from Moxiecode as our WYSIWYG plug-in and find it to be pretty good. It produces HTML - and also offers the option to tweak the HTML by hand for the times when something isn't quite right, or you just want to see what it is doing.  It's free, relatively easy to set up and widely used: so I'd definitely recommend considering it, if anyone is looking at incorporating a WYSIWYG editor into their product.


Bill
www.swirrl.com