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? Continue Reading
Did you know that in the user settings every user is able to activate the visual editor by default?
So if you are a „WYSIWYG-worker“ you should enable the setting „visual editor“ in your user preferences in the BlueSpice tab. Everytime you enter the edit mode of an article, the visual editor will show up first.
On the other hand, if you are constantly working in the wikicode, you should disable the default use of the WYSIWYYG editor.
Visual Editor – Wikicode is supplanted
Anyone who has written or improved Wikipedia articles in the last few years, already knows about the Visual Editor, which has now reached a certain maturity. (See the post by Nathalie Köpff on this subject). Creating such an editor is a big project. Unlike other web applications, an editor for Wikipedia must not only work with different languages (for example right to left languages), but also be able to process the multitude of wiki functions, the template system, the magic words and many more things besides. So for this, the wiki text parser Parsoid needed to get a totally new technological basis. As Wikipedia develops further through web standards (browsers, protocols, languages), the task will remain a complex one for a long time. However, it is also a rewarding project which has significance for the whole web community – as, for example, no commercial provider would develop an editor for over 100 languages and make it available for free.
Nevertheless, the project is still controversial in the Wikimedia community to this day. This is partly because the introduction of the editor has lead to significant complications. The editor was simply not ready to use when it was implemented for the first time.
The scepticism in the community towards the editor, however, also has to do with the fact that its increasing use allows for a wide reaching dropping of Wikitext. What, for some, is a good opportunity is, for others, a loss of design potential. As up to now, it was possible to build many small tools with the standard resources (for example templates or overview lists). Even simple formatting is significantly more efficient for experienced wiki text users.
However, over time, Wiki code, which should make editing easier, has almost had the opposite effect. Editing a wiki article needs a certain amount of experience and skill. This is, however, not sensible, as many hand-made functions can be done more elegantly with corresponding extensions.
A great deal of identity and a bit of wiki philosophy is attached to the transition to the visual editor. For some wiki authors, it may be a restriction, but for the wiki world outside Wikipedia, it is a great leap forward. The standard ways of using wikis have changed; most wikis work in much less complex ways than Wikipedia, which has always been a special case with its own particular demands. For this reason, a native visual editor is a long overdue step for many MediaWiki users. It is necessary so that wikis can be used to build up new free knowledge hubs on the web.
Simultaneous editing of texts
A further, very ambitious project was introduced at Wikimania 2014. The aim is to enable the simultaneous editing of texts, that one already knows from Google Docs. This has been considered for a long time. However, the necessary resources for the project were not there. Now, the Deputy Director of the Wikimedia Foundation, Erik Möller, has announced that the first prototype should already be available in a year. This is very exciting news.
Two points are not being discussed at the moment, but could become important in the future.
- Speech2Text: Texts in wikis should be increasingly possible to dictate. “Speech2Text” is developing into a standard as the speech recognition software has made great strides in the last few years. We will see that speech-control can be performed in Google search.
- Draft function: On top of this, a real draft function is needed for MediaWiki. Every trust and NGO with local groups needs to be able to develop texts for projects, for example. Up to now, they have been diverted to Google Docs or Etherpad. But these two applications are totally inappropriate for the public collection of knowledge for a number of reasons.
For this reason there should finally be the chance in MediaWikis to edit a first drafts with just a small circle of authors before the text is released generally.
Overall, we at Hallo Welt! see this development as very positive as MediaWiki will become more user friendly. Using it will be more intuitive and working with the editor more stable. Our enterprise distribution will take these developments on, customise them and make sure they are continually developed.
WYSIWYG (What You See Is What You Get): The visual editor enables writing and formatting in your wiki without the use of wiki mark-up characters. You can often see the phrase “write just like in Word” in marketing texts even though, to be honest, this often gives the user false expectations. One should always keep in mind that this is and remains a browser-based system. Nevertheless, the visual editor makes writing and formatting in the wiki a great deal easier.
The wordsmiths in Wikipedia (which runs with the wiki engine “MediaWiki”) had to wait for such an aid for a long time. Despite many initiatives, Wikipedians have had to craft their knowledge into articles without a visual editor until very recently. Finally there is now a visual editor in the Wikimedia projects (Extension: VisualEditor) available as a beta. This is updated each week and can generally be activated when the user wants it.
We present three editors below. There are further editor extensions listed, for example on mediawiki.org, however, they have generally been discontinued or are at least no longer being followed up. (To see a larger version of a screenshot, simply click on it).
Extension: Wiki Editor
This extension is currently being deployed and is delivered with MediaWiki from Version 1.18 on, in order to make editing a little easier. The essential functionality is to insert wikicode characters at the touch of a button, which then only need to be edited. Therefore, one does not need to remember the code, but one still has to understand it. This means it only makes editing easier under some conditions and is not a real WYSIWYG editor.
Extension: Visual Editor
There is no visual editor currently being delivered with MediaWiki. However, on the development platform “mediawiki.org“, there is a developer initiative for a rich-text editor for MediaWiki. There has been an initial beta version on this platform itself since 2013 with some of the essential functions, which, however, is targeted specifically for use in the Wikimedia project “Wikipedia”. This editor is now also available on all versions of Wikipedia as a beta feature for all users who are logged in.
The editor makes a very good impression, even though it is still obviously a beta version, and some essential functions like, for example, the table function, are missing – which for me is one of the main reasons for having a WYSIWYG editor. Here is a little information on a few select functions which I need in my everyday work:
Inserting media is very easy here, as an initial selection of suitable pictures is filtered in advance from the system using the article title. This can be, but is not always, useful. Uploading pictures is just as laborious as before. One needs to change page, calling up the upload page which is separate.
This is rather annoying, particularly at the start. After time you get faster and keep the upload page constantly open in a separate tab, then you can save a lot of time with disconnected uploading. One can already insert templates via the visual editor presented on mediawiki.org.
This also seems very easy at first glance. Initially, only internal links are suggested, these being subdivided into new page, redirects, disambiguation pages and suchlike. What one does not see at first sight: if you enter the URL of an external page, this will be recognised and entered as an internal link.
If one begins to type a name in the field, but then interrupts this (for example by clicking outside the dialogue), then what you have typed will be accepted as what is known as a red link. You have to make sure that you remember to click on cancel in the dialogue.
Changing between WYSIWYG and code
Suppose I want to check or change something in the code and then carry on working in WYSIWYG. Then I have to save the page first and then reload it. I find this irksome.
Visual Editor from BlueSpice for MediaWiki
BlueSpice has come up with a fully developed WYSIWYG editor including table functions and business-specific adaptations. I am now writing a lot in Wikicode but the well-organized WYSIWYG editor is worth its weight in gold, especially when writing tables. Checkboxes and checklists can be inserted which is very helpful for company wikis with minutes and to-do lists. On top of this, the editor includes a spell checker from Version 2.22.2 on. You can also switch between WYSIWYG and wiki code whenever you like by pressing a button. For this reason we do not discuss this further here.
You can search for files you have uploaded in the dialogue for inserting pictures and other files. You can specify the size, link destination, borders, etc. before inserting a picture. Furthermore, there is an upload tool. This means you can upload a file, assign it a category, and insert it in two steps all on the same page. If you have the package [paste image], then images can even be pulled into the editor with drag and drop. The only annoying thing is that sometimes the picture you have inserted is not displayed with the right configuration immediately. However, one can see if everything looks right by going to the preview.
There is also a tool for inserting categories, like in the MediaWiki VisualEditor. However, in BlueSpice, this dialogue can also be called and used when in the reading view without having to change to the edit view.
The dialogue for inserting links is subdivided into several types of link. I can choose a namespace, article name, description, or enter one (for example when creating red links). If one chooses a namespace, then in the field underneath the pages will be automatically sorted for you to choose from. What is missing, in comparison to the MediaWiki editor is the differentiation for redirects and so forth. This, however, plays a much larger role in Wikipedia than in company wikis.
Working with tables
The number of rows and columns can be entered easily via the toolbar. If a table in the article is selected, then further table-specific functions are shown in the toolbar such as insert column or row.
The table can also be given a design (formatting), also just with a click in the toolbar. The table will then be given the correct properties, from colour or the possibility for the user to sort the contents to the properties of a normal contents table. As several designs can be used simultaneously, this can, however, sometimes lead to confusion.
Furthermore, the right mouse button lets you specify properties for the whole table, row, column or cell. You can also merge selected cells here. The width of columns can also be fixed, as a percentage of the browser width or as a number of pixels. However, be careful: it is not possible to define the column width for each row.
The table functions of this WYSIWYG editor are valuable when you need to create complex tables or for tables which need to be edited regularly (for example to-do lists).
The Wikimedia development team is on the right road. We (the development team at Hallo Welt! – Medienwerkstatt) are waiting eagerly for the day when we can switch to using the MediaWiki editor, as the development of a reliable editor is very time-consuming. At the moment, however, there is no way we could contemplate this. Directly comparing it with the visual editor from BlueSpice, we find that the BlueSpice editor has more of the important functions, particularly for enterprise wikis and came out of the beta phase a long time ago. Alongside this, the WYSIWYG editor from BlueSpice also works with Internet Explorer (IE 9 or higher). This is important for many companies, as the use of Internet Explorer is compulsory in many companies. IE compatibility is on the roadmap for the VisualEditor from MediaWiki, but it is not yet usable. The visual editor is initially not even activated in Internet Explorer.