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

[Robert Rohde]

If we are going to discuss Minimal Viable Product, then we might want
to take note of the line in the Wikipedia article that says:

"The product is typically deployed to a subset of possible customers,
such as early adopters that are thought to be more forgiving, more
likely to give feedback, and able to grasp a product vision from an
early prototype or marketing information."

More than any specific deficiency in VE, I think the aggressive roll
out did the most to cause user dissatisfaction.  If you want to claim
that VE is a minimal product, then it stands to reason that it
wouldn't be ready for all users.  There are plenty of ways to stage a
deployment and gather feedback that are intermediate between the early
opt-in and turning it on for all users everywhere.  The WMF took
nearly the most aggressive deployment path possible while the quality
of the software really didn't warrant that.

-Robert Rohde

On Thu, Aug 1, 2013 at 12:00 AM, Erik Moeller <erik at wikimedia.org> wrote:
> Hey Kevin,
>
> contrary to your belief (and in spite of your desire to blame me ;-),
> I actually have a ton of respect for the opinions you've expressed
> throughout the process, and for the level of detail and time you've
> committed to it, including helping in a hands-on manner. I don't agree
> with you on quite a few issues, obviously, but I've really enjoyed
> reading your comments, which are always well-reasoned and on point.
> :-) I hope you don't lose your patience with us, as you really are the
> kind of person we enjoy working with due to your diligence and the
> quality of your reports.
>
> So, if you've personally felt that it's been disruptive for you and
> caused you annoyance and frustration, I'm sorry, because I do respect
> your opinion and your work as an editor.
>
> On the subject of an appropriate MVP:
>
>> If you had followed that, and understood that the Minimum Viable Product
>> included cut-and-paste, table editing, and maybe the ability to successfully
>> and completely edit the hundred or so most edited articles out of all the
>> millions, you wouldn't have hit the level of pushback you've encountered.
>
> Couple of diffs from a few minutes ago of table edits:
> https://en.wikipedia.org/w/index.php?title=Major_League_Soccer&curid=71802&diff=566676293&oldid=566669395
> https://en.wikipedia.org/w/index.php?title=List_of_True_Blood_characters&curid=23290782&diff=566675268&oldid=565993704
>
> That's not just plain vanilla tables, but tables with inline CSS
> specified by hand, templates inside cells, etc. No roundtripping
> issues or other problems as far as I can tell.
>
> The kind of table you want us to make work well is this type:
>
> <onlyinclude>{| class="wikitable" style="margin: auto; width: 100%"
> |-
> ! colspan="2" rowspan="2" style="width:3%;"|Season
> ! rowspan="2" style="width:5%;"|Episodes
> ! colspan=2|Originally aired
> ! colspan=2|DVD release
> |-
> (...)
> | style="background:green; color:#134; text-align:center;"|
> | style="text-align:center;" colspan="2"| '''[[List of Big Time Rush
> episodes#Film|Film]]'''
> | style="text-align:center;" colspan="2"| {{Start date|2012|3|10}}
> | style="text-align: center; top" {{N/a}}
> | style="text-align: center; top" {{N/a}}
>
> which injects this kind of template:
> https://en.wikipedia.org/w/index.php?title=Template:N/a&action=edit
>
> In other words, a table partially constructed out of table cell templates.
>
> Now, I understand that you've dealt with dirty diffs resulting from
> people editing pages using those templates, and I know that sucks, so
> sorry about that - but it's a hard problem, and I don't think it's
> reasonable to frame it as an MVP-level one. The reasonable expectation
> is to fix roundtripping issues on those hairy tables as soon as
> possible, and ideally avoid any kind of accidental leakage of CSS into
> the UI. But as you know, some of these templates don't even map
> against HTML elements, so it's not a trivial issue.
>
> We could spend literally months trying to make
> tables-constructed-out-of-templates work nicely, and it would still be
> a shitty experience, and those would be months not spent on actual MVP
> features. Before we sink countless person hours into
> tables-constructed-out-of-templates, I think we need to step back and
> see what our options are for solving that particular problem well in
> the long run. Perhaps there's a type of table-template we can support
> well, and gradually migrate all tables to it, but it won't be easy.
>
> I appreciate that you created the "Disable VE" template which makes it
> possible to shield pages that are vulnerable to dirty diffs from VE.
> That was a great hack (we should have included _that_ one with the
> MVP, it would have saved users a lot of pain), and should help in
> cases where an immediate fix isn't feasible.
>
> As for copy-and-paste, yes, it's pretty wonky still, and I'm sure
> causes a fair bit of frustration for first-time VE users who have no
> experience with wikitext. However, it is there within a VE session,
> and we see very few diffs where users are causing problems due to
> broken copy-and-paste. Does that not match your experience? I've just
> inspected another round of 100 diffs and didn't see a single
> copy-and-paste related issue. Contrary to Andreas' claim, copying
> references isn't completely broken, but the bug is pretty nasty when
> it hits, so we'll get it fixed soon.
>
> As for performance, it already was a high priority before release, and
> we made huge gains in server-side performance thanks to the deployment
> of a completely new caching infrastructure for VisualEditor and lots
> of optimizations on Parsoid (still more to come). Where we could have
> done better prior to release was client-side performance -- we didn't
> do sufficient profiling there, and pushed it off to later; but we've
> made pretty significant improvements in the last month already to the
> point that even Adam Cuerden remarked on it. :-)
>
> I don't agree that focusing more on the pain points you name would
> have reduced the level of pushback significantly. You don't mention
> nowiki issues, but guess what, across the communities, aside from
> performance, that's the single biggest pain point we've heard and
> focused a lot of attention on already. And it's exactly the kind of
> issue you only really see fully in real world deployment. Or what
> about users who encountered a bug or crash when they used VE and
> concluded immediately that it could not possibly be ready? Or what
> about the users who want us to process wikitext inside VisualEditor?
> They'll continue to point to that as evidence of brokenness. Or the
> users who say that VisualEditor is a horrible idea, and we should just
> all be using markup? "It's a big giant waste of money, obviously! Kill
> it!" All of those opinions exist in fair measure.
>
> But I don't want to argue with you - I'm just saying things are a bit
> more complex and nuanced. In any case, we're also not arguing for not
> giving an inch, so your complaint about "You're not listening still!"
> is really not fair. (Would I be spending an hour before midnight
> engaging in this discussion with you if that was true?) I think James'
> proposal on the talk page is a reasonable middle ground. Users get a
> separate VisualEditor tab, clearly labeled beta, with a clear one-time
> notice informing them what that means. If they want to hide it, that's
> a click away, and the ones who already have hidden VE won't see it
> again. Why don't we try that for size and see if it helps us get to a
> reasonable pattern of working together?
>
> 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>