VisualEditor/June 2012 release FAQs

Here are some quick answers to questions about the Visual editor, and in particular the version released in June 2012:

Does this mean you’re going to switch off editing wikitext?

No. We do not intend to remove the ability to directly edit wikitext from the Wikimedia projects. This is about giving everyone an easier editing environment, not about taking anything away.

Note that for the test run, only administrators can directly edit the wikitext underlying the pages in the VisualEditor namespace, to avoid breaking the editor in its current state.

The visual editor will just ‘dumb down’ Wikipedia; it will mean that vandals can edit more easily, whereas genuine contributors already have the passion to learn wikitext.

We disagree. We know [DN: cite sources!] that our existing interface is very complex and discourages new editors, particularly non-technical users. Our steep learning curves (which include user behaviour, ways of working and community policies) are something that the Foundation is committed to easing, and the Visual Editor effort is a key part of that. There are also a number of parallel efforts that the Wikimedia Foundation is working on to help existing community members manage the influx of new users, such as Page Triage and the Article Creation Workflow “Landing System”. By making it easier to edit, we hope to increase the number of editors engaged as long-term contributors, making Wikimedia projects better, growing the pool of people combatting vandals. Poor editing usability is not an appropriate or respectful way to moderate the quality of contributions.

The visual editor demo doesn’t work for me.

Sorry! What we’ve released today is an early demo. Although we have tried to make it stable and functional, we expect that releasing it to you guys will highlight some bugs we’ve not yet spotted. We’d really love for you to highlight when it doesn’t work for you (or doesn’t work as you’d expect it to) so we can fix it — please see our feedback page and help us make it better.

In terms of which particular browsers it should work in, we think that the current major version of the major four desktop browsers — Google Chrome (19), Mozilla Firefox (13), Microsoft Internet Explorer (9) and Apple Safari (5) — should all work fine. As we say below, we think there should be a serious discussion about which browsers we should and should not support, bearing in mind our limited resources but also our goal in making editing Wikimedia projects as easy and open to all as possible, and we would welcome your input.

Please note: the test only works in the Vector skin, and older MediaWiki skins are not currently supported.

The demo isn’t good enough because it doesn’t support <functionality>.

We know! This is just a prototype, and we have focussed on making it stable rather than covering lots of features poorly. We will be adding new features rapidly — we hope to push new changes live every two weeks or so. To help us prioritise which features to work on when, we’d love your thoughts on our feedback page to help guide our work for you.

The visual editor is just for English-language users of Wikipedia and isn’t relevant to me.

No, definitely not. Over time, we plan on rolling out the Visual Editor to all the languages and all the projects of the Wikimedia movement. In fact, we are particularly looking for feedback about how this will integrate with the workflow on Wikimedia projects other than Wikipedia, and for non-Western languages. We’re also keen to discuss how the visual editor works — or doesn’t — for other people using MediaWiki for their sites. We can only make this as good as we want it to be if we know how we can help you, so please tell us how on our feedback page.

Why is the prototype visual editor locked down so you can only use it on one namespace, and only edit that namespace using it?

The prototype is at a very early stage now and we don’t want to break it by letting any wikitext that it doesn’t yet support be inserted into the pages it edits. Locking it down means that we won’t waste testers’ time encountering bugs and missing features we already know about. Once the visual editor has a more complete set of features, we intend to deploy it more widely on mediawiki.org and later on content project wikis, and there it will work in parallel with the existing wikitext editor.

The demo isn’t good enough because it requires <technology>. Didn’t you promise to support everyone / support all browsers with over 1 % share?

This is an important question and we’re not settled on what the answer should be. It covers not just the visual editor but other technology projects related to the Wikimedia projects, and we look forward to having an open discussion involving the community. Our general rule is that we should support reading of Wikimedia projects by all browsers that have at least 1 % of market share. That said, we must make choices about how we spend our resources — should we devote our developers to embedding support for a ten-year-old browser, or for an extension that’s core for Wikipedia? This is why we want to engage the community in the discussion to prioritise our work — please tell us how on our feedback page.

How long until it’s deployed on <my wiki>? What’s your timeline?

We don’t know, and we don’t have a firm timeline. For us, the most important thing is building high-quality, reliable and useful software for our users. We’d rather take an extra month to make it better than disrupt your wiki as a testing environment. But to make sure it’s great (and that we fix things sooner in the project when it’s easier to correct), please get involved on our feedback page and tell us what you like and what needs work.

This isn’t new; you guys had a demo back in December 2011 which was just the same.

