Wikipedia:Wikipedia Signpost/2013-07-31/Op-ed

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.