[Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

[Erik Moeller]

On Wed, Jul 31, 2013 at 1:41 PM, Andreas Kolbe <jayen466 at gmail.com> wrote:

> I mean, look at how Jimbo sold the VisualEditor to the press at the start
> of the roll-out:
>
> http://www.telegraph.co.uk/technology/wikipedia/10196578/Wikipedia-introduces-new-features-to-entice-editors.html
>
> ---o0o---
>
> “VisualEditor is a user interface that is much more familiar to people.
> When you click edit you get something that looks very much like any word
> processor, and you can change things and do whatever you want.”

Except that of course the narrative you're trying to establish here is
completely wrong. Wikimedia Foundation did not launch VisualEditor
with great fanfare, promising a panacea of perfect and beautiful
software. We announced it through a single blog post, inviting
feedback and support with the rollout. We launched a community portal
which had the following statements on it from day one:

---o0o--- (I like your quotation markup, let's add it to wikitext .. j/k)
At the moment, the VisualEditor has a number of bugs; this is
inevitable. The only way to only deploy software when it is bug-free
is not to deploy it at all - we're still finding errors in MediaWiki,
and that's 10 years old. If you encounter an issue, please do not
hesitate to report it on the Feedback page. There are also some areas
where we still have to build entirely new features. Current
limitations include:

* Odd-looking — We currently struggle with making the HTML we produce
look like what you are used to seeing, so styling and so on may look a
little (or even very) odd. We're increasing the time we put into this,
but so far our focus has been on making sure that the VisualEditor
does not alter wikitext unexpectedly.
* Incomplete editing — Some elements of "complex" formatting will
display and let you edit their contents, but not let users edit their
structure or add new entries – such as tables or definition lists.
Adding features in this area is one of our priorities.
* Limited browser support — Right now, we have only got VisualEditor
to work in the most modern versions of Firefox, Chrome and Safari. It
does not work in very old versions of each browser, and does not work
in Opera, although a volunteer is working on Opera support. Internet
Explorer currently does not work, but we aim to have support for the
latest versions of IE by the time we release the VisualEditor more
widely.
* Articles and User pages only — The VisualEditor will only be enabled
for the article and user namespaces (so you can make changes in a
personal sandbox). In time, we will build out the kinds of specialised
editing tools needed for non-articles, but our focus has been on
articles.

Because of these limitations, and inevitable bugs, we recommend that
users click "review your changes" before saving the page, and report
any problems they encounter.
---o0o---

This list has been community-updated since then and is a transparent
and honest reflection of the known areas of improvement.

In terms of media, when we've received inquiries, our response has
generally been "We're still in beta, talk to us in a few months". The
article you're quoting from is a single story that's about "new
features" that WMF is launching, of which VisualEditor is one; it also
discusses Echo and Flow. It also includes the following quote from
Jimmy about the VisualEditor.

---o0o---
“This is version 1.0, which means it is the first one that has really
had mass adoption and mass use,” said Wales. “We've had a lot of
feedback and there's going to be a lot of upgrades and changes, and
we're investing a lot in that kind of thing.”
---o0o---

The VisualEditor itself has a "Beta" button which, when clicked, shows
the following text:

---o0o---
VisualEditor is in 'beta'. You may encounter software issues, and you
may not be able to edit parts of the page.
---o0o---

Is the Beta notice too small and obscure? Fair criticism. But if you
want to claim that we're somehow misleading users about the state of
VisualEditor, you'll have to do a lot better.

> I also don't understand why the Foundation would need any more feedback at
> this point in time.

James has written a very good and detailed response to this here.
Please read it:
https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:VisualEditor/Default_State_RFC&oldid=566666714#Suggested_changes

In a nutshell, it's not about volume of feedback, but about iterating
with a representative real world set of users, rather than in
isolation. In terms of volume, right now we're dealing with a
firehose, which is more than we strictly need, but has the huge
advantage of being an unbiased sample of users. We understand it's
very disruptive, which is why we've been responsive to RFCs and
community consensus asking us to slow down. But we can't do it with a
trickle of self-selected users. We need a steady stream of real user
interactions and user feedback from different groups (IPs, new users,
experienced users) in order to iterate effectively. That's not trivial
to accomplish, but we'll try finding a middle-ground between the
current beta and the previous alpha.

If you're from old-school enterprise software engineering, you might
be looking at this process and wanting to gouge your eyes out. You're
deploying every week, sometimes every day? You're fixing bugs in
production the same day you write the fix? Crazy! Where are the
hundreds of pages of specs? Where's the Gantt chart schedule with
dependencies? Madness! Well, guess what - VisualEditor is being used
for >800 edits per hour at peak on enwiki alone, while your imaginary
waterfall software project is stuck in integration hell. And by the
way, all these bugs you thought you'd fixed? Turns out you haven't.
And that user experience you designed, which looked so great in the
spec? Turns out users have no idea what you were trying to do. Welcome
to the web, baby.

There's a reason every start-up on the planet follows the idea of the
Minimum Viable Product like a religion. There's a reason why Reid
Hoffman, who founded a little company called LinkedIn, said: "If you
are not embarrassed by the first version of your product, you've
launched too late." There's a reason why "release early, release
often" became a mantra in open source development. There's a reason
why waterfall development isn't used for real-world web development by
anyone who knows what they're doing.

If VisualEditor was a piece of software on a shelf that won't get a
new release until mid-2014, then the idea of "You've got enough
feedback, time to work by yourselves for a few months and then
re-release" would make some amount of sense, because that's the only
choice you have (it's brought us many wonderful software products that
we all love, like the one with the talking paperclip). But that's not
the way web-based software works, by design. The need to be able to
both make change and be responsive to it is a daily cycle, not a six
month one.

Criticize us for releasing too early (hello Reid), or for launching a
very disruptive beta - fine. I personally will never judge a team too
harshly for releasing too early, because the normal bias is the
opposite, and it's counterproductive. The disruptive impact is real,
for sure (sorry!), which is why we're paying close attention and
looking for reasonable compromise approaches. The yardstick by which
we ought to be measured in the end is whether we'll be able to make
VisualEditor an awesome product, and whether we're responsive to
change. And I have every confidence in the team on both counts.

Erik

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation