Create texts together: about MediaWiki VisualEditor and simultaneous editing

Biswarup Ganguly, Visitors are checking the Laptops at Infocom 2004, CC BY-SA 3.0 oder GFDL, via Wikimedia Commons

Biswarup Ganguly, Visitors are checking the Laptops at Infocom 2004, CC BY-SA 3.0 oder GFDL, via Wikimedia Commons

With BlueSpice 3, we replace the previous VisualEditor with the MediaWiki VisualEditor, which some people will already know from Wikipedia. This leads to questions, for example: Why are we changing now? What potential does the editor have? And what is the situation with real-time editing?

What advantages does the new VisualEditor have?

BlueSpice 2 is currently delivered with a TinyMCE editor. This is still a very good choice. TinyMCE is probably the HTML editor most often integrated on the web. WordPress and many other open source projects use this editor.

However, with MediaWiki, there is a special challenge for any editor, even TinyMCE. Although editors like Tiny offer a user interface a bit like word (“rich text”) and transform the input into HTML, the input for MediaWiki also needs to be transformed into wiki code. And this is not offered by any available editor. The challenge of tailoring an HTML editor to MediaWiki lies in the fact that this transformation is not unique. There are different ways of achieving the same thing. And, on the other hand, WikiText is very tolerant of errors. This means that it is not forced to comply with the usual formal requirements for a conversion.

Nevertheless, over the last few years we have written more and more for a wiki code parser which does this translation. MediaWiki VisualEditor makes this time-consuming work no longer necessary, freeing us to turn to new topics.

So we are very pleased to be able to deliver BlueSpice 3 with the new MediaWiki VisualEditor:

  • The editor is a native development for MediaWiki, based on completely different technological procedures to Tiny MCE, and is directly tailored and optimised for use with MediaWikiText.
  • This VisualEditor is stable and tested on the whole of Wikipedia. The developers have run every article through the editor in order to find errors.
  • There are many features we have been wanting for a long time. One can, for example, edit templates very conveniently. In contrast to the current version of BlueSpice, templates are not only given a non-editable tag, but in the edit mode one also sees them as they will be published. And it is even better: one can change the content of the template directly from the editor. In other words, one no longer needs to transfer to the wiki code editor. This is very convenient, changing and supporting the use of templates in the wiki. Up to now, templates were a function for authors with deeper knowledge only, because using them was not supported and one needed to understand wiki text to use them.

Unfortunately, editing tables is not at the level which we would like. And there are some functions in BlueSpice which we would like to extend. But for the BlueSpice users and our customers, this is an ideal solution.

VisualEditor smooths the way towards real-time editing

The VisualEditor also offers many technological possibilities for the future. For example, simultaneous writing, as you may know from Google Docs, where several authors can work on content at the same time. We already drew attention to this development three years ago.

The technical problem has been solved in principle. The developers have adopted the foundations from Etherpad and Google Docs. The HTML must be separated from the text. Going back to TinyMCE: this editor writes HTML in the background. This means that the author writes a text and the editor sets special characters in the background: the HTML tags. You do not see these tags, however. You do not know if the cursor is within such a tag or outside it, for example when a word is written in bold.

And this necessity to mark up the text brings problems. Suppose that we want to add an annotation to a text segment. This is awfully complicated with HTML because the tags need to be nested symmetrically. This can go wrong very quickly.

The MediaWiki VisualEditor separates everything into two areas:

  • a pure text level, where only the text to be shown is edited, together with an indication of the position;
  • and a second level, where the formatting is noted, for example cursive script from positions 2 to 7.

The point being that the HTML page is only built after the end of all the computations. Because everything runs independently from HTML, one can use ones own logic, which is also independent of HTML, to ensure that the mark up is placed in the right places. This opens up many clever possibilities: commentary, coloured marking and much more.

This is a very simplified and concise description. But that is the new technology which one uses to develop a new editor. TinyMCE, which we have been using, is technologically out of date, from this point of view. The MediaWiki VisualEditor has, in principle, everything you need today.

Problems specific to the Wikimedia community

Simultaneous writing (real-time editing) is not yet available for Wikipedia and MediaWiki. This is due to the specific situation of these communities.

In Wikipedia, up to now, there has been the principle of “one edit, one author”. This is important for a number of reasons. One is that the currency of Wikipedia is edits. For real-time edits by several editors at the same time, the question arises who gets the credit? Both? The last? And what happens with interim versions? What happens with versioning and rollbacks?
Every edit in Google Docs and Etherpad is also assigned a version. Here, every keystroke can be undone. The question is how far this behaviour – not only a contribution but every keystroke is an edit – fits into the philosophy of Wikipedia. This is not clear.

And another totally different problem is spam: anyone can post in Wikipedia anonymously. How does one stop spambots writing on Wikipedia? These are all questions which the developers say remain unclear, and they cannot proceed until they know what they should do. This may well take a long time.

Alongside this, it is interesting to imagine the impact when one goes to a page and notices that other people from other places are editing it at that moment. Also one would require an automatic solution for edit conflicts, the present one being resolved very intricately.

If one were to approach it a little more casually, there would be good solutions. It is an open question whether the world outside Wikipedia will have to go the first steps, because simultaneous editing is primarily interesting for minuting, brainstorming or drafting. It is a bit of a joke that Wikipedians themselves use Etherpad and Google Docs for their work. Perhaps this will change when the topic of drafting is gone into.

In any case, an exciting and important area of wiki technology is opening up.

Leave a Reply