Mailing List Archive: Wikipedia: Foundation

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

1 2

View All

Index | Next | Previous | View Threaded

amir.aharoni at mail

Jul 31, 2013, 10:56 AM

Post #26 of 38 (75 views)
Permalink

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

2013/7/31 Brad Jorsch (Anomie) <bjorsch [at] wikimedia>:
> On Wed, Jul 31, 2013 at 12:47 PM, Gerard Meijssen
> <gerard.meijssen [at] gmail> wrote:
>> Quality like beauty is in the eye of the beholder. One thing that I learned
>> today is that the Visual Editor will have functionality that only the more
>> accomplished editors will enter directly or they will use templates. With
>> VE these templates are redundant.
>
> Some, perhaps. But would you rather use a template or remember the
> multiple buttons in VE and the right CSS style/class string (if that's
> even possible in VE?) to do the same thing manually?

God no. The whole idea of VE is to make people NOT have to remember
CSS class names.

If a template is a very common in a project, it should be a button
with complete GUI in the VE's toolbar in that project. If a template
is very common in many projects, it should be a button with complete
GUI in all projects.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

rarohde at gmail

Jul 31, 2013, 11:25 AM

Post #27 of 38 (75 views)
Permalink

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

On Wed, Jul 31, 2013 at 10:56 AM, Amir E. Aharoni
<amir.aharoni [at] mail> wrote:
> God no. The whole idea of VE is to make people NOT have to remember
> CSS class names.
>
> If a template is a very common in a project, it should be a button
> with complete GUI in the VE's toolbar in that project. If a template
> is very common in many projects, it should be a button with complete
> GUI in all projects.

Enwiki has 300 templates used more than 100,000 times. There are 1800
templates used more than 10,000 times.

That's an awful lot of buttons (or an awfully long drop-down).

There may be room for some special purpose buttons, but many tasks are
going to need to be accomplished by generalized tools.

-Robert Rohde

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

erik at wikimedia

Jul 31, 2013, 11:27 AM

Post #28 of 38 (75 views)
Permalink

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

On Wed, Jul 31, 2013 at 5:36 AM, David Gerard <dgerard [at] gmail> wrote:
> Certainly. However, it's the obvious question to ask, and a curious
> question to spend several paragraphs not answering.
>
> Erik, James - how did de:wp convinced you when en:wp hasn't?

Hi David,

I don't really agree with your framing - it's not about who's
convincing who, but being on a sustainable path to making VisualEditor
continually better, with an appropriately diverse and large base of
users. That's a balancing act with any community. In the case of
dewiki, it became clear pretty quickly that any additional benefit of
continued feedback would be outweighed by strife and upset about the
change to the default experience. In enwiki and other deployments, in
spite of upset, we've received a ton of useful and actionable feedback
through all of July that's enabled us to continually improve, but
given the enwiki RFC on default state, it's clear that the full-on
change of the default experience isn't yet sustainable in the long run
as a way to run the beta. So we're looking at alternatives, as per my
prior note, rather than waiting for the RFC to come to a close. Once
again, the only way to continually improve VisualEditor is to ensure
that we have a large base of continued use from a diverse group of
users, minimizing self-selection bias, but we'll explore different
ways to get there.

I don't believe in hard and fast rules - in managing big and complex
changes, we need to be patient with each other. On your end, we ask
for forgiveness because we're going to sometimes do things that get in
your way, confuse and annoy you in the process of finding ways to
improve the user experience. On our end, we need to show flexibility
and willingness to find a workable solution for the main problem:
ensuring we're making development decisions in a real world context,
not in a laboratory.

All best,
Erik

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

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

dgerard at gmail

Jul 31, 2013, 11:28 AM

Post #29 of 38 (75 views)
Permalink

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

On 31 July 2013 19:27, Erik Moeller <erik [at] wikimedia> wrote:
> On Wed, Jul 31, 2013 at 5:36 AM, David Gerard <dgerard [at] gmail> wrote:

>> Erik, James - how did de:wp convinced you when en:wp hasn't?

> I don't really agree with your framing - it's not about who's
> convincing who, but being on a sustainable path to making VisualEditor
> continually better, with an appropriately diverse and large base of

