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

[Peter Southwood]

You could start by making the edit links permanently visible and clearly 
labeled. The mouse-over thing is really annoying, as I click on the wrong 
link often and the delay getting back to where I wanted to be is 
frustrating.
Display them as differently coloured buttons. [Wikitext editor] and [Visual 
editor (beta)], that are fixed in visibility and position.
It becomes easy to select the link you want, the screen stops flickering, 
you are warned that VE is beta. Nobody needs to add custom code to work in 
the way they prefer. A large number of complaints stop coming in. The amount 
of useful feedback is not likely to be reduced, but maybe a bit of the rage 
dies down.
Or you could explain why this would not work.
Or you could carry on ignoring the suggestion.
Your choice.
Peter
----- Original Message ----- 
From: "Erik Moeller" <erik at wikimedia.org>
To: "Wikimedia Mailing List" <wikimedia-l at lists.wikimedia.org>
Sent: Wednesday, July 31, 2013 7:28 AM
Subject: Re: [Wikimedia-l] Let's have the courage to sit down and talk 
aboutVisualEditor


> 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
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> <mailto:wikimedia-l-request at lists.wikimedia.org?subject=unsubscribe>