This page is superceded by the editor in 1.5, see EditorRedesign and FCKeditor.

Graphical User Interface

If you want your wiki to be successful in a company where many people are still uncomfortable with computers, you need a graphical editor.

There are four ways to edit a page in a wiki:

• text only with markup instructions : this is the way moinmoin works today

• text only with assistance : pushing buttons will insert the markup instructions which are still visible. This is the way WikiPedia works or WikiEdit (WysiwygEditor)

  • There is now a patch which adds this to moinmoin for some types of markup (see MoinMoinPatch section Add a special character inserter helper to the page editor).

• GUI editor : you select a text and apply a change which is immediately visible. Markup instructions are invisible. The final result might be different according to the theme you selected

• WYSIWYG editor : What You See Is What You Get. Similar to the GUI editor, but also takes your theme in account. Perspective is a wiki with a nice (but limited) editor : http://www.high-beyond.com/perspective.aspx?action=all-pages&collection=sandbox

We are going to develop a GUI editor for moinmoin using a flexible javascript html editor which will be configured to convert moinmoin formating into html:

1. create a new action to call the GUI editor
2. use the standard edit lock mechanism to protect the page
3. transform the moinmoin formating into html and put that into the editor
4. edit the text in the html editor (which is built-in in IE/Netscape/Mozilla/Firefox)
5. preview the result using the wiki's features (post text, extend edit lock, display formated text)
6. save the changes (post and release lock)

The first version will implement most (but not all) formating features. For advanced features, the user will have to go to the text mode.

Here are the specifications; if we missed something important, please feel free to make your comments:

• specifications.pdf /Specifications (from specifications.doc)

Macro instructions will be displayed "as is".

If template pages, there are lines that the user shouldn't change (like macro calls) and text that he must add (insert your text here). GUI editors have the possibility to display text in another color according to some conditions. "Don't touch" text should be displayed red and "to be replaced" in green. Macros and anchors can be recognized ( ), but to signalize text to replace you need a new markup which would only affect the GUI editor like double dashes "-- text --" or " text ".

Missing features might be added in future releases according to their importance and difficulty to implement. Macros could be inserted into a page in exemplary form by using a drop down list.

The editor (or at least the preview) might also use the user's CSS files to implement real WYSIWYG.

The advantage of editing in html, is that cut & paste with Web pages or Office or RTF documents would be supported (but that needs filtering of some special tags office puts into that html).

-- JeanJacquesKahn 2005-03-15 10:35:24

It sounds interesting and I hope it's well defined javascript and does not need especially functions only licensed to m$. -- ReimarBauer 2005-03-15 19:40:31

There are quite some GUI (html based) editors out there already. One of them is KupuEditor, another is FckEditor.

As it does editing in html, you have to primarily solve the lossless round-trip problem first - that means that you have to do a transformation wiki to html to wiki without losing or adding any stuff (not even empty lines). If you succeed, you can use such an editor on the html (and in that case, the transformation still needs to be kind of minimal, just adding or removing what was intended by the editing person, no more, no less).

This will be maybe the hardest part of it and it is not really sure if that can be reached to 100%. Also the browser's editor controls slightly differs from IE to Mozilla, introduces some unwanted <br /> sometimes, doesn't handle <p> too well, etc. - so this stuff will need quite some care to get it working like a non-technical user would maybe expect it.

-- ThomasWaldmann 2005-03-22 19:45:23

• Additionally, you need to be able to round-trip comments and meta-markup as well as parser/macro calls. If the browser converts your code representation of them into something else, you have to be able to reconstruct the "meaning".

-- ChrisAkre 2024-05-09 04:51:19

• My company is using MoinMoin currently, and the biggest complaint is regarding wiki markup. We've discussed migrating off of Moin to one that natively supports a gui editor, or figuring out how to use Moin with a gui editor. We don't want to migrate, as we have a significant investment in Moin macros that integrate with the rest of our systems, but we can't justify the internal resources to do implement a GUI editor ourselves. We would be willing to contribute to this effort however, as it would greatly help transition our less techincal users from emailing around word documents to using our wiki.

--Marshall Kirkpatrick marshallk.blogspot.com This is the primary reason I am not advising a non-technical client organization to use MoinMoin. In case you don't know, people who don't even know HTML FREAK OUT at the sight of anything more complex than double brackets. They think of it as "crap" in my experience.

• Just wait to see FCKEditor in MoinMoin. ETA - August 2005

FCKeditor is what they use at Seedwiki, and it's not usable on old macs (pre OS X). Ken at Seedwiki says it's really hard to find a low cost or free WYSIWYG editor that works with PC, Mac and old Macs. If you don't use something readable on old, crappy computers though then many technical non-elites will miss out on wikibliss. Good luck..

• I'm not sure what they're using at http://www.jot.com, but it's the best wiki integration I've seen. I tried seedwiki, but it still required markup to make wiki links. In jotspot's editor (modified fckeditor???) you highlight the words and click. I just got an account today and I have to say jotspot is the most usable wiki I've seen so far. They did a lot of things right. Unfortunately, it's commercial and only a hosting site. I think there's a lot to be learned there with regard to usability.

from: http://meta.wikimedia.org/w/index.php?title=WYSIWYG_editor

If we manage to create a python or php script that converts simplified tidy output (xhtml) to wiki-code, this would be easy to do with epoz. Epoz 0.74 feeds the html through tidy on the server via xml-rpc when switching to source view and on save. This works great, it's Plone's standard editor.

Our conversion script can hook in after tidy, the source visible in 'source view' and submitted to the server would be wiki markup. All without reloading the surrounding page. Creating the conversion script is a challenge, but operating on tidy-cleaned xhtml should simplify matters. Epoz only allows structural markup (no font tags etc), so this is mainly a str_replace(). With the appropriate configuration tidy will strip the complex things first.

This setup combines the advantages of both worlds by providing two views switchable back and forth without reloading the page:

• WYSIWYG view: uses the default css and html editing

• SOURCE view: WIKI source