Lots has changed — almost all of the code “under the hood” is brand new, as thanks to community feedback we realised that our previous approach wasn’t going to work well enough. However, we agree that right now it appears quite similar to the previous editor’s functionality (with the addition of a “save” button, of course)! That’s why we want to work with the community to help decide what we should work on next to turn the visual editor from a prototype into a fully-featured editing environment suitable for being deployed as the default editor on Wikimedia projects. Please do edit our feedback page to tell us what you like and what needs work.

Are the Wikimedia Foundation and Wikia the same company?

No. Wikimedia Foundation, Inc. is a non-profit charitable organisation dedicated to encouraging the growth, development and distribution of free, multi-lingual content, and to providing the full content of these wiki-based projects to the public free of charge. The Wikimedia Foundation operates some of the largest collaboratively-edited reference projects in the world, including Wikipedia, a top-ten Internet property. The Wikimedia Foundation is funded mostly from donations and some grants.

Wikia, Inc. is a for-profit company that runs the largest network of collaborative published content around video games, entertainment and lifestyle communities. Wikia’s video game audience is the second largest in the world in terms of global unique users and its US-based entertainment audience is one the fastest growing in the world. Both preceding accounts are according to ComScore 2012.

While this section seemed to start out by attempting to address the unseemly relationship between the two organizations (the non-profit being chaired by Jimmy Wales and the for-profit being owned by Jimmy Wales), you'll notice it quite creatively side-stepped the question by offering two bland paragraphs describing each organization.

What coding has been done on the Visual Editor since December 2011?

A lot. Almost every line of code is different because, based on feedback and our technical work, we dropped our previous route of implementing most of the editor ourselves (which we called ‘Edit Surface’). Instead, we’re now using the HTML5 ‘Content Editable’ property, which gives us a lot of useful functions built-in to most people’s browsers, in return for some added complexity. This means that we now have basic mobile editing support, spell-checker, and auto-correct, as these are generally provided by users’ browsers.

The other major pieces of work are having a parser and serializer, and integrating the Editor into the MediaWiki interface. The first of these means that we can now load and save revisions from MediaWiki, rather than just being unable to make any changes. This is provided by Parsoid, which is designed to seamlessly translate back and forth between wikitext and HTML without adding or removing any information in the process. This means that edits made through the Visual Editor and the regular editor should work together without making any unnecessary or unwanted changes to the underlying wikitext. The integration allows in-place editing in a familiar context - key to the goal of the Visual Editor becoming our default editor. We have also made a start on the user interface through which users will be able to interact in a more natural and intuitive manner.

What does the Visual Editor do currently?

For the June 2012 release, the Visual Editor supports basic text, links and simple lists only - there is the specific list of what elements of what wikitext/HTML (“node types”) the Visual Editor supports so far if you want a complete list. As you can see, we do not yet support tables or media files, Categories or Templates, references or redirects, or dozens of other important items, which we will add in the coming weeks and months.

How does the Visual Editor work?

The Visual Editor has several components, and relies on Parsoid:

Parsoid provides a bridge between the saved wikitext and the Visual Editor, exposing an API to load and save documents. It translates documents back and forth between wikitext and HTML5. The document is enriched with additional attributes to help the Visual Editor understand the intent of the elements, and to ensure that changes result in clean modifications of the saved wikitext without loss of information.

The Data Model (dm) converts from the HTML5 document to a linear representation of the structural and content data, and a space-partitioning tree of nodes. This means that inline formatting is applied to each character rather than being provided through inherited elements, so arbitrary slicing of content (such as when a user cuts some content and pastes it elsewhere) is simple and consistent. It also means that each change made to the document can be rolled back, providing the expected undo/redo functionality.

The data structures from dm are used by the Content Editable (ce) module to populate the editable elements, rendering “the document” as a visible piece so that users can interact with it, selecting, removing or inserting content.

Finally, the toolbar and inspector chrome (ui) module allows users to make changes to the document other than direct key presses - such as changing the nature of a node and adding new ones, as well as convenience access to functionality such as cut-and-paste. It provides a basic toolbar that floats at the top of the page, and inspectors which are light-weight in-line dialogs to provide controls for more complex formatting like adding link locations.

Where can I find the code? How can I get involved?

Like all our development, the code we’ve written for the Visual Editor is browseable via gitweb and cloneable from our public git server (including the Parsoid) and is licensed under the GNU General Public Licence v. 2 or later.

If you want to get involved, that’s great — please contact us either through the feedback page or by e-mail and we’ll help you get started! There’s also an e-mail list, “wikitext-l” that you might want to join. Be warned that we’re in early days right now so there may not be as much documentation as we’d prefer!