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

Erik Moeller erik at wikimedia.org
Thu Aug 1 17:05:44 UTC 2013


On Thu, Aug 1, 2013 at 9:36 AM, Kevin Wayne Williams
<kwwilliams at kwwilliams.com> wrote:
> The editor was able to change a 4 to a 5 in an existing table, that's true.
> Could that editor add a row? No. Add a column? No. Delete a row or a column?
> No. Are all of those operations part of the bare minimum feature set for
> "table editing"? Absolutely.

No, I don't agree -- it's actually totally fine to say for now "if you
want to add rows etc., use the source editor". And as you know, once
you start going into complex table manipulations, the product becomes
a _lot_ more complex, because you need to be able to do so in a way
that matches existing expectations of how a table should be
structured, which vary by page (some augmented by templates, some
using various inline CSS approaches, etc.). However, I do agree that
we should do a better job communicating VE's limitations (they are
listed pretty clearly in a bunch of places, but obviously you're not
going to look if you're a new editor).

This is why I think the approach of adding VE as a second tab with a
clear "beta" label and an explanation when you open it is a reasonable
way forward.

> It's not "dirty diffs": the articles get converted to gibberish on saves:
> http://en.wikipedia.org/w/index.php?title=List_of_Big_Time_Rush_episodes&diff=565906957&oldid=565898974
>
> Wholesale destruction of articles is *not* a "dirty diff".

The use of "dirty diff" was not intended to minimize that - we've seen
destructive changes with VE, and we take them very seriously. Like I
said, cleanly roundtripping has always been a top priority. The way
we've prioritized them is by handcoding actual diffs we see in the
real world and fixing things that occur frequently first. I also like
the approach of shielding page content if needed. I just don't agree
that providing a clean experience for _editing_ that type of
masterfully template-constructed table is a fair expectation for a
first release.

You're right that copy/paste is badly broken across tabs, and still
pretty broken even inside tabs, and we should have tried harder for
the first release. But if I have time later today, I'll make you a
video of how badly broken and slow copy/paste is in Google Docs across
tabs, which has been around for many years now and seen a huge amount
of world-wide usage -- not to even mention other less widely used
web-based RTEs. Again, I'm not minimizing it -- just saying that what
look like obvious easy issues often turns out to be a very complex
problem that you end up being better served iterating on in the real
world.

What I do agree with is that we need to now make a change to the user
experience to acknowledge the legitimate issues with the current
experience, dial back the firehose, and more prominently inform users
about VE's limitations.

Erik

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



More information about the Wikimedia-l mailing list