You have it. Simplicity. I'd settle (prefer) to have a very few 'WYSIWYG' markup buttons that execute wiki syntax underneath. Don't care if it's clunky if the code stays hidden. Maybe an ajax refresh so it's instant-ish. We have hundreds of new users coming, and project tens of thousands. Even with good instruction, it's a bit 1999 to have to teach everybody markup. They *hate* it. When you explain why you're using it, they hate it more because they know they 'should' admire its virtues...
I don't want a lot of markup in the pages anyway. That's the whole idea. Besides which, writers should be writing, not marking up text. There's css and an art department for that.
That's exactly what we are doing in an experimental branch (experimental/coe/). I have modifyed the mediawiki FCKEditor plugin to undrestand the Tikiwiki syntax. That way we store only wikisyntax even if you use WYSIWYG editor...
It works pretty well, but needs some tests refinements before going to trunk...
Hi Goeff!
Thanks for this very detailed report.
M ;-)
I have been using Google Sites through google apps a lot recently as it has suited the needs of some of my smaller clients.
The WYSIWYG interface on that is stunning. Its power lies in the fact that there is relatively little of it - basically what is required to write a wiki page.
I think the problem with integrating FCKeditor or any other pre-made editor is that you are adding a bizarre additional layer on top of your system.
Currently you compose pages in your wiki syntax. These are then parsed and converted on the fly into html. The wysiwyg editor seems to be trying to impose an extra rather than alternative html layer into this mix.
To clean up this I think you need to do one of two things:
Abandon the Wiki-syntax completely throughout the whole system (except for plugins) and just do everything as html
or
Create your own version of a wysiwyg editor that rather than generate html, generates wiki-syntax. You are half way there with the quicktags - you need to be able to see the result on the fly, however, rather than the syntax source.
I have been trying to evaluate wiki systems all over the place (free ones!) for use as the intranet for a game company. Tikiwiki comes closest too what we need. But there are two things which would mean it simply blows the competition out of the water:
1. The ability to not have or see wki-syntax at all. Most of my users (hundreds of them) don't know and don't want to learn a new mark up language - they simply don't have the time.
2. Greatly improve the performance of the Tracker system so it is saleable to thousands of hits.
With those two things and a general simplification of the interfaces, Tiki-wiki could become the competitor to most of what Google is planning. It is as simple as that.
I just wish I was a programmer so I could make the changes. But I ain't!