This comes across to me as a full and reasonable answer. Thanks :-)

- d.

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

jayen466 at gmail

Jul 31, 2013, 1:41 PM

Post #30 of 38 (74 views)
Permalink

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

On Wed, Jul 31, 2013 at 7:28 PM, David Gerard <dgerard [at] gmail> wrote:

> On 31 July 2013 19:27, Erik Moeller <erik [at] wikimedia> wrote:
> > On Wed, Jul 31, 2013 at 5:36 AM, David Gerard <dgerard [at] gmail> wrote:
>
> >> Erik, James - how did de:wp convinced you when en:wp hasn't?
>
> > I don't really agree with your framing - it's not about who's
> > convincing who, but being on a sustainable path to making VisualEditor
> > continually better, with an appropriately diverse and large base of
>
>
> This comes across to me as a full and reasonable answer. Thanks :-)
>
>
> - d.

Commiserations. If would hazard a guess that 450+ clear and indignant votes
against the VisualEditor on the German Wikipedia, collected within the
space of a weekend, spoke much louder than a trickle of moans by a few
dozen people on the English Wikipedia, where almost everybody was at first
inclined to be polite and "assume good faith". Most people did not want to
rain on the Foundation's parade.

I mean, look at how Jimbo sold the VisualEditor to the press at the start
of the roll-out:

http://www.telegraph.co.uk/technology/wikipedia/10196578/Wikipedia-introduces-new-features-to-entice-editors.html

---o0o---

“VisualEditor is a user interface that is much more familiar to people.
When you click edit you get something that looks very much like any word
processor, and you can change things and do whatever you want.”

---o0o---

"Whatever you want" indeed. Except add a citation:

http://www.dnaindia.com/blogs/1863070/post-wikipedia-editing-session-for-journalism-students-at-sophia-polytechnic

---o0o---

"After spending a bit of time dealing with connectivity issues and *finding
out that the Visual Editor doesn’t function on mobile devices and Internet
Explorer*, everyone started rolling on the demo-cum-live editing session.
The volunteers had chosen two biography articles for creation on the
English language Wikipedia, based on a list of possible subjects provided
by the department. Rohini did a step-by-step demo of how to create a page,
how to ensure there are enough third-party references available etc, and
created a biographical stub on Dina Vakil. The exact same exercise was
given to the students, who followed the same process in their groups, and
created a stub article on Ritu Menon. *All the groups got stuck at using
the reference/ citations templates on the Visual Editor, so we switched
back to wiki syntax.*"

---o0o---

In part, the German Wikipedia had the advantage of seeing the problems
accumulate on the English Wikipedia before it was "their turn" to
experience the same horrors. They had a chance to see the reality as
opposed to the PR spin, and to see how big the gap was between what was
promised and what was delivered. Seeing the mountain of unfixed bugs
assembled as a result of the English Wikipedia's feedback, they wisely said
"nein, danke".

I also don't understand why the Foundation would need any more feedback at
this point in time. Developers haven't even fixed bugs that have been known
for months. It seems just catching up with Bugzilla would be enough to keep
them busy for a while.

For example, I just learnt that it was reported almost two months ago that
you cannot take a reference into the clipboard. If you try, you either
can't do it at all, or you actually end up accidentally deleting the
reference content, leaving Wikipedia with just the plain-character string
"[1]". This is a problem that can do pretty nasty damage to an article,
besides angering editors, or making newbies feel incompetent if the next
person shouts at them because they deleted a perfectly good reference.

That bug was first reported on 13 June.

https://bugzilla.wikimedia.org/show_bug.cgi?id=49396

It was reported again on 2 July.

https://bugzilla.wikimedia.org/show_bug.cgi?id=50594

It was reported again on 29 July (by me).

https://bugzilla.wikimedia.org/show_bug.cgi?id=52212

It still hasn't been fixed. I fail to see the point in having the same
error reported time and again, and having developers spend their time
marking reports "Resolved" because they are duplicates of earlier reports
of the same, still unsolved issue, rather than spending their time actually
fixing the bug.

Andreas
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

erik at wikimedia

Jul 31, 2013, 9:58 PM

Post #31 of 38 (70 views)
Permalink

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

On Wed, Jul 31, 2013 at 1:41 PM, Andreas Kolbe <jayen466 [at] gmail> wrote:

> I mean, look at how Jimbo sold the VisualEditor to the press at the start
> of the roll-out:
>
> http://www.telegraph.co.uk/technology/wikipedia/10196578/Wikipedia-introduces-new-features-to-entice-editors.html
>
> ---o0o---
>
> “VisualEditor is a user interface that is much more familiar to people.
> When you click edit you get something that looks very much like any word
> processor, and you can change things and do whatever you want.”

Except that of course the narrative you're trying to establish here is
completely wrong. Wikimedia Foundation did not launch VisualEditor
with great fanfare, promising a panacea of perfect and beautiful
software. We announced it through a single blog post, inviting
feedback and support with the rollout. We launched a community portal
which had the following statements on it from day one:

---o0o--- (I like your quotation markup, let's add it to wikitext .. j/k)
At the moment, the VisualEditor has a number of bugs; this is
inevitable. The only way to only deploy software when it is bug-free
is not to deploy it at all - we're still finding errors in MediaWiki,
and that's 10 years old. If you encounter an issue, please do not
hesitate to report it on the Feedback page. There are also some areas
where we still have to build entirely new features. Current
limitations include:

* Odd-looking — We currently struggle with making the HTML we produce
look like what you are used to seeing, so styling and so on may look a
little (or even very) odd. We're increasing the time we put into this,
but so far our focus has been on making sure that the VisualEditor
does not alter wikitext unexpectedly.
* Incomplete editing — Some elements of "complex" formatting will
display and let you edit their contents, but not let users edit their
structure or add new entries – such as tables or definition lists.
Adding features in this area is one of our priorities.
* Limited browser support — Right now, we have only got VisualEditor
to work in the most modern versions of Firefox, Chrome and Safari. It
does not work in very old versions of each browser, and does not work
in Opera, although a volunteer is working on Opera support. Internet
Explorer currently does not work, but we aim to have support for the
latest versions of IE by the time we release the VisualEditor more
widely.
* Articles and User pages only — The VisualEditor will only be enabled
for the article and user namespaces (so you can make changes in a
personal sandbox). In time, we will build out the kinds of specialised
editing tools needed for non-articles, but our focus has been on
articles.

Because of these limitations, and inevitable bugs, we recommend that
users click "review your changes" before saving the page, and report
any problems they encounter.
---o0o---

This list has been community-updated since then and is a transparent
and honest reflection of the known areas of improvement.

In terms of media, when we've received inquiries, our response has
generally been "We're still in beta, talk to us in a few months". The
article you're quoting from is a single story that's about "new
features" that WMF is launching, of which VisualEditor is one; it also
discusses Echo and Flow. It also includes the following quote from
Jimmy about the VisualEditor.

---o0o---
“This is version 1.0, which means it is the first one that has really
had mass adoption and mass use,” said Wales. “We've had a lot of
feedback and there's going to be a lot of upgrades and changes, and
we're investing a lot in that kind of thing.”
---o0o---

The VisualEditor itself has a "Beta" button which, when clicked, shows
the following text:

---o0o---
VisualEditor is in 'beta'. You may encounter software issues, and you
may not be able to edit parts of the page.
---o0o---

Is the Beta notice too small and obscure? Fair criticism. But if you
want to claim that we're somehow misleading users about the state of
VisualEditor, you'll have to do a lot better.

> I also don't understand why the Foundation would need any more feedback at
> this point in time.

James has written a very good and detailed response to this here.
Please read it:
https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:VisualEditor/Default_State_RFC&oldid=566666714#Suggested_changes

In a nutshell, it's not about volume of feedback, but about iterating
with a representative real world set of users, rather than in
isolation. In terms of volume, right now we're dealing with a
firehose, which is more than we strictly need, but has the huge
advantage of being an unbiased sample of users. We understand it's
very disruptive, which is why we've been responsive to RFCs and
community consensus asking us to slow down. But we can't do it with a
trickle of self-selected users. We need a steady stream of real user
interactions and user feedback from different groups (IPs, new users,
experienced users) in order to iterate effectively. That's not trivial
to accomplish, but we'll try finding a middle-ground between the
current beta and the previous alpha.

If you're from old-school enterprise software engineering, you might
be looking at this process and wanting to gouge your eyes out. You're
deploying every week, sometimes every day? You're fixing bugs in
production the same day you write the fix? Crazy! Where are the
hundreds of pages of specs? Where's the Gantt chart schedule with
dependencies? Madness! Well, guess what - VisualEditor is being used
for >800 edits per hour at peak on enwiki alone, while your imaginary
waterfall software project is stuck in integration hell. And by the
way, all these bugs you thought you'd fixed? Turns out you haven't.
And that user experience you designed, which looked so great in the
spec? Turns out users have no idea what you were trying to do. Welcome
to the web, baby.

There's a reason every start-up on the planet follows the idea of the
Minimum Viable Product like a religion. There's a reason why Reid
Hoffman, who founded a little company called LinkedIn, said: "If you
are not embarrassed by the first version of your product, you've
launched too late." There's a reason why "release early, release
often" became a mantra in open source development. There's a reason
why waterfall development isn't used for real-world web development by
anyone who knows what they're doing.

If VisualEditor was a piece of software on a shelf that won't get a
new release until mid-2014, then the idea of "You've got enough
feedback, time to work by yourselves for a few months and then
re-release" would make some amount of sense, because that's the only
choice you have (it's brought us many wonderful software products that
we all love, like the one with the talking paperclip). But that's not
the way web-based software works, by design. The need to be able to
both make change and be responsive to it is a daily cycle, not a six
month one.

Criticize us for releasing too early (hello Reid), or for launching a
very disruptive beta - fine. I personally will never judge a team too
harshly for releasing too early, because the normal bias is the
opposite, and it's counterproductive. The disruptive impact is real,
for sure (sorry!), which is why we're paying close attention and
looking for reasonable compromise approaches. The yardstick by which
we ought to be measured in the end is whether we'll be able to make
VisualEditor an awesome product, and whether we're responsive to
change. And I have every confidence in the team on both counts.

Erik

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

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

kwwilliams at kwwilliams

Jul 31, 2013, 10:24 PM

Post #32 of 38 (70 views)
Permalink

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

Op 2013/07/31 21:58, Erik Moeller schreef:
> There's a reason every start-up on the planet follows the idea of the
> Minimum Viable Product like a religion.
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. You released a sub-viable product, which is what
caused the storm you encountered.
> I personally will never judge a team too
> harshly for releasing too early, because the normal bias is the
> opposite, and it's counterproductive.
I'll be content with just blaming you, then. You value your team's
productivity over everyone else's. I don't know why you expected
everyone that has worked on Wikipedia for years to cheerfully clean up
after you when you make it abundantly clear that you hold everything we
have worked on in disdain.

KWW

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

steven.walling at gmail

Jul 31, 2013, 11:19 PM

Post #33 of 38 (68 views)
Permalink

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

On Wed, Jul 31, 2013 at 10:24 PM, Kevin Wayne Williams <
kwwilliams [at] kwwilliams> wrote:

> 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. You released a sub-viable product, which is what caused the
> storm you encountered.

Minimum viable product does not mean "anything and everything works
perfectly" just like you want right out of the box, and it definitely does
not mean feature parity with an existing product (i.e. wikitext editing).
The purpose is to release something that can help us gather feedback and
test the concept behind the product in the real world instead of in a
lab.[1] Table editing and other advanced markup is not really necessary to
test the concept with the target audience, and decide whether to move
forward.

We all know VE didn't and doesn't edit everything in a way that's perfectly
up to snuff. No one has been claiming it doesn't have warts. What the team
is pushing back against is the idea that they can just turn it off and
develop a great new editor in a vacuum, away from real use by a
representative swath of current editors (registered and anonymous, new and
old). The lack of use by a sufficiently large and representative group of
editors is a big part of why the _seven months_ of original opt-in use
didn't fix most issues.

Erik and James have clearly admitted we can achieve our goals while moving
at a slower pace than the initial rollout and making other concessions.
Despite this, the attitude of some seems to be that they should be
committing seppuku for daring to release something not 100% perfect
according to [insert personal criteria for editing perfection here]. That's
not the kind of reaction that drew me to Wikipedia back in 2006, not by a
long shot. Rather, most of us find Wikipedia so rewarding because there is
room to be bold in the name of helping the encyclopedia. Which is precisely
what the VE team has been attempting to do.

Do I really really wish editing references and tables and templates was
easier when I'm writing articles in my off hours? Holy smokes yes. Is it
helping us get there to be making bitter comments about how Erik or anybody
else at WMF doesn't care about editors? No.

Steven

1. https://en.wikipedia.org/wiki/Minimum_viable_product
2. https://www.youtube.com/watch?v=qVR82uP_f6Q
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

erik at wikimedia

Aug 1, 2013, 12:00 AM

Post #34 of 38 (68 views)
Permalink

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

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
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

rarohde at gmail

Aug 1, 2013, 1:50 AM

Post #35 of 38 (68 views)
Permalink

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

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> 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
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

kwwilliams at kwwilliams

Aug 1, 2013, 9:36 AM

Post #36 of 38 (65 views)
Permalink

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

Op 2013/08/01 0:00, Erik Moeller schreef:
It's the constant minimization of issues that's the most annoying, Erik.
Reading through your response, you'd think that I was some kind of picky
person with irrationally high expectations. Nothing could be further
from the truth.
>> 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 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.
>
> 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.
It's not that *I* want them to work well. If you look over the whole pop
music area, you will find that most recent articles in that area include
at least one of {{Certification Table Top}}, {{Singlechart}},
{{Albumchart}}, or one of the {{won}}, {{lost}}, {{n/a}} group. Those
templates all failed, and all failed because of *different* bugs.

>
> Now, I understand that you've dealt with dirty diffs
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".
> ... it's not a trivial issue.
But it's certainly one that you knew was broken before you released
> ...
>
> 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.
I'm trying to generate an experience right now. So far I'm at 11 minutes
of CPU time trying to save the results, so not having diffs is
relatively unsurprising: if I wasn't braced for this, I would have
killed my browser and started over 8 minutes ago.

Wow ... 34 minutes of solid CPU time and the thing still hasn't saved.
I'll get back to the rest of the e-mail and hope it's done before I have
to leave the house.

Just crossed the one hour mark for CPU time, so I'll look back at this
e-mail when I'm done with my morning errands ...

At two hours and five minutes of solid CPU time, I'm going to crash my
browser and try a smaller test. Suffice it to say that a basic test plan
like "open the article about Lady Gaga in one edit window, paste the
results in another edit window, and save the results" was not a smashing
success. Corrupted the article format and could not save.

OK, http://en.wikipedia.org/wiki/User:Kww/pastetest2 shows the results
of copying the second paragraph from
http://en.wikipedia.org/wiki/Lady_Gaga?veaction=edit and pasting it into
a second edit window. That's *broken*. Inexcusably broken. Copying text
from one article and pasting it into another successfully is a test case
that doesn't require a firehose test to detect, and it certainly is a
part of the Minimum Viable Product.
>
>
>
> But I don't want to argue with you - I'm just saying things are a bit
> more complex and nuanced.
The problem is that you "do" continue to argue when you shouldn't. Has
your team accomplished a lot? Absolutely. But your definition of Minimum
Viable Product was so far off the mark that it caused the perception
that what you had wasn't worth testing. That's why the pushback was so
loud and so hard.

KWW

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

erik at wikimedia

Aug 1, 2013, 10:05 AM

Post #37 of 38 (65 views)
Permalink

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

On Thu, Aug 1, 2013 at 9:36 AM, Kevin Wayne Williams
<kwwilliams [at] kwwilliams> 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
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

cfranklin at halonetwork

Aug 5, 2013, 6:16 PM

Post #38 of 38 (23 views)
Permalink

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

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> wrote:

> On Thu, Aug 1, 2013 at 9:36 AM, Kevin Wayne Williams
> <kwwilliams [at] kwwilliams> 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
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request [at] lists?subject=unsubscribe>

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads