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

[Craig Franklin]

Erik,

I don't agree with everything you're saying here, but I for one appreciate
the candour and openness you're displaying in this discussion, not to
mention a willingness to act on ideas from the community.  You've already
implemented what my suggestion was going to be (sticking the word "Beta" in
the tab so people know what they're getting), so there's not much left
except to say thanks and I appreciate it.

Cheers,
Craig Franklin


On 2 August 2013 03:05, Erik Moeller <erik at wikimedia.org> wrote:

> 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
>
> _______________________________________________
> 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>
>