Wikipedia:Wikipedia Signpost/2013-07-03/Technology report
VisualEditor in midst of game-changing deployment series
The VisualEditor extension has gone live by default to registered users on the English Wikipedia, marking a huge milestone in a project that has taken the best part of a decade to reach fruition. The extension was previously described as "the biggest and most important change to our user experience we’ve ever undertaken" by the WMF team behind it.
WYSIWYG editors, 2004 to 2011
“ | At the moment, we know that very few people who create an account ... ever complete an edit or become members of the community. One of the reasons for this is that Wikipedia, unlike almost everywhere else on the Internet in 2013, expects users to learn a markup language to properly contribute. | ” |
—WMF VisualEditor team |
“ | It would be no overstatement to call it the most significant change in Wikipedia’s short history | ” |
—The Economist, December 2011 |
The idea of a fully-integrated What-You-See-Is-What-You-Get (WYSIWYG) editor has a long history. The associated Meta-wiki page—now a redirect—was created in 2004, drawing on an already significant literature. Much of its content then ("many would-be users of MediaWiki are put off by what looks to them—rightly—to be code of any sort") would not look out of place in a discussion of contemporary developments, and at least one of the page's authors, Gabriel Wicke, has been able to help bring his ideas into fruition as a staff developer. When asked in July 2004 what one thing he'd change about Wikipedia, wiki-innovator Ward Cunningham immediately listed the installation of a WYSIWYG editor.
With much of the web moving its user-facing interfaces over to various WYSIWYG systems in the years following (WordPress went WYSIWYG in December 2005, for example), several WYSIWYG editors—specially tailored to output Wikitext rather than HTML—were created, including a popular fork of FCKEditor (2007). Commercial wikifarms Seedwiki and Wikia were among those to benefit, allowing site administrators to banish wikitext from their wikis as early as 2005.
Nevertheless, the freedom that Wikitext provides editors, the difficulties of working with MediaWiki's evolving and generally idiosyncratic Wikitext-to-HTML parser, and a drive for perfection prevented the introduction of any WYSIWYG editing capability to Wikimedia wikis—at least by default (previous Signpost coverage).
WMF development, 2011 to present
That changed in May 2011, when the Wikimedia Foundation took on the challenge of creating a fully functioning visual editor (a commitment with its origins in the 2010 Wikimedia Usability Initiative and confirmed in 2011's product whitepaper, which described rich-text editing as a "great movement project").
At the time, June 2012 was given as a first release date, albeit for a smaller wiki. Though a working prototype was successfully released on time in December 2011, attracting (mostly positive) attention from the press, including The Economist, PC World and The Verge, the project ultimately got off to a bad start when an early decision to build their own edit surface ("ES") rather than use the (then rudimentary) ContentEditable ("CE") component built into browsers was reversed in March 2012. As a result, users would have been forgiven if they could not see the difference between the first prototype and the second, released in June 2012 on MediaWiki.org. Indeed, months of development restricted to behind-the-scenes code refinements to both the VisualEditor itself and Parsoid—the new and improved wikitext parsers that underpins it—meant that a year after the first prototype and six months after the original deployment target, the team was still demo'ing almost exactly the same feature set as it had always done: bold/italics, lists, links and headings.
Seven months on and the transformation is complete. The editor now includes template prompting, reference tag integration, image handling and category support—in theory at least. The revised timetable, published a year ago, seems to have been broadly kept to, for better or worse. If the trend continues, anonymous users on the English Wikipedia will get the editor next week, users on other large Wikipedias the week after, and all other Wikipedias where compatibility can be guaranteed a week after that—an adventurous timetable, especially given the storm of comment after the initial deployment on the English Wikipedia and the bug reports it provoked. It is not known when users of Internet Explorer will be able to use the editor, though support for recent versions of the browser is planned.
The contemporary debate
Based on an estimated 4 FTEs over two years, back-of-an-envelope calculations suggest the project has cost the Foundation upwards of half a million US dollars. It is hardly surprising, then, that the Foundation stands by its assertion that the VE will help reverse the recent decline in editor numbers. Certainly, there can be little doubt that the VisualEditor will, once any bugs are ironed out, make it easier to edit. Whether that translates into a net positive, however, is more dubious. As Ubergizmo suggested back in December 2011, it is not clear that the edits that Wikimedia wikis miss out on every day because they are too hard to edit are of the high-quality variety, drive-by vandalism, or (more likely) a mixture of the two. Other commenters have suggested that new editors may now be additionally bewildered when learning to use talk pages, which still rely on wikitext. In any case, as more data is collected—a trial on new editors started last week—the question of impact should more or less be laid to rest.
In the meantime, the nature of the present deployment—with its focus on existing users—has shifted the focus of discussion onto the merits of providing the VisualEditor to power users by default. Fueled by the fact that only a gadget (instead of a proper preference) allows editors to effectively hide the VE, along with VE's lengthy loading times, bugs (including occasionally adding <nowiki>
tags without being prompted), and the lack of reference and template support, many immediate comments on the tool's feedback page have been generally negative. "This is yet another botched new feature deployment by the WMF" wrote one; "turn it off and fire whoever developed it" wrote another. Other comments were more helpful, pointing to the lack of integration with features such as the citation toolbar and special character selection, while yet others posted their appreciation for a tool that "has greatly eased [their] editing"; one user explained that he had "given up on editing" many times, and that VE now allowed him to contribute. The results of an A/B test on new users will be forthcoming. At time of writing, the VisualEditor team say they have no plans to reverse the deployment.
Discuss this story
As noted in this posting, there were at least 200 open (unresolved) bugs when VE went live for all logged-in editors. I hope the Signpost will cover the story, in a subsequent issue, of why the WMF development team felt that it was urgent to provide software with so many bugs to every logged-in editor, rather than delaying the rollout and reducing the number of unresolved issues. -- John Broughton (♫♫) 00:58, 5 July 2013 (UTC)[reply]
When the VE has a citation toolbar as good as the one in the previous editbox I will give it another try. It is hard enough to try to get new editors to add references. So adding references needs to be as easy as possible. Doc James (talk · contribs · email) (if I write on your page reply on mine) 02:00, 5 July 2013 (UTC)[reply]