WYSIWYG Editing
My understanding is that this is not an either/or decision. The decision is whether to allow GUI editing as an option alongside Wiki markup. In that light, many of the pros and cons come down to personal opinion. If some feel more productive using wiki markup they can, if others find the initial learning curve intimidating they can use the GUI editor. If some functionality isn't available in the GUI, then GUI users can either do without, or switch to text mode to add those features.
The key as I see it, is whether the use of the GUI editor to edit a page will remove or "break" existing functionality/formatting on a page created using plain text markup.
I'm not clear on the practical implications of Macros and parsers not being supported in the GUI editor. (from MoinMoin site):
"There are some elements in the MoinMoin markup that cannot be represented as own HTML entities in the editor. These are left as plain text. They are coloured yellow in the editor to show you that they have special meaning. ... The yellow is for your information only and has no further effect. You can just type in these items as plain text although the editor does not recognize them as special and does not color them for you. But when the page is rendered after you pressed Save or Preview these items are recognized."
This text is confusing to me, but my current impression is that you can type in Macros in the GUI editor and they will be recognized when you press Save or Preview. Has anyone tried this out?
I have now had a play in the sandbox and was impressed with the Macro tool. It lets you browse available macros, including their purpose and syntax. Once you choose macro, the macro (with syntax hints) is inserted as yellow highlighted plain text. When previewed, the macros I tested seem to display and work fine. More intensive testing is obviously desirable! -- RicSherlock 2008-08-08 04:23:22
It seems that Moon is making good progress on his Google Summer of Code project. Hopefully a number of the current issues with GUI editing will be sorted by the Northern hemisphere Autumn. -- RicSherlock 2008-08-08 02:10:40
Caveat emptor: these are just a few quirks I noticed circa v 1.5 and they are still there.
no support for important `inline code` style
while there are helper popups such as for macros, links, etc. they are incomplete: eg no way to edit existing macro; for meaning of parameters still need to consult documentation
it breaks existing plain text formatting, eg in sandbox switch to GUI mode; break the first paragraph into shorter lines and insert an empty line before it; switch to GUI and back to Text; observe how it reverted to single line and empty line above removed
It is very hard to produce a very good WYSIWYG editor that would maintain the integrity of the underlying markup. For example, FrontPage does a good job, having set up whitespace and line breaks treatment for each tag and having the split screen mode to keep an eye on what it's doing; Visual Studion only in version 2005 achieved more or less acceptable treatment of source code in design mode. So it is unrealistic to expect it from a simple tool like HTML on-page editor.
A differentiating solution would allow certain pages to be edited in GUI, such as created and maintained by novice users (because it is primarily the argument of entrance barrier while advanced users don't care about GUI); and prevent editing other pages in GUI and only allow Text mode. While there is no such thing as WYSIWYG attribute that can be attached on per-page basis, this can be done as follows: a "TrustedGroup" created, intermediate between EditGroup and WikiGroup, to which people "graduate" when they feel fluent in Text mode, can respect Text mode format and be careful when making changes. Then attaching an ACL for TrustedGroup would require elevated competence to make changes and protect text format integrity.
-- OlegKobchenko 2008-08-10 08:39:51
I think we have to be careful about the use of the phrase "no support", it is non-specific and not very helpful when trying to make an informed decision. For example, from my experiments with inline code in the WYSIWYG editor, although I couldn't work out a way of formatting text as inline code in the editor so it was immediately displayed correctly in the editor,
- the GUI editor correctly displayed inline code that has been specified earlier
- I could use backticks in the GUI editor to specify inline code, after a Preview the text displayed as inline code in the editor
Of the three quirks mentioned, only the last one seems to me to be relevant to the decision of whether to allow the GUI editor as an option.
The ability to identify a page as only editable in Text-mode would be a nice option if possible and would enable us to offer the GUI option while keeping some pages "safe". The idea of using ACL groups to implement something similar is good, but my preference would be to keep things simple if possible. If we decided it was worth trying the GUI editor option, would we be able to trial it first to see what, if any, problems it caused before implementing the ACL groups idea, or removing the GUI option altogether?
-- RicSherlock 2008-08-12 12:25:43
I just noticed the following comment on Moon's Summer of code page. This is the elusive functionality that we discussed above, but unfortunately is still only an idea! It is promising that he is unsure whether the functionality is needed following his updates to the GUI editor.
Don't know whether this is needed anymore after updating the editor. Formerly however on some pages it was not wanted to edit them with GUI edit, e.g. MoinMoinWikis. I had a look at the Mediawiki-project of FCK at http://mediawiki.fckeditor.net/. There they introduced some pragma setting like #pragma gui-edit off which prevents the page to be opend with gui. Maybe this is also something for Moin.
-- RicSherlock 2008-08-19 18:56:39