About the MediaWiki VisualEditor and simultaneous writing
1. March 2017
With BlueSpice 3 we replace our previous VisualEditor with the MediaWiki VisualEditor, which some people already know from Wikipedia. This raises some questions: Why are we changing now? What potential does the editor have? What about real-time editing?
The new editor has been developed natively for MediaWiki, is technologically based on completely different procedures than TinyMCE and is directly tailored and optimized for use with MediaWikiText.
Markus Glaser, CEO of Hallo Welt! GmbH digs deeper into the matter …
A brief review
BlueSpice 2 was delivered with a TinyMCE editor, probably the most used HTML editor on the web. WordPress and many other open source projects use this editor.
But at MediaWiki you face a special challenge with every editor, even with TinyMCE. Editors like Tiny offer a word-like interface (“Rich Text”) and convert the input into HTML. For MediaWiki, however, the input must also be converted into wiki code. And no available editor offers that. The challenge in adapting an HTML editor to MediaWiki is that this conversion is not unique. There are several possible ways to achieve the same thing. And vice versa, WikiText is very error-tolerant. This means that it does not necessarily meet the common formal requirements for a conversion.
Nevertheless, in recent years we have continued to work on a Wiki code parser that provides this translation service. With the delivery of the MediaWiki VisualEditor this very time-consuming work is no longer necessary and we can finally turn our attention to new topics.
Display: The visual editor in BlueSpice 3
The new visual editor came with BlueSpice 3
With the release of BlueSpice 3 we have delivered the new MediaWiki VisualEditor to our customers.
- The editor has been developed natively for MediaWiki, is technologically based on completely different procedures than TinyMCE and is directly tailored and optimized for use with MediaWikiText.
- This VisualEditor is stable and is tested against the entire Wikipedia. The developers once ran all articles through the editor to find errors.
- There are many features that we have long wished for. For example you can edit templates very comfortable. In contrast to the current version in BlueSpice, templates are not only displayed as an uneditable tag, but you can see the template in edit mode as it looks published. And it gets even better: You can change the content in the respective template directly from the editor. So you don’t have to go to the Wiki code editor anymore. This is very convenient and will fundamentally change and support the use of templates in the Wiki. Up to now, templates were a function for authors with in-depth knowledge, because their use was not supported and you had to understand Wikitext in order to use them.
Unfortunately, table editing is not yet at the level we would like to see. And there are some functions in BlueSpice that we would like to add. But for the BlueSpice users and for our customers this is now an ideal solution.
VisualEditor paves the way to real-time editing
The VisualEditor also offers many technological possibilities for the future. For example, simultaneous writing, as known from Google Docs: several authors can edit the content simultaneously. We had already drawn attention to this development three years ago.
Technically, the problem is basically solved. The developers took the basics from Etherpad and Google Docs. You have to separate HTML from text. 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. But these tags are not visible. You don’t know if the cursor is inside the tag or outside, for example if a word is written in bold.
And this need for tagging causes problems. Suppose you want to comment (“annotate”) a part of text. With HTML, this is terribly complicated, because the tags must be nested symmetrically. A lot of things can get broken very quickly.
The MediaWiki VisualEditor now separates everything into two areas:
- into a pure text layer. Here only the text to be displayed is edited, together with a position specification.
- and into a second layer, which notes markings, e.g. italic letters from position 2 to 7.
The clou: Only at the end of all calculations an HTML page is assembled. Since everything now runs independently of HTML, you can now use your own logic – independent of HTML – to ensure that the markups are placed in the correct position without errors. This opens up many fancy possibilities: Comments, colored markers and more
This is a very simplified and shortened description. But this is the new technology you use when a new editor is developed. The TinyMCE we have used so far is technologically outdated in this respect. The MediaWiki VisualEditor basically has everything you need today.
Problems of the Wikimedia community
The fact that simultaneous writing (real-time editing) is not yet available in Wikipedia and for MediaWiki has to do with specific problems of the Wikipedia communities.
So far, the Wikipedia has followed the principle of “one change, one author”. This is important, among other things, because the currency in Wikipedia is the edits. With real-time editing by several editors at the same time, the question arises as to who gets the credits. Both? The last one? And what happens with intermediate versions? What about versioning and a rollback?
With Google Docs or Etherpad, every change is also versioned. Here every keystroke can be undone. The question is to what extent this behavior – not just a post, but every keystroke is an edit – fits into the philosophy of Wikipedia. This is all unclear.
And another problem is spam: In Wikipedia you can post anonymously. How do you prevent Wikipedia from being attributed to spambots? These are all questions where the developers say it’s not clear and we won’t implement it until we’re told how to do it. And it is to be feared that this will take some time.
But it would be visually exciting if you go to a page and you notice that there are people writing on other corners as well. Then you would have an automatic solution for editing conflicts, which are resolved very cumbersomely today.
If you were a little more casual, there would be good solutions. Again, it is open whether the world outside Wikipedia should not take the first steps here, because simultaneous working is primarily interesting for protocols, brainstorming or drafting texts. It is quite a joke that the Wikipedians themselves use Etherpad and Google Docs for their work. Perhaps this will change when the topic of drafts is addressed.
In any case, an exciting and important area for wiki technology still opens up.