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(a)wikimedia.org> wrote:
On Thu, Aug 1, 2013 at 9:36 AM, Kevin Wayne Williams
<kwwilliams(a)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&am…
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(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>