On Mon, Jul 22, 2013 at 5:43 PM, Liam Wyatt liamwyatt@gmail.com wrote:
The concern is not about the validity of the Visual Editor project, or the quality of the work being done, but about the deployment process. Unfortunately, the rollout schedule for the visual editor was determined by the WMF senior management months and months ago. The "1 July defaut for en.wp" deadline was set in stone independently of the status/stability of the software, merely to meet a self-set and arbitrary reporting deadline.
That's an inaccurate characterization, Liam. The original deadline was negotiated with the team (although James only joined as PM in May), and the launch on July 1 by en.wp was also done on recommendation of the team (as were other controversial decisions, e.g. not to provide a disable switch). If the team had said "We need X amount more time to meet Y objectives", we would have moved the launch.
The deadline was not a simplistic "We will go live by X date no matter what", but driven both by the scope of functionality we needed to deliver (e.g. template editing, reference insertion), critical blockers (e.g. dirty diffs, performance), and the date we needed to deliver it by. Based on these three variables, we decided to go forward. Many urgent issues have been fixed quickly since the launch.
I am not saying this to pass the buck, but to simply state that we're in this together. If people on the team felt pressured to do something they think is wrong, they would not have trouble saying so. :-) Instead, what I've been hearing from the team is "It's great to finally have a product out in the world and see real usage and real feedback".
Since the launch, many many new issues have been reported and fixed. Many of the main concerns which are still lingering (e.g. "increased JS footprint") have been fully resolved (VE adds 2.6KB to JS footprint until used). Others (e.g. users accidentally typing wikitext into VE) have been partially addressed.
A lot of things that users report or experience as bugs are almost unavoidable aspects of the introduction of a new editing system. The occasional confusion between the two modes is an example of that. As are the following:
- Introducing a visual editor means that people will do, well, visual editing. That means they may be more likely to make a certain category of mistake (e.g. applying inappropriate formatting, or removing a footnote), and less likely to make another category of mistake (breaking markup completely). It may be frustrating to look at diffs where people do things that they'd never do in markup mode, but it's to some extent unavoidable.
- The uses to which templates are put are truly mindboggling. For example, a route-map template for the Circle Line of the London Underground looks like this:
https://en.wikipedia.org/w/index.php?title=Template:Circle_Line_RDT&acti...
The template for football infoboxes accepts parameters that dynamically render images of football shirts in specified colors:
https://en.wikipedia.org/wiki/Template:Infobox_football_club
Needless to say, these don't look particularly great when run through the new parser, and I'm not especially embarrassed about that.
The number of different citation templates and "standards" that co-exist in a single wiki is equally boggling. Sometimes <ref> tags exist inside a template, sometimes outside. Sometimes {{#tag:ref}} is used instead of <ref>. Etc.
The notion that any VisualEditor would, at launch or soon thereafter, be able to provide an intuitive editing experience for this entire base of content is insane. Nor is it sane to strive for making those types of templates and constructions all equally workable.
Rather, we need to collectively figure out what a discoverable, intuitive user experience should look like. Should subway maps really be constructed from templates like {{BS8-2}}? :-) If we were to use a modern, intuitive design approach for this problem, what would the solution look like? Probably we need to think in the direction of more flexible tools for creating and editing vector graphics.
We're not going to solve these challenges if we lock away VisualEditor into some kind of laboratory and work in waterfall mode for another year. We have to make improvements every day, and get them into production every week, in order to find solutions that make sense.
That's why it's the right decision to get VisualEditor out there now, and to continue to improve it, and that's why I would encourage everyone to not take the easy way out and hide it from their experience, but to keep hammering at it, keep reporting issues, and help us make it the best editing experience it can be.
VisualEditor is emphatically *not* intended to simply be a "nice way for newbies to edit articles". It's intended to become the best collaborative editor for the web, for new users and power users alike. We've still got a long way to go, but we're not turning back.
Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation