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

[Erik Moeller]

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