[Wikimedia-l] Feedback for the Wikimedia Foundation

[Erik Moeller]

On Mon, Jul 22, 2013 at 5:43 PM, Liam Wyatt <liamwyatt at 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&action=edit

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