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

Erik Moeller erik at wikimedia.org
Wed Jul 31 05:28:56 UTC 2013


On Tue, Jul 30, 2013 at 11:13 AM, David Gerard <dgerard at gmail.com> wrote:

> de:wp convinced you. What would it take to convince you on en:wp? (I'm
> asking for a clear objective criterion here. If you can only offer a
> subjective one, please explain how de:wp convinced you when en:wp
> hasn't.)

Hey David,

to me, this isn't about power dynamics (who decides, what is the
threshold, etc.) but about doing the right thing. It's pretty clear
where the en.wp RFC is going - a lot of users aren't comfortable
enough with the state of VE to give it the level of visibility it has.
Fair enough. I'm not going to dismiss that concern as "conservatism
about change" or any BS like that. There's plenty of that, and
there'll be more, but that's not the core issue right now.

Where we're coming from is simple. VE needed to get out of the
development model with a tiny group of users. It's been absolutely
critical to get the level of feedback we've been getting, and to have
thousands of users hit every edge case combination of
browser/OS/template complexity/editing operation. To get real world
reports on various aspects of the experience. To have people in India
or Argentina tell us "We used VE in a workshop, and here are some of
the things that worked and didn't work".

And this is not a one-time thing. We can't just work through a
mountain of feedback in a waterfall development model and hope that
all our assumptions about how to fix this or that complex issue will
work out in practice. You can throw cheap user tests at every design,
but at the end of the day, you need to go into the real world. Doug
Engelbart put it well: "The rate at which a person can mature is
directly proportional to the embarrassment he can tolerate."

This is why our preference is to keep fixing issues every day, as we
have been, addressing many of the highest priority real world issues,
including performance improvements, reducing <nowiki> escaping,
improving template/citation dialogs, etc. And every time we push out
one of those changes, we learn quickly whether it's working or not.

The opt-in alpha period wasn't sufficient to give us a large diversity
of users. The large-scale beta we're in right now, in spite of not
taking anything away from the ability to edit wikitext, is feeling too
disruptive for many at this time. What's a reasonable middle ground we
could shoot for?

In order to continually improve, we really need to build a large pool
of users that include IPs, new users, and experienced users. One
possibility is to aim for a prominent beta switch that's available to
all, similar to what we have on the mobile site. That would be an
opportunity to consolidate beta features, and to consistently treat
beta as opt-in as is being requested, while increasing the diversity
of the pool through increased prominence and recruiting. We'd have
some self-selection bias if we don't do better recruiting.

Another possibility would be to just maintain a separate, clearly
labeled tab for the VisualEditor that gives a prominent beta notice on
first-time invocation, with easy permanent dismissal.

We may also need to continue to run split A/B tests for different user
groups, in order to really get solid quantitative data on experience
differences.

Other thoughts & ideas? All of this is to say - to me this isn't a
game with a winner or a loser. We're working on this together to build
an awesome editing environment, not to score political points. So
let's iterate and find the best way forward together. :)

Cheers,
Erik

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



More information about the Wikimedia-l mailing list