The VisualEditor Beta and the path to change
- Erik Möller is the deputy director of the Wikimedia Foundation, the non-profit behind Wikipedia and its related sister projects. This op-ed is the first of two that will examine the new VisualEditor, which allows editing without learning wikimarkup, but has proved controversial for a variety of reasons. (Update, 10 August: the editor who was going to write a response piece has decided that recent changes to the VisualEditor tool have assuaged many of his/her concerns; as such, the planned second op-ed will not be forthcoming.)
- The views expressed in this op-ed are those of the author only; responses and critical commentary are invited in the comments section. Those wishing to submit an opinion piece of their own should email the editor-in-chief at least one week prior to their desired publishing date.
One of the narratives I've heard a lot is that Wikipedia is unable to change, that it's too stagnant, too poorly resourced, too inherently resistant to change. I don't believe that at all.
Here are some of the technical changes we've partially or fully deployed in the last few months:
- mobile editing
- a new login/account creation experience
- a new central login system
- a new language selection experience
- input methods for >150 languages
- automatic font delivery
- a new translation user experience
- article edit suggestions for new users
- mobile web uploads
- mobile app uploads for iOS/Android
- notifications, including user mentions & thanks
- Lua support for templates
- Wikidata support for templates and countless Wikidata improvements (development by Wikimedia Germany)
- and, of course, the VisualEditor Beta.
We've done this with a tiny engineering team by the standards of websites of our reach, working through a mountain of technical debt. We've done it with a QA team of two. We've done it with you. All these changes still need love, for sure.
Wikipedia was inspired by the free software and open source movement. All our software is open source. All the changes we make, the bugs we find, the discussions we have, the things we learn—we share. We continually improve in everything we do, both in what we do and how we do it.
When we embarked on the VisualEditor project, we knew it was going to be the most disruptive change to the user experience in the history of our projects, and also that it was going to be incredibly difficult. Anyone who says "what's the big deal—it's just a rich-text editor, there are a billion of those" doesn't have the faintest clue what's involved.
The single most complex thing to support: templates. What started as a simple idea (re-usable blocks of text) has turned the encyclopedia into a set of programmable documents, complete with a Turing-complete programming language. Every document is made up of in some cases hundreds or even thousands of transclusions that need to be updated dynamically whenever they change.
Because until now, as our software only had to spit out a single document for readers, it has been very tolerant of how templates are used. You can make almost any page content out of templates, including subway maps, football t-shirt graphics, vote result charts, chess diagrams, and of course citations. And templates can literally inject bits of markup into a page that don't make sense in isolation, but perform some function in the context of a table, inside image syntax, etc. (e.g. {{!}} which creates just the "|" that marks the boundary of a table cell).
There are two primary problems with this approach:
- If you edit a page visually, a visual editing environment needs to actually be aware of which parts of the page are templates, needs to properly isolate them, make them editable, and convert them back to wikitext. Depending on just what the template does, this can be very brittle. Encapsulating elements of a larger object like a table inside a template makes it harder to provide a consistent user experience for the whole object (e.g. changing properties of a table cell should always work the same way). Templates that insert code fragments are especially tricky, because you often can't map such a template against a well-defined part of an HTML structure, which means you're fighting against HTML rather than working within its semantic structure.
- Depending on the template's operation and purpose, it may never be possible to make it easy to use in a visual editing environment. A subway map created out of templates will never look useful in a visual editor—visually creating and editing such content just requires a completely different approach altogether (e.g. SVG editing).
When we released the beta of VisualEditor earlier in July, a lot of users were legitimately upset that in many cases, it doesn't yet deliver on the promise of easy editing for everyone; it has bugs (it's a beta) and can be slow especially on large pages, while imposing a new cost to the community:
Besides bugs, a new editing environment means that new types of errors can be made. Deleting an infobox in a markup editor means selecting a whole bunch of text and consciously removing it. Deleting it in a visual editor means accidentally backspacing one time too many. Positioning markup for formatting consciously around text using cursor keys increases precision around spacing and encapsulation of characters. Using the mouse to select text increases the likelihood of certain types of selection errors. And so on.
We've made many changes and improvements already. There are additional affordances we can create to reduce user error. There are changes we can make to the parser to improve its handling of complex template constructions. And in the long run, there are features we can build to make graphics, charts and other rich content easy to create and edit without templates.
We also need to have conversations about the future of wiki markup (yes, there may be uses of markup that will need to be deprecated), about how and whether certain features can even be supported with markup (e.g. annotations, real-time collaboration), and about the unavoidable consequences of having users edit articles in a visual editing environment (yes, there are types of editing mistakes that are inherently more likely in such an environment—others are less so). If you're coming to Wikimania, we'll create opportunities to have these and other conversations with you in person throughout the course of the conference.
Even though it's difficult and disruptive, there was no alternative to getting VisualEditor in front of thousands of real users. While there is more polish that we should have given core features before launching the beta to as many users, I can also tell you with confidence that the level of initial disruptive impact would have been 80% the same even with 3-6 months of additional development effort. Given the level of complexity involved (number of browser/OS/device combinations, amount and complexity of existing markup including templates, types of user actions), there's really no way around it. And yes, we've done tons of automated parser testing on Wikipedia's content, which has enabled us to minimize wikitext<->HTML roundtripping issues.
But as disruptive as it has been, it's also been incredibly useful. The stream of feedback we've been getting is invaluable. The continuing improvement of template metadata is essential. Seeing real-world diffs on a day-to-day basis that show whether a specific thing we're changing has had the desired effect on real-world users (without self-selection bias) is the only way to make VisualEditor awesome. We need to update user documentation, welcome messages, videos, tutorials, workshop resources, etc. etc.
An off-again, on-again approach doesn't work well. We have to keep improving every week, not fall into a pattern where development is largely isolated from the real world impact of its decisions.
Being bold, failing quickly, improving iteratively has been the way Wikipedia has evolved from the very beginning, both in technology and content. I don't believe in the mythology that Wikipedia can't change—in fact, that is all it ever does. I believe in our resilience as a community, and our ability to make it through complex change together.
That said, let's find the best way to do this together, and take the principle of iteration seriously even in how the VisualEditor is deployed. We do have a ton of useful actionable feedback and data that we didn't have a month ago.
And we can make VisualEditor prominently accessible with appropriate caveats, without making it the default primary experience. In doing so, we need to ensure that we maintain a large and diverse number of users (IP address users, new accounts, experienced users) so that we can continually improve VisualEditor under real world conditions and avoid blind spots. We're open to exploring the best ways of accomplishing that goal, and will alter the current beta configuration soon.
One other thing I'm taking away from our beta experience is that we'll need to make it really trivial to set your primary editing experience—whatever the secondary option is needs to be minimally intrusive. Complaints about the section editing experience with VisualEditor are completely valid in that context, for example; the progressive disclosure of wikitext section edit links was a bad idea.
And no, we're not taking markup-level editing away. Some users may always prefer it over visual editing, even if the exact nature of the markup changes, and even if VisualEditor becomes the best tool it can possibly be.
The VisualEditor/Parsoid team has solved some really challenging problems already, but I also recognize that we still have a long way to go. We are listening, and are continuing to iterate, in partnership with you. Thanks to you for embracing change while helping us to get it right.
Discuss this story
This is in response to the feedback we've received, and we hope we can agree on it as a reasonable way forward that adds appropriate caveats and makes it abundantly clear that VisualEditor is beta software, while maintaining a reasonable and representative level of beta usage as we improve it.--Eloquence* 05:46, 2 August 2013 (UTC)[reply]
The storm of negativity from established editors is hard to believe, and makes me suspect that there's an attitude abroad that "if I had to do it the hard way, so should you". Established editors have two buttons to push: one for the status quo edit-box, and one for VE. Apparently this is disorienting and offensive, so it's simple ... please just don't push the VE button by mistake. And while you're at it, your continued helpful feedback to the engineers would be appreciated.
A big thank-you to WMF engineers and any supporting volunteers; please keep up your very good work on this critical project. Tony (talk) 07:57, 2 August 2013 (UTC)[reply]