Hi, there is a famous quote on courage by Winston Churchill, a British Prime Minister, who once wisely said: "Courage is what it takes to stand up and speak. Courage is also what it takes to sit down and listen."
Over the weekend, more than 440 editors of the German Wikipedia took part in an RfC-like process ("Umfragen") at https://de.wikipedia.org/wiki/Wikipedia:Umfragen/VisualEditor_Opt-in and voted against the activation of the VisualEditor for anonymous users, asking the WMF to revert to an opt-in phase instead of the currently existing opt-out.
This is yet another signal coming from the community that there is something very broken about the process in which VisualEditor is being rolled out. Most of the criticism has been ignored so far, but on the other hand, we haven't yet seen such an enormous community objection against the VisualEditor anywhere.
Let us therefore use this opportunity, and have the courage to sit down and listen. Or, perhaps, in the wiki spirit, let's edit this quote, and let us sit down and talk.
And, together, let's learn a lesson from this, and correct the errors so that they don't become mistakes.
Tomasz
Can somebody summarize the concerns raised in that RfC?
Best regards, Bence
On Mon, Jul 29, 2013 at 2:36 AM, Tomasz W. Kozlowski <tomasz@twkozlowski.net
wrote:
Hi, there is a famous quote on courage by Winston Churchill, a British Prime Minister, who once wisely said: "Courage is what it takes to stand up and speak. Courage is also what it takes to sit down and listen."
Over the weekend, more than 440 editors of the German Wikipedia took part in an RfC-like process ("Umfragen") at <https://de.wikipedia.org/** wiki/Wikipedia:Umfragen/**VisualEditor_Opt-inhttps://de.wikipedia.org/wiki/Wikipedia:Umfragen/VisualEditor_Opt-in> and voted against the activation of the VisualEditor for anonymous users, asking the WMF to revert to an opt-in phase instead of the currently existing opt-out.
This is yet another signal coming from the community that there is something very broken about the process in which VisualEditor is being rolled out. Most of the criticism has been ignored so far, but on the other hand, we haven't yet seen such an enormous community objection against the VisualEditor anywhere.
Let us therefore use this opportunity, and have the courage to sit down and listen. Or, perhaps, in the wiki spirit, let's edit this quote, and let us sit down and talk.
And, together, let's learn a lesson from this, and correct the errors so that they don't become mistakes.
Tomasz______________________________**_________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-request@lists.wikimedia.org ?subject=**unsubscribe>
I don't speak German, but with the aid of Google Translate, I think one can get a decent gist of the results.
Firstly, let me note that this German "Umfragen" process is structured largely as a vote. Some participants added short explanatory statements, but it is not a discussion forum so one shouldn't expect detailed explanations.
Participants were asked their opinion about how VE should be deployed on dewiki. The vote is still ongoing, but so far the results are:
22 individuals (4.4%) feel that VE should be deployed for anonymous users as scheduled.
7 users (1.4%) feel that VE should stay at its present status, i.e. deployed for registered users but not anons.
442 users (87.7%) feel that the VE deployment should be rolled back so that it is only available to users who explicitly opt-in at this time.
33 users (6.5%) chose a fourth opinion, the meaning of which is somewhat unclear to me using Google Translate, but which appears to express the opinion that VE should continue to be active in the interface but that it should be assigned a new button and not take over the "edit" functions.
Some of the people voting for the fourth option also supported one of the other three options as an alternative / supplemental preference.
Rather than continuing with the deployment to anons (scheduled for tomorrow), it appears that most of the contributors in this poll would prefer that VE be rolled back and only delivered as an opt-in process at this time.
Among the users choosing to offer an explanatory statement, the most common opinions offered in support of rollback (in no particular order) were perceptions that:
VE is too buggy / error-prone. VE is missing too many essential features. The current performance of VE is too slow. Various complaints about UI ("edit" section animation, button labels, etc.) Creates more work than benefits. Poor experience will deter rather than encourage new editors. Not intuitive.
The overarching theme of the comments is that VE was perceived as too immature/incomplete to justify any form of wide-scale deployment at this time. It should also be acknowledged that many participants agreed with the idea of a visual editor, in principle, but felt that the current implementation wasn't yet adequate.
-Robert Rohde
On Sun, Jul 28, 2013 at 5:43 PM, Bence Damokos bdamokos@gmail.com wrote:
Can somebody summarize the concerns raised in that RfC?
Best regards, Bence
On Mon, Jul 29, 2013 at 2:36 AM, Tomasz W. Kozlowski <tomasz@twkozlowski.net
wrote:
Hi, there is a famous quote on courage by Winston Churchill, a British Prime Minister, who once wisely said: "Courage is what it takes to stand up and speak. Courage is also what it takes to sit down and listen."
Over the weekend, more than 440 editors of the German Wikipedia took part in an RfC-like process ("Umfragen") at <https://de.wikipedia.org/** wiki/Wikipedia:Umfragen/**VisualEditor_Opt-inhttps://de.wikipedia.org/wiki/Wikipedia:Umfragen/VisualEditor_Opt-in> and voted against the activation of the VisualEditor for anonymous users, asking the WMF to revert to an opt-in phase instead of the currently existing opt-out.
This is yet another signal coming from the community that there is something very broken about the process in which VisualEditor is being rolled out. Most of the criticism has been ignored so far, but on the other hand, we haven't yet seen such an enormous community objection against the VisualEditor anywhere.
Let us therefore use this opportunity, and have the courage to sit down and listen. Or, perhaps, in the wiki spirit, let's edit this quote, and let us sit down and talk.
And, together, let's learn a lesson from this, and correct the errors so that they don't become mistakes.
Tomasz______________________________**_________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-request@lists.wikimedia.org ?subject=**unsubscribe>
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hey Tomasz,
this is a good way to start a new thread here, so let me respond.
We've done the following with regard to the VE beta so far: - We've overall slowed down the beta rollout schedule; - We've excluded nlwiki from the phase 2 beta rollout; - We've switched dewiki back to opt-in; - We've offered an easy way to hide VisualEditor (it was always possible not to use it).
We've also pushed out lots of fixes & improvements, including a first round of performance improvements, a better (still not awesome) citations dialog, improvements to the template dialog, etc.
If we have to globally go back to opt-in for a while, or some middle-ground (instant opt-out, or advertised beta) we'll do that too. We'd prefer not to, because having developers quickly see the impact of their changes at scale, positive and negative, is essential to making the product better quickly. The steady stream of feedback has been invaluable, and I think the changelog of the last few weeks demonstrates that beyond all doubt.
We see very few roundtripping errors. We do see incidents of problematic edits that are unique to a visual editing environment (e.g. backspace-deleting an infobox vs. having to select & delete all the markup representing it; reduced precision in applying formatting to content due to mouse selection). Some of those we can help reduce, some of them are inherent and we'll likely have to accept as a cost of introducing a new editor. And we do see the much-discussed issues with complex templates where the question isn't really who is "at fault" but what the right long term solution is.
There are quite a few ugly bugs (it's a beta), but most of those aren't that hard to squash. It'll take longer to make really big gains in performance, though -- that's a genuinely hard problem.
We don't think going back into opt-in mode is in the interests of advancing Wikimedia's mission -- maintaining VE as the "edit" button while making it trivial to edit source forces us to really stay at a high pace of continuous improvement that meets user needs. Nothing constrains choice and imposes urgency like reality.
Our preference is therefore to work with the community to stay in continuous improvement mode. If the overwhelming community sentiment is that the cost of continuous improvement with a large scale user base is larger than the benefit (as it was on dewiki), we'll switch back (or to a compromise), and use a more rigid set of acceptance criteria and a less rigid deadline for getting back into large scale usage later in the year.
Erik
On 30 July 2013 17:03, Erik Moeller erik@wikimedia.org wrote:
If the overwhelming community sentiment is that the cost of continuous improvement with a large scale user base is larger than the benefit (as it was on dewiki), we'll switch back (or to a compromise), and use a more rigid set of acceptance criteria and a less rigid deadline for getting back into large scale usage later in the year.
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
- d.
On 30 July 2013 14:13, David Gerard dgerard@gmail.com wrote:
On 30 July 2013 17:03, Erik Moeller erik@wikimedia.org wrote:
If the overwhelming community sentiment is that the cost of continuous improvement with a large scale user base is larger than the benefit (as it was on dewiki), we'll switch back (or to a compromise), and use a more rigid set of acceptance criteria and a less rigid deadline for getting back into large scale usage later in the year.
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
Just noting in passing: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Default_State_RFC
Risker
On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dgerard@gmail.com wrote:
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
[Speaking personally, not for the VE team in any way.]
Why should a consensus of any arbitrary number of power editors be allowed to define the defaults for all editors, including anonymous and newly-registered people? Anonymous edits make up about 1/3 of enwiki edits, IIRC. Every day, 3,000-5,000 new accounts are registered on English Wikipedia. These people are not even being asked to participate in these RFCs. Even if they were, they typically don't know how to participate and find it very intimidating.
This system of gauging the success of VE is heavily biased toward the concerns of people most likely to dislike change in the software and frankly, to not really need VE in its current state. That doesn't mean they're wrong, just that they don't speak for everyone's perspective. The sad fact is that the people who stand to benefit the most from continued use and improvements to VE can't participate in an RFC about it, in part because of wikitext's complexities and annoyances. It is a huge failure of the consensus process and the Wikimedia movement if we pretend that it's truly open, fair, and inclusive to make a decision about VE this way.
In WMF design and development, we work our butts off trying to do research, design, and data analysis that guides us toward building for _all_ the stakeholders in a feature. We're not perfect at it by a long shot, but I don't see a good faith effort by English and German Wikipedians running these RFCs to solicit and consider the opinions of the huge number of new/anonymous editors. And why should they? That's not their job, they just want to express their frustration and be listened to.
To answer David's question: I think we need a benchmark for making VE opt-in again that legitimately represents the needs of _all the people_ who stand to benefit from continuing the rapid pace of bug fixing and feature additions. I don't think an on-wiki RFC is it.
Steven
On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dgerard@gmail.com wrote:
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
[Speaking personally, not for the VE team in any way.]
Why should a consensus of any arbitrary number of power editors be allowed to define the defaults for all editors, including anonymous and newly-registered people? Anonymous edits make up about 1/3 of enwiki edits, IIRC. Every day, 3,000-5,000 new accounts are registered on English Wikipedia. These people are not even being asked to participate in these RFCs. Even if they were, they typically don't know how to participate and find it very intimidating.
This system of gauging the success of VE is heavily biased toward the concerns of people most likely to dislike change in the software and frankly, to not really need VE in its current state. That doesn't mean they're wrong, just that they don't speak for everyone's perspective. The sad fact is that the people who stand to benefit the most from continued use and improvements to VE can't participate in an RFC about it, in part because of wikitext's complexities and annoyances. It is a huge failure of the consensus process and the Wikimedia movement if we pretend that it's truly open, fair, and inclusive to make a decision about VE this way.
In WMF design and development, we work our butts off trying to do research, design, and data analysis that guides us toward building for _all_ the stakeholders in a feature. We're not perfect at it by a long shot, but I don't see a good faith effort by English and German Wikipedians running these RFCs to solicit and consider the opinions of the huge number of new/anonymous editors. And why should they? That's not their job, they just want to express their frustration and be listened to.
To answer David's question: I think we need a benchmark for making VE opt-in again that legitimately represents the needs of _all the people_ who stand to benefit from continuing the rapid pace of bug fixing and feature additions. I don't think an on-wiki RFC is it.
Steven
Let me confess, I hate all new things. I hate the constantly changing complicated wiki markup and I hate the new editor, cause I don't know how to work it even if it would be simpler if I were starting from scratch. The point was to design an editor that would be better for casual and new editors; I have nothing whatever to add from my own experience because I can't duplicate from my experience that of a casual or new editor.
Fred
On 30 July 2013 21:47, Steven Walling steven.walling@gmail.com wrote:
Why should a consensus of any arbitrary number of power editors be allowed to define the defaults for all editors, including anonymous and
OK - so why were those people listened to on de:wp? What happened there that they convinced you?
- d.
On 30 July 2013 22:27, David Gerard dgerard@gmail.com wrote:
On 30 July 2013 21:47, Steven Walling steven.walling@gmail.com wrote:
Why should a consensus of any arbitrary number of power editors be allowed to define the defaults for all editors, including anonymous and
OK - so why were those people listened to on de:wp? What happened there that they convinced you?
And I would remind you - I've been an ardent advocate of the absolute necessity for a Visual Editor for Wikipedia for the past few years. My qualms are not with change, but this particular instance and the serious problems on many levels the project of its implementation has manifested. It's possible the present project is recoverable into something usable, but it's really not going to just happen.
- d.
On Tue, Jul 30, 2013 at 2:27 PM, David Gerard dgerard@gmail.com wrote:
OK - so why were those people listened to on de:wp? What happened there that they convinced you?
If you're replying to me... this is why I said I wasn't speaking for the VE team. I didn't make that call. :)
Steven
Dear Steven, I think I understand what you mean, and I am concerned about a certain conservatism among the editors, too. Some editors complain all the time anyway. But when 87% reject such a software feature I suppose they cannot be all wrong (by the way, I am one of this huge majority). There are two groups among the "rejectors": Those who object a VE in general, and those who are eager to have one but have experienced major problems using it (I am one of them). One of my compatriots has expressed it as I feel it: we often see "beta phase" software, and sometimes after the beta phase there has never been a "final version". But those beta versions usually work well. This is different to the VE version we have experienced. I do appreciate Erik's explanations from above, see that the Foundation does notice what happens, and I agree that the existing community should not have an absolute veto power with regard to the "potential community of the future". I do have the impression that people were used as guinea pigs who did not ask for being that. :-) Kind regards Ziko
-------------------------------------------------------------------------------- Ziko van Dijk voorzitter / president Wikimedia Nederland deputy chair Wikimedia Chapters Association Council
Vereniging Wikimedia Nederland Postbus 167 3500 AD Utrecht http://wikimedia.nl --------------------------------------------------------------------------------
2013/7/30 Steven Walling steven.walling@gmail.com
On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dgerard@gmail.com wrote:
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
[Speaking personally, not for the VE team in any way.]
Why should a consensus of any arbitrary number of power editors be allowed to define the defaults for all editors, including anonymous and newly-registered people? Anonymous edits make up about 1/3 of enwiki edits, IIRC. Every day, 3,000-5,000 new accounts are registered on English Wikipedia. These people are not even being asked to participate in these RFCs. Even if they were, they typically don't know how to participate and find it very intimidating.
This system of gauging the success of VE is heavily biased toward the concerns of people most likely to dislike change in the software and frankly, to not really need VE in its current state. That doesn't mean they're wrong, just that they don't speak for everyone's perspective. The sad fact is that the people who stand to benefit the most from continued use and improvements to VE can't participate in an RFC about it, in part because of wikitext's complexities and annoyances. It is a huge failure of the consensus process and the Wikimedia movement if we pretend that it's truly open, fair, and inclusive to make a decision about VE this way.
In WMF design and development, we work our butts off trying to do research, design, and data analysis that guides us toward building for _all_ the stakeholders in a feature. We're not perfect at it by a long shot, but I don't see a good faith effort by English and German Wikipedians running these RFCs to solicit and consider the opinions of the huge number of new/anonymous editors. And why should they? That's not their job, they just want to express their frustration and be listened to.
To answer David's question: I think we need a benchmark for making VE opt-in again that legitimately represents the needs of _all the people_ who stand to benefit from continuing the rapid pace of bug fixing and feature additions. I don't think an on-wiki RFC is it.
Steven _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
It is absolutely true that the power users can't directly speak for the new users or anons.
That said, it would be unusual (though not impossible) if 85% of one group held an opinion without a large fraction of other related communities also sharing that view. If the WMF or someone else wants to commission a study of anon and new users opinions, that would definitely be interesting to see. Personally, I think VE is probably still too immature to be spending a lot of money asking people about it. (In other words, many of the problems and missing features are pretty obvious and we don't need to query large numbers of people to hear about things we already know.) Once it is a bit more stable and the low hanging fruit have been addressed, it could be quite instructive to get some user interaction studies on how people think it could be made better.
We also might be able to get some useful data by further A/B testing. For example, if VE is disabled, then assigning some anons to a VE enabled group (perhaps by a cookie) could provide a valuable comparison that we don't presently have.
For the moment, the thing we do have is edit counts over time (and similar data). Such data is certainly subject to various confounding influences, but the data we do have for anons and new users isn't exactly exciting. New users are only choosing VE at the 30-40% level for article edits, while anons are at the 20% use level. Not exactly a sign of wild enthusiasm for the new editing platform. By itself, these lowish use numbers are probably enough to conclude that neither group is overwhelmingly excited by VE, though admittedly both numbers are much higher than the 6% usage seen by established users.
The number I worry a bit more about is that total anon editing of articles has fallen 9% in the two weeks since introduction (compared to the prior two weeks). During the same time period total editing of articles by registered users rose 2%. Again, correlation is not causation, but if novice editors really liked VE then I would rather have expected total anon editing to increase relative to established users. Even though anons and power user undoubtedly have different needs. I can't help worrying that the bugs, missing features, and sluggish performance that power users complain about might also be discouraging some of the anonymous and new users. If the present state of VE is actually discouraging new editors then that would be a good sign that it isn't yet ready for wide deployment.
If I were designing a research program to study VE, I would certainly make getting additional information on anon behaviors a high priority, either by conducting new comparison trials or by finding better ways to tease out patterns in editing trends.
-Robert Rohde
On Tue, Jul 30, 2013 at 1:47 PM, Steven Walling steven.walling@gmail.com wrote:
On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dgerard@gmail.com wrote:
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
[Speaking personally, not for the VE team in any way.]
Why should a consensus of any arbitrary number of power editors be allowed to define the defaults for all editors, including anonymous and newly-registered people? Anonymous edits make up about 1/3 of enwiki edits, IIRC. Every day, 3,000-5,000 new accounts are registered on English Wikipedia. These people are not even being asked to participate in these RFCs. Even if they were, they typically don't know how to participate and find it very intimidating.
This system of gauging the success of VE is heavily biased toward the concerns of people most likely to dislike change in the software and frankly, to not really need VE in its current state. That doesn't mean they're wrong, just that they don't speak for everyone's perspective. The sad fact is that the people who stand to benefit the most from continued use and improvements to VE can't participate in an RFC about it, in part because of wikitext's complexities and annoyances. It is a huge failure of the consensus process and the Wikimedia movement if we pretend that it's truly open, fair, and inclusive to make a decision about VE this way.
In WMF design and development, we work our butts off trying to do research, design, and data analysis that guides us toward building for _all_ the stakeholders in a feature. We're not perfect at it by a long shot, but I don't see a good faith effort by English and German Wikipedians running these RFCs to solicit and consider the opinions of the huge number of new/anonymous editors. And why should they? That's not their job, they just want to express their frustration and be listened to.
To answer David's question: I think we need a benchmark for making VE opt-in again that legitimately represents the needs of _all the people_ who stand to benefit from continuing the rapid pace of bug fixing and feature additions. I don't think an on-wiki RFC is it.
Steven _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dgerard@gmail.com wrote:
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
Hey David,
to me, this isn't about power dynamics (who decides, what is the threshold, etc.) but about doing the right thing. It's pretty clear where the en.wp RFC is going - a lot of users aren't comfortable enough with the state of VE to give it the level of visibility it has. Fair enough. I'm not going to dismiss that concern as "conservatism about change" or any BS like that. There's plenty of that, and there'll be more, but that's not the core issue right now.
Where we're coming from is simple. VE needed to get out of the development model with a tiny group of users. It's been absolutely critical to get the level of feedback we've been getting, and to have thousands of users hit every edge case combination of browser/OS/template complexity/editing operation. To get real world reports on various aspects of the experience. To have people in India or Argentina tell us "We used VE in a workshop, and here are some of the things that worked and didn't work".
And this is not a one-time thing. We can't just work through a mountain of feedback in a waterfall development model and hope that all our assumptions about how to fix this or that complex issue will work out in practice. You can throw cheap user tests at every design, but at the end of the day, you need to go into the real world. Doug Engelbart put it well: "The rate at which a person can mature is directly proportional to the embarrassment he can tolerate."
This is why our preference is to keep fixing issues every day, as we have been, addressing many of the highest priority real world issues, including performance improvements, reducing <nowiki> escaping, improving template/citation dialogs, etc. And every time we push out one of those changes, we learn quickly whether it's working or not.
The opt-in alpha period wasn't sufficient to give us a large diversity of users. The large-scale beta we're in right now, in spite of not taking anything away from the ability to edit wikitext, is feeling too disruptive for many at this time. What's a reasonable middle ground we could shoot for?
In order to continually improve, we really need to build a large pool of users that include IPs, new users, and experienced users. One possibility is to aim for a prominent beta switch that's available to all, similar to what we have on the mobile site. That would be an opportunity to consolidate beta features, and to consistently treat beta as opt-in as is being requested, while increasing the diversity of the pool through increased prominence and recruiting. We'd have some self-selection bias if we don't do better recruiting.
Another possibility would be to just maintain a separate, clearly labeled tab for the VisualEditor that gives a prominent beta notice on first-time invocation, with easy permanent dismissal.
We may also need to continue to run split A/B tests for different user groups, in order to really get solid quantitative data on experience differences.
Other thoughts & ideas? All of this is to say - to me this isn't a game with a winner or a loser. We're working on this together to build an awesome editing environment, not to score political points. So let's iterate and find the best way forward together. :)
Cheers, Erik
You could start by making the edit links permanently visible and clearly labeled. The mouse-over thing is really annoying, as I click on the wrong link often and the delay getting back to where I wanted to be is frustrating. Display them as differently coloured buttons. [Wikitext editor] and [Visual editor (beta)], that are fixed in visibility and position. It becomes easy to select the link you want, the screen stops flickering, you are warned that VE is beta. Nobody needs to add custom code to work in the way they prefer. A large number of complaints stop coming in. The amount of useful feedback is not likely to be reduced, but maybe a bit of the rage dies down. Or you could explain why this would not work. Or you could carry on ignoring the suggestion. Your choice. Peter ----- Original Message ----- From: "Erik Moeller" erik@wikimedia.org To: "Wikimedia Mailing List" wikimedia-l@lists.wikimedia.org Sent: Wednesday, July 31, 2013 7:28 AM Subject: Re: [Wikimedia-l] Let's have the courage to sit down and talk aboutVisualEditor
On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dgerard@gmail.com wrote:
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
Hey David,
to me, this isn't about power dynamics (who decides, what is the threshold, etc.) but about doing the right thing. It's pretty clear where the en.wp RFC is going - a lot of users aren't comfortable enough with the state of VE to give it the level of visibility it has. Fair enough. I'm not going to dismiss that concern as "conservatism about change" or any BS like that. There's plenty of that, and there'll be more, but that's not the core issue right now.
Where we're coming from is simple. VE needed to get out of the development model with a tiny group of users. It's been absolutely critical to get the level of feedback we've been getting, and to have thousands of users hit every edge case combination of browser/OS/template complexity/editing operation. To get real world reports on various aspects of the experience. To have people in India or Argentina tell us "We used VE in a workshop, and here are some of the things that worked and didn't work".
And this is not a one-time thing. We can't just work through a mountain of feedback in a waterfall development model and hope that all our assumptions about how to fix this or that complex issue will work out in practice. You can throw cheap user tests at every design, but at the end of the day, you need to go into the real world. Doug Engelbart put it well: "The rate at which a person can mature is directly proportional to the embarrassment he can tolerate."
This is why our preference is to keep fixing issues every day, as we have been, addressing many of the highest priority real world issues, including performance improvements, reducing <nowiki> escaping, improving template/citation dialogs, etc. And every time we push out one of those changes, we learn quickly whether it's working or not.
The opt-in alpha period wasn't sufficient to give us a large diversity of users. The large-scale beta we're in right now, in spite of not taking anything away from the ability to edit wikitext, is feeling too disruptive for many at this time. What's a reasonable middle ground we could shoot for?
In order to continually improve, we really need to build a large pool of users that include IPs, new users, and experienced users. One possibility is to aim for a prominent beta switch that's available to all, similar to what we have on the mobile site. That would be an opportunity to consolidate beta features, and to consistently treat beta as opt-in as is being requested, while increasing the diversity of the pool through increased prominence and recruiting. We'd have some self-selection bias if we don't do better recruiting.
Another possibility would be to just maintain a separate, clearly labeled tab for the VisualEditor that gives a prominent beta notice on first-time invocation, with easy permanent dismissal.
We may also need to continue to run split A/B tests for different user groups, in order to really get solid quantitative data on experience differences.
Other thoughts & ideas? All of this is to say - to me this isn't a game with a winner or a loser. We're working on this together to build an awesome editing environment, not to score political points. So let's iterate and find the best way forward together. :)
Cheers, Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Tue, Jul 30, 2013 at 11:51 PM, Peter Southwood peter.southwood@telkomsa.net wrote:
You could start by making the edit links permanently visible and clearly labeled.
Yeah, I've already requested this, since it seems like an easy win. The mouseover behavior is really not a good solution - it was an attempt to find a compromise between ensuring continued availability of wikitext editing for sections while reducing clutter, but it doesn't really serve that purpose well. It makes wikitext editing secondary, which is unreasonable, adds screen flicker, and doesn't translate to touch devices. We've been procrastinating for too long finding the perfect solution for this problem, when really we'll probably just need to take a marginal clutter hit right now. We'll fix it.
That should help, Any idea of when we can expect the change? Cheers, Peter
----- Original Message ----- From: "Erik Moeller" erik@wikimedia.org To: "Wikimedia Mailing List" wikimedia-l@lists.wikimedia.org Sent: Wednesday, July 31, 2013 8:58 AM Subject: Re: [Wikimedia-l] Let's have the courage to sit down and talkaboutVisualEditor
On Tue, Jul 30, 2013 at 11:51 PM, Peter Southwood peter.southwood@telkomsa.net wrote:
You could start by making the edit links permanently visible and clearly labeled.
Yeah, I've already requested this, since it seems like an easy win. The mouseover behavior is really not a good solution - it was an attempt to find a compromise between ensuring continued availability of wikitext editing for sections while reducing clutter, but it doesn't really serve that purpose well. It makes wikitext editing secondary, which is unreasonable, adds screen flicker, and doesn't translate to touch devices. We've been procrastinating for too long finding the perfect solution for this problem, when really we'll probably just need to take a marginal clutter hit right now. We'll fix it.
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Wed, Jul 31, 2013 at 12:56 AM, Peter Southwood peter.southwood@telkomsa.net wrote:
That should help, Any idea of when we can expect the change?
Last time I discussed with Trevor he mentioned that it was a trivial fix (we just need to remove the hover effect), so let me bug them tomorrow :).
On 31 July 2013 06:28, Erik Moeller erik@wikimedia.org wrote:
Thanks. So, how did de:wp convince you when en:wp didn't? I notice you didn't address that point at all.
- d.
Erik Moeller, 31/07/2013 07:28:
We can't just work through a mountain of feedback in a waterfall development model and hope that all our assumptions about how to fix this or that complex issue will work out in practice.
+1 Also, such an important feature cannot be based on biased feedback from a subset of users and projects.
Erik Moeller, 30/07/2013 18:03:
The steady stream of feedback has been invaluable, and I think the changelog of the last few weeks demonstrates that beyond all doubt.
I think it would be helpful, if possible, to give some guesstimates of this, i.e.: how longer a wait it would cost us to reach some rank of quality if the deployment was downscaled; or, what would be the "deadline" for feedback on aspects X and Y to be actually able to be processed and worked on, before previous development decisions become irreversible or the developers move on to something else. We have seen some other products stuck for a few weeks or months in semi-ready state, which have then been deployed and have experienced some problems that were not predicted; or other products which have been used only on en.wiki (with dozens of WMF staffers involved in processing the feedback from one single wiki) and which are later deployed to other wikis when the product is already in maintenance mode, so that those wikis will never have a chance to influence the development. If de.wiki users or other users discussing/voting on whether to delay wider VE deployment could do so knowing that "delaying by x months will make us wait y months more to get use case w to work", or "if we delay after day z, feedback from our community will not influence the deployment of w", the conclusions would be more meaningful. If one assumes that the cost of delaying is 0, as it's what we've been using for 12 years, of course the benefits will always seem to outweigh the downsides.
Nemo
On 07/31/2013 10:52 AM, Federico Leva (Nemo) wrote:
I think it would be helpful, if possible, to give some guesstimates of this, i.e.: how longer a wait it would cost us to reach some rank of quality if the deployment was downscaled; or, what would be the "deadline" for feedback on aspects X and Y to be actually able to be processed and worked on, before previous development decisions become irreversible or the developers move on to something else.
Is it even possible to quantify this without just pulling numbers out of one's ass? It's not just a matter of "10 times the number of users means 10 times the number of bugs found" since the /profile/ of the users changes drastically as well.
For instance, allowing the VE only for registered editors is guaranteed to never reveal bugs/issues that only affects anonymous editing or interaction between anons and registered editors.
Likewise, requiring opt-in or allowing opt-out changes the makeup of the users a great deal (the former making certain that only editors with at least some familiarity with how we work use it and thus preventing usability issues for "true newbies" from being found, the latter by allowing the more vocal and knowing segments of editors to "hide" the VE and no longer see issues they alone are well-equipped to notice or evaluate).
-- Marc
Hoi, 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.
From my perspective, the future will be with the VE and not with the
horrible tortuous templates that require study to use. One of the reasons why I prefer Wikidata over Wikipedia is that Wikidata does not have templates and is certainly as relevant. When I notice the improvements in the Wikidata experience, I can only applaud the improvements made.
What is truly beyond me is that people protest the availability of the VE edit button. It is the choice of everybody to use VE or not. When they do they will have a similar experience I have with Wikidata.. You can only rejoice for the improvements that are made. Given that the improvements to the VE are a top priority, this experience can only be that much more enjoyable..
For all the oldies who complain about VE I want to remind them about the Commons experience; Commons existed without any functionality. It took months before we could use the images in any Wikipedia.
Really stop moaning and let that button be. Thanks, Gerard
On 31 July 2013 18:26, Marc A. Pelletier marc@uberbox.org wrote:
On 07/31/2013 10:52 AM, Federico Leva (Nemo) wrote:
I think it would be helpful, if possible, to give some guesstimates of this, i.e.: how longer a wait it would cost us to reach some rank of quality if the deployment was downscaled; or, what would be the "deadline" for feedback on aspects X and Y to be actually able to be processed and worked on, before previous development decisions become irreversible or the developers move on to something else.
Is it even possible to quantify this without just pulling numbers out of one's ass? It's not just a matter of "10 times the number of users means 10 times the number of bugs found" since the /profile/ of the users changes drastically as well.
For instance, allowing the VE only for registered editors is guaranteed to never reveal bugs/issues that only affects anonymous editing or interaction between anons and registered editors.
Likewise, requiring opt-in or allowing opt-out changes the makeup of the users a great deal (the former making certain that only editors with at least some familiarity with how we work use it and thus preventing usability issues for "true newbies" from being found, the latter by allowing the more vocal and knowing segments of editors to "hide" the VE and no longer see issues they alone are well-equipped to notice or evaluate).
-- Marc
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
It is not so much the presence of the button, that I ,and preumably some others, object to, as that if you switch from one wiki to another a lot, which I do, you tend to click on the wrong link a lot of the time, and that wastes time for absolutely no useful purpose whatsoever. The links should be static and easily distinguishable from the edit links on the other wikis. I am willing to help with beta testing, but only if they sort out the things that annoy me. If they dont, I will simply leave it to other people. When they run out of people willing to help then they will have to make changes to get them back. Its a simple supply and demand situation. If the devs dont supply what the users demand, the users will stop using it. Whether what the users demand is possible, practicable or even objectively desirable is a different issue. Cheers, Peter
----- Original Message ----- From: "Gerard Meijssen" gerard.meijssen@gmail.com To: "Wikimedia Mailing List" wikimedia-l@lists.wikimedia.org Sent: Wednesday, July 31, 2013 6:47 PM Subject: Re: [Wikimedia-l] Let's have the courage to sit down and talk aboutVisualEditor
Hoi, 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.
From my perspective, the future will be with the VE and not with the horrible tortuous templates that require study to use. One of the reasons why I prefer Wikidata over Wikipedia is that Wikidata does not have templates and is certainly as relevant. When I notice the improvements in the Wikidata experience, I can only applaud the improvements made.
What is truly beyond me is that people protest the availability of the VE edit button. It is the choice of everybody to use VE or not. When they do they will have a similar experience I have with Wikidata.. You can only rejoice for the improvements that are made. Given that the improvements to the VE are a top priority, this experience can only be that much more enjoyable..
For all the oldies who complain about VE I want to remind them about the Commons experience; Commons existed without any functionality. It took months before we could use the images in any Wikipedia.
Really stop moaning and let that button be. Thanks, Gerard
On 31 July 2013 18:26, Marc A. Pelletier marc@uberbox.org wrote:
On 07/31/2013 10:52 AM, Federico Leva (Nemo) wrote:
I think it would be helpful, if possible, to give some guesstimates of this, i.e.: how longer a wait it would cost us to reach some rank of quality if the deployment was downscaled; or, what would be the "deadline" for feedback on aspects X and Y to be actually able to be processed and worked on, before previous development decisions become irreversible or the developers move on to something else.
Is it even possible to quantify this without just pulling numbers out of one's ass? It's not just a matter of "10 times the number of users means 10 times the number of bugs found" since the /profile/ of the users changes drastically as well.
For instance, allowing the VE only for registered editors is guaranteed to never reveal bugs/issues that only affects anonymous editing or interaction between anons and registered editors.
Likewise, requiring opt-in or allowing opt-out changes the makeup of the users a great deal (the former making certain that only editors with at least some familiarity with how we work use it and thus preventing usability issues for "true newbies" from being found, the latter by allowing the more vocal and knowing segments of editors to "hide" the VE and no longer see issues they alone are well-equipped to notice or evaluate).
-- Marc
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Wed, Jul 31, 2013 at 12:47 PM, Gerard Meijssen gerard.meijssen@gmail.com 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?
From my perspective, the future will be with the VE and not with the horrible tortuous templates that require study to use. One of the reasons why I prefer Wikidata over Wikipedia is that Wikidata does not have templates and is certainly as relevant. When I notice the improvements in the Wikidata experience, I can only applaud the improvements made.
Wikidata also deals with discrete bits of usually-unformatted data, rather than heavily-formatted encyclopedia articles. I'm not sure you're comparing apples to apples there.
2013/7/31 Brad Jorsch (Anomie) bjorsch@wikimedia.org:
On Wed, Jul 31, 2013 at 12:47 PM, Gerard Meijssen gerard.meijssen@gmail.com 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
On Wed, Jul 31, 2013 at 10:56 AM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il 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
Am 30.07.2013 20:14 schrieb "David Gerard" dgerard@gmail.com:
On 30 July 2013 17:03, Erik Moeller erik@wikimedia.org wrote:
If the overwhelming community sentiment is that the cost of continuous improvement with a large scale user base is larger than the benefit (as it was on dewiki), we'll switch back (or to a compromise), and use a more rigid set of acceptance criteria and a less rigid deadline for getting back into large scale usage later in the year.
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
Hi David, i am editing on dewp and enwp. I consider myself an experienced editor, but not an expert. I did not participate voting in dewp, but i like to try ve from time to time. Beeing a software developper I fully support eriks arguments before. Imo pragmatic and flexible decisions help such development a lot, just like Erik explained.
What i would have hoped though is that the wiki syntax gets changed where it is difficult to implement. And what i would have expected are more ideas to just edit parts of a page, like e.g. hotcat does it, to avoid such a mammoth dealing with everything which feels slow then.
To give three examples: 1. why not define a metadata section for every page, where categories, and access rights are stored? Then these parts already can be split out of the "page ve".
2. Why not having a read and edit mode? Edit mode just adds "edit" links to all applicable parts of a page.
3. Why not decide references can only be after paragraphs, and edited via edit links showing up in Edit mode? so this part can be split out of "page ve".
Rupert
Thanks Erik for the helpful attitude.
Out of curiosity (not sure if this was discussed in more detail before - apologies for that), is it indeed true that Visual Editor is significantly slower than the regular editor (it feels like that to me, but might be my computer playing tricks on me), and is there any chance this will be overcome soon? I'm asking because you state that you want VE to move outside the small group of users - and making it faster might quite easily make it more popular with the non-diehard-non-new users. Right now I often simply use the regular editor for simple edits, because it is just quicker (less clicks, but also faster loading).
Lodewijk
2013/7/31 rupert THURNER rupert.thurner@gmail.com
Am 30.07.2013 20:14 schrieb "David Gerard" dgerard@gmail.com:
On 30 July 2013 17:03, Erik Moeller erik@wikimedia.org wrote:
If the overwhelming community sentiment is that the cost of continuous improvement with a large scale user base is larger than the benefit (as it was on dewiki), we'll switch back (or to a compromise), and use a more rigid set of acceptance criteria and a less rigid deadline for getting back into large scale usage later in the year.
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
Hi David, i am editing on dewp and enwp. I consider myself an experienced editor, but not an expert. I did not participate voting in dewp, but i like to try ve from time to time. Beeing a software developper I fully support eriks arguments before. Imo pragmatic and flexible decisions help such development a lot, just like Erik explained.
What i would have hoped though is that the wiki syntax gets changed where it is difficult to implement. And what i would have expected are more ideas to just edit parts of a page, like e.g. hotcat does it, to avoid such a mammoth dealing with everything which feels slow then.
To give three examples:
- why not define a metadata section for every page, where categories, and
access rights are stored? Then these parts already can be split out of the "page ve".
- Why not having a read and edit mode? Edit mode just adds "edit" links to
all applicable parts of a page.
- Why not decide references can only be after paragraphs, and edited via
edit links showing up in Edit mode? so this part can be split out of "page ve".
Rupert _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 31 July 2013 10:59, rupert THURNER rupert.thurner@gmail.com wrote:
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
Hi David, i am editing on dewp and enwp. I consider myself an experienced editor, but not an expert. I did not participate voting in dewp, but i like to try ve from time to time. Beeing a software developper I fully support eriks arguments before. Imo pragmatic and flexible decisions help such development a lot, just like Erik explained.
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?
- d.
On 31 July 2013 08:36, David Gerard dgerard@gmail.com wrote:
On 31 July 2013 10:59, rupert THURNER rupert.thurner@gmail.com wrote:
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
Hi David, i am editing on dewp and enwp. I consider myself an experienced editor, but not an expert. I did not participate voting in dewp, but i
like
to try ve from time to time. Beeing a software developper I fully support eriks arguments before. Imo pragmatic and flexible decisions help such development a lot, just like Erik explained.
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?
I would also like to see a direct answer to David's very specific question.
Risker
Am 31.07.2013 15:07 schrieb "Risker" risker.wp@gmail.com:
On 31 July 2013 08:36, David Gerard dgerard@gmail.com wrote:
On 31 July 2013 10:59, rupert THURNER rupert.thurner@gmail.com wrote:
de:wp convinced you. What would it take to convince you on en:wp?
(I'm
asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
Hi David, i am editing on dewp and enwp. I consider myself an
experienced
editor, but not an expert. I did not participate voting in dewp, but i
like
to try ve from time to time. Beeing a software developper I fully
support
eriks arguments before. Imo pragmatic and flexible decisions help such development a lot, just like Erik explained.
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?
I would also like to see a direct answer to David's very specific question.
From a software developers standpoint its nice to have the 2 biggest wikis
following a different strategy. Enwp is enough to get a lot of testers. But some accommodation of the users comes with it. Switching over wpde later gets again not accommodated and more critical feedback.
On 31 July 2013 13:32, rupert THURNER rupert.thurner@gmail.com wrote:
Am 31.07.2013 15:07 schrieb "Risker" risker.wp@gmail.com:
On 31 July 2013 08:36, David Gerard dgerard@gmail.com wrote:
On 31 July 2013 10:59, rupert THURNER rupert.thurner@gmail.com
wrote:
de:wp convinced you. What would it take to convince you on en:wp?
(I'm
asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
Hi David, i am editing on dewp and enwp. I consider myself an
experienced
editor, but not an expert. I did not participate voting in dewp, but
i
like
to try ve from time to time. Beeing a software developper I fully
support
eriks arguments before. Imo pragmatic and flexible decisions help
such
development a lot, just like Erik explained.
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?
I would also like to see a direct answer to David's very specific question.
From a software developers standpoint its nice to have the 2 biggest wikis following a different strategy. Enwp is enough to get a lot of testers. But some accommodation of the users comes with it. Switching over wpde later gets again not accommodated and more critical feedback.
Without rejecting your position, what we really want to hear is Erik Moeller's reasoning, in his role as VP Engineering. It was Erik's decision, and we want him to explain his reasoning in his own words.
Risker
It is a fair question. Peter ----- Original Message ----- From: "David Gerard" dgerard@gmail.com To: "Wikimedia Mailing List" wikimedia-l@lists.wikimedia.org Sent: Wednesday, July 31, 2013 2:36 PM Subject: Re: [Wikimedia-l] Let's have the courage to sit down and talk aboutVisualEditor
On 31 July 2013 10:59, rupert THURNER rupert.thurner@gmail.com wrote:
de:wp convinced you. What would it take to convince you on en:wp? (I'm asking for a clear objective criterion here. If you can only offer a subjective one, please explain how de:wp convinced you when en:wp hasn't.)
Hi David, i am editing on dewp and enwp. I consider myself an experienced editor, but not an expert. I did not participate voting in dewp, but i like to try ve from time to time. Beeing a software developper I fully support eriks arguments before. Imo pragmatic and flexible decisions help such development a lot, just like Erik explained.
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?
- d.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Wed, Jul 31, 2013 at 5:36 AM, David Gerard dgerard@gmail.com 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
On 31 July 2013 19:27, Erik Moeller erik@wikimedia.org wrote:
On Wed, Jul 31, 2013 at 5:36 AM, David Gerard dgerard@gmail.com 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.
On Wed, Jul 31, 2013 at 7:28 PM, David Gerard dgerard@gmail.com wrote:
On 31 July 2013 19:27, Erik Moeller erik@wikimedia.org wrote:
On Wed, Jul 31, 2013 at 5:36 AM, David Gerard dgerard@gmail.com 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-introduce...
---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-jou...
---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
On Wed, Jul 31, 2013 at 1:41 PM, Andreas Kolbe jayen466@gmail.com 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-introduce...
---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/Defau...
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
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
On Wed, Jul 31, 2013 at 10:24 PM, Kevin Wayne Williams < kwwilliams@kwwilliams.com> 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
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=718... https://en.wikipedia.org/w/index.php?title=List_of_True_Blood_characters&...
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
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@wikimedia.org 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=718... https://en.wikipedia.org/w/index.php?title=List_of_True_Blood_characters&...
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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
This may be a stupid question, but is it possible to put a label into a complicated template which will simply prevent VE from trying to edit it? P ----- Original Message ----- From: "Erik Moeller" erik@wikimedia.org To: "Wikimedia Mailing List" wikimedia-l@lists.wikimedia.org Sent: Thursday, August 01, 2013 9:00 AM Subject: Re: [Wikimedia-l] Let's have the courage to sit down and talk aboutVisualEditor
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=718... https://en.wikipedia.org/w/index.php?title=List_of_True_Blood_characters&...
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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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=718... https://en.wikipedia.org/w/index.php?title=List_of_True_Blood_characters&...
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&...
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
On Thu, Aug 1, 2013 at 9:36 AM, Kevin Wayne Williams kwwilliams@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&...
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,
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@wikimedia.org wrote:
On Thu, Aug 1, 2013 at 9:36 AM, Kevin Wayne Williams kwwilliams@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&...
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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
wikimedia-l@lists.wikimedia.org