http://www.accmanpro.com/2008/07/16/wordpress-26-much-to-like/

points to a bad experience by Chris Brogan

http://www.chrisbrogan.com/quick-note-wordpress-26-beware/

but that sounds like a one-off.

Within the firewall I have some sympathy with the idea that the crucial early adopter advanced users can get cut off at the knees by poor implementations of WYSIWYG which produce unfathomable html code at the edit source level, rather than convert back into WikiText. So the proposal to provide a choice of editor is often in reality a one way migration.

Back to WordPress, if programs such as Dreamweaver can provide good switching between html and wysiwyg views without messing up the code too much then why not blog authoring and wiki editing tools?

2. You can use WikiSyntax if you like but that shouldn’t be the barrier to creation. Why should there just be one format? And WYSIWYG is far from being the “lowest common denominator”, they’ve just been very badly implemented at the moment.

One exception is Deki wiki which has made the best stab at a properly integrated WYSIWYG tool. And by the way it’s built on MediaWiki.

3. Just because the big wikis use it, it doesn’t make it right. How do you know there aren’t a billion passworded wikis that don’t. As I’m frequently told, size isn’t everything.

Addendum: Of course every wiki would benefit from adopting WYSIWYG, but I wouldn’t necessarily want it to be *forced* on the authors… unless it’d been a bad day

What I’m really getting at is that WYSIWYG die-hards can’t seem to recognize that it’s not the best in every use case. I do really like it in some contexts, but not every wiki would benefit from adopting WYSIWYG.

2. I groan whenever I hear people yammering about how WYSIWYG is the ideal for wikis. Your argument especially devolves for me in the context of Wordpress-as-wiki. HTML is just as (if not more) inscrutable than MediaWiki markup. I don’t use a reference sheet for wiki syntax, but even if I did, the fact that there’s a community supporting you in contributing to a MediaWiki site means you don’t have to know wiki markup to contribute. But if I want to build decent looking templates and tables (for example) that are properly flexible (WYSIWYG currently allows you make such things, but it’s not variable enough by a long shot), then I want the capability. WYSIWYG editing is playing to the lowest common denominator by pleasing newbies and luddites and cutting off advanced users at the knees. If you look at the actual data of who contributes the most good content to the successful wikis, it’s a core group of users (less than 1% of total editors, in the case of Wikimedia). If you want a wiki to be successful, enable them.

3. It’s not unproven. All of the biggest wikis in history use MediaWiki, while many of the (comparatively) smaller early ones use CamelCasing. For me, I guess it all comes down to the fact that you cannot escape the fact that all of the biggest and best wikis in history use MediaWiki. No organization forced users to tolerate it, and Wikipedia could easily have died if people rejected MediaWiki. But they didn’t. Saying MediaWiki is not the best option out there for creating a wiki belies the obvious truth in the numbers.

1. CamelCase doesn’t have to confusing to the reader, they can, be automatically expanded so they look and feel like a normal link. What then becomes interesting is that CamelCase can become confusing for the author, in that it’s difficult to remember whether you want to link to ThatVeryCoolThingOfMine or MyVeryCoolThing.

In both the above cases, the tools can be made to support reading and writing (how about type-ahead on WikiWords?). MediaWiki, although being 2nd best wiki out there is still a bit shit on both scores.

2. You don’t necessarily need to disambiguate WikiWords and links, again, if the tools are good. For me, the only Wiki Syntax you should really need to know is CamelCase… and this should be optional, allowing the use of simple WYSIWYG alternatives where appropriate. Rmemember what wiki means? It means not having to refer to a WikiSyntax sheet for a language that’s become almost as complex as postscript.

3. Saying that CamelCase works better in smaller organisations is a. nonsense and b. unproven. In larger organisations there are always communities with a narrower interest. What CamelCase-ing does (when used) is force people to think of “the best title” for the page they are creating… which in turn is very useful when trying to create a wiki that mimics Design Pattern Language thinking (like Yahoo have done). Being forced to give a resource a meaningful, catchy and memorable name can be a good thing that helps the content being created get found later.

And as for your comment about speed. I made a tool that sync-ed a Desktop Gui Wiki tool called VoodooPad with Wordpress (via xmIrpc).. which meant I could write as fast as my gob is… without the speed hit of working with a web-based application. And that’s fast!

You’re right that Wordpress won’t replace MediaWiki. Hopefully something usable with replace both of them.

Also, CamelCase is beyond outdated for three simple reasons: it’s confusing to the reader, you can’t disambiguate links ([[newname|name]]), and in a very large wiki page it is hard to pick out when editing. CamelCase works well in very small wikis that are meant for community organization and discussion, but not larger ones that need to produce a finished product.

Do you encounter any plugin that doesn’t work?

Still, good news, thanks for keeping us posted.