On Mon, Jul 22, 2013 at 12:37 PM, Bartosz Dziewoński matma.rex@gmail.comwrote:

The bug for that patch was just WONTFIXed, synchronizing information. https://bugzilla.wikimedia.**org/show_bug.cgi?id=50929#c16https://bugzilla.wikimedia.org/show_bug.cgi?id=50929#c16

Just to accomodate people too lazy to chase through two links, in the interests of having a synchronized discussion I'm cut and pasting from the rationale given there:

{{Ping|Adam Cuerden}} Thanks for the thoughtful note. Some initial thoughts

-- I'll jump in more when I can, but also pinging [[User:Okeyes (WMF)|Oliver]] and [[User:Whatamidoing (WMF)|Whatamidoing]] who can help with clarifications.

Our overall concern, and the reason we did not offer a preference, is that

"out of sight, out of mind" makes it very hard for us to address the kinds of efficiency issues you mention. It makes it too easy for us to ignore the needs of users such as yourself as we improve VisualEditor. I actually do ''not'' agree that the kind of task you describe needs to be inherently less efficient in VisualEditor, but I do agree that it'll take us a while to make VisualEditor a good tool for that case.

I really would like us to be increasingly scientific and systematic about

this -- enumerate the types of tasks that users perform frequently, and measure the relative task performance in VisualEditor and source mode. I will personally not be satisfied with the product until we can exceed task efficiency in the vast majority of cases.

If you've followed the deployment a bit, you'll note that even this week,

we've made some changes to improve task efficiency for templates and images. Inserting an image used to take two clicks; now it takes one. Filling in a template used to require manually selecting all parameters; now required parameters (as defined by templatedata) are pre-selected, and it takes a single click to add a new parameter. Etc.

So, in other words, we ''do'' care, a lot, about making this not only an

easy-to-use tool, but an efficient one. Many of us at WMF are Wikipedians, and we hate tools that don't do the job. Where VisualEditor doesn't get the job done, we need to know. Our hypothesis is that we ''can'' build a tool that's both powerful and discoverable, not just a nice UI for newbies.

And to be honest, we made the mistake of offering a quick and easy "out of

sight, out of mind" preference before. When we did the Vector skin rollout in 2010, we offered a trivial "Take me back to the old look" option -- which lots of users took. Almost any change to a user interface [ http://www.designstaff.org/articles/how-to-avoid-mitigate-change-aversion-20... be met with resistance and objections]. As a recent non-WMF example, did you see the reactions to Flickr's design change? I've rarely seen so much hatemail for a company in one place.

By making it easy to switch back, we effectively created two generations of

users: the pre-Vector generation and the post-Vector users. Pre-Vector users, by and large, stayed with Monbook; post-Vector users stayed with Vector. There may have been legitimate efficiency reasons to stay with Monobook - things we could have improved in Vector, but didn't. In our drive to increase usability, we didn't pay sufficient attention to the needs of advanced users. And because of the "out of sight, out of mind" effect, we didn't have to.

To avoid this effect, with VisualEditor, you can't make it disappear

completely without resorting to gadgets or user scripts. You don't have to use it, but we encourage you to give it a try every once in a while to see the improvements and changes, and to point out those annoying bugs which we should have long fixed and haven't. And to the extent that there are things about the new default user experience that we have to fix to not interfere with normal editing (the current section editing behavior is definitely still not ideal), please keep us honest and remind us about it.

I hear you on the subject of muscle memory and confusing edit tabs. There

are a couple of things I'd say right now which may help mitigate this issue going forward, and I'd appreciate your suggestions as well.

1) We can reduce the issue by avoiding inconsistency between "Edit" and

"Edit source". I believe this is already on [[User:Jdforrester (WMF)|James']] agenda, and there was some community energy around this as well on [[WP:VPT]]. What I mean here is that right now, some namespaces still use wikitext by default. If those namespaces consistently had the tab labeled "Edit source", visually scanning for the right tab to click would be a lot easier. (Having VisualEditor on all Wikimedia projects, as it soon will be, will also help with those consistency issues.)

2) This is more of a personal tip for you: To support muscle memory, we

ensured that VisualEditor does not take over the existing keyboard shortcut for editing in source mode. If you've never given keyboard shortcuts a try, I strongly suggest it; they should work in all modern browsers. When you mouse over the tab, it gives you the shortcut indicator. So, I can just press Alt+Shift+E on any page to edit, and it will always edit in wikitext mode (Alt+Shift+V will edit in VisualEditor).

Finally, on the earlier point of measuring task efficiency -- this is

something anyone can help with. We may do some specific community outreach around this, but any efforts to document "It takes me X steps/seconds to do this in VisualEditor, Y steps/seconds in wikitext" helps ''a lot''. It's worth noting that VisualEditor has its own set of keyboard shortcuts, which can help with common tasks such as linking (which I actually already find faster in VE). And I do think tasks like updating image links should ultimately be well-supported in VE (even if it's by means of plugins), so we should start tracking these types of use cases in Bugzilla.

--[[User:Eloquence|Eloquence]][[User:Eloquence/CP|*]] 07:19, 17 July 2013

(UTC)

When Vector skin became the default, users continued to have preferences for other skins. That went extremely well, and did not negatively impact editing. (I'll note that there were comparatively few bugs reported when Vector became default, and none of them prevented people from doing *necessary* tasks, like referencing.) This was the first major all-sites deployment of new software in many years, and it was very successful. There are those who say it wasn't successful because so many people chose not to switch; however, there's been no research I'm aware of to figure out why people chose not to do so. (Myself, I still use monobook on enwiki because it opens large pages much faster, but I use Vector elsewhere.)

The logic that people are only avoiding VE because they hate change is faulty. They're not using it because it isn't fully functional yet. They're not using it because it can't handle edits that experienced users make dozens of times a day yet. And yes, some of them aren't using it because they hate change. But most of them have very good reasons not to want to debug software that was far too buggy to have been deployed as default. No explanation has ever been forthcoming of how we went from an alpha release that was so feature-deficient nobody was testing it to a default beta deployment with major features (i.e., referencing and templates) that were almost completely untested by those who were expected to use it. The result was not "many eyes find all bugs"....it was "most eyes stopped looking, and those that stayed have found a whole pile of bugs, some of which should have been caught before the software became default". This felt a lot like the kinds of releases the WMF did back in the 2000s when there were no resources at all. It's not really what people expect from an Engineering department with over 100 employees and a budget of $17 million.

People have already written hacks to prevent the tabs from showing up. The majority of edits by people registered after July 1 are now being done using "edit source", as are IP editors; over 90% of edits by experienced editors are using source editing, and there are questions about even the 10% being done on VE because so many are testing it right now. I'm not going to go so far as to say we should go back to source editing as default; that decision is being made indirectly by every group that is editing. Please pay attention to these red flags. I think some goodwill can be done by reinstating the opt-out preference. It's happening anyway.

A note about the bugzilla: there's a reason why people are commenting there. They're being ignored in every other venue, and WP:CONEXCEPT (exceptions to project consensus)[1] has been invoked in regard to this. Therefore the correct place to appeal the decision is with the community of Wikimedia developers and (maybe) WMF staff, and one of the most effective ways of getting the eyes of both groups is to launch and comment on Bugzillas.

Risker

[1] https://en.wikipedia.org/wiki/Wikipedia:CONEXCEPT#Decisions_not_subject_to_c...

On 22 July 2013 12:51, Tyler Romeo tylerromeo@gmail.com wrote:

On that note, I think we should start forcing MediaWiki developers to use Eclipse for PHP. Of course some people prefer using just a text editor, but I'm sure no matter what it'll be more efficient in Eclipse, and if it isn't we can just have Eclipse fix it.

Seriously, though, I understand why the VE team might want to force everybody to use VE, because otherwise users just "give up", so to say, because they don't like the change. But some people really just don't want to use VE, and I don't see why we should be forcing that upon them, especially if the community consensus is to add the user option back.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

On Mon, Jul 22, 2013 at 12:47 PM, C. Scott Ananian cananian@wikimedia.orgwrote:

...

On Mon, Jul 22, 2013 at 12:37 PM, Bartosz Dziewoński <

matma.rex@gmail.com

...

...

wrote:

...

The bug for that patch was just WONTFIXed, synchronizing information. https://bugzilla.wikimedia.**org/show_bug.cgi?id=50929#c16<

https://bugzilla.wikimedia.org/show_bug.cgi?id=50929#c16%3E

Just to accomodate people too lazy to chase through two links, in the interests of having a synchronized discussion I'm cut and pasting from

the

...

rationale given there:

{{Ping|Adam Cuerden}} Thanks for the thoughtful note. Some initial

thoughts

...

...

-- I'll jump in more when I can, but also pinging [[User:Okeyes (WMF)|Oliver]] and [[User:Whatamidoing (WMF)|Whatamidoing]] who can

help

...

...

with clarifications.

Our overall concern, and the reason we did not offer a preference, is

that

...

...

"out of sight, out of mind" makes it very hard for us to address the

kinds

...

of efficiency issues you mention. It makes it too easy for us to ignore

the

...

needs of users such as yourself as we improve VisualEditor. I actually

do

...

...

''not'' agree that the kind of task you describe needs to be inherently less efficient in VisualEditor, but I do agree that it'll take us a

while

...

...

to make VisualEditor a good tool for that case.

I really would like us to be increasingly scientific and systematic about

...

this -- enumerate the types of tasks that users perform frequently, and measure the relative task performance in VisualEditor and source mode.

I

...

...

will personally not be satisfied with the product until we can exceed

task

...

efficiency in the vast majority of cases.

If you've followed the deployment a bit, you'll note that even this week,

...

we've made some changes to improve task efficiency for templates and images. Inserting an image used to take two clicks; now it takes one. Filling in a template used to require manually selecting all

parameters;

...

...

now required parameters (as defined by templatedata) are pre-selected,

and

...

it takes a single click to add a new parameter. Etc.

So, in other words, we ''do'' care, a lot, about making this not only an

...

easy-to-use tool, but an efficient one. Many of us at WMF are

Wikipedians,

...

and we hate tools that don't do the job. Where VisualEditor doesn't get

the

...

job done, we need to know. Our hypothesis is that we ''can'' build a

tool

...

...

that's both powerful and discoverable, not just a nice UI for newbies.

And to be honest, we made the mistake of offering a quick and easy "out

of

...

...

sight, out of mind" preference before. When we did the Vector skin

rollout

...

in 2010, we offered a trivial "Take me back to the old look" option -- which lots of users took. Almost any change to a user interface [

http://www.designstaff.org/articles/how-to-avoid-mitigate-change-aversion-20... with resistance and objections]. As a recent non-WMF example,

...

...

did you see the reactions to Flickr's design change? I've rarely seen

so

...

...

much hatemail for a company in one place.

By making it easy to switch back, we effectively created two generations

of

...

...

users: the pre-Vector generation and the post-Vector users. Pre-Vector users, by and large, stayed with Monbook; post-Vector users stayed with Vector. There may have been legitimate efficiency reasons to stay with Monobook - things we could have improved in Vector, but didn't. In our drive to increase usability, we didn't pay sufficient attention to the needs of advanced users. And because of the "out of sight, out of mind" effect, we didn't have to.

To avoid this effect, with VisualEditor, you can't make it disappear

...

completely without resorting to gadgets or user scripts. You don't have

to

...

use it, but we encourage you to give it a try every once in a while to

see

...

the improvements and changes, and to point out those annoying bugs

which

...

we

...

should have long fixed and haven't. And to the extent that there are

things

...

about the new default user experience that we have to fix to not

interfere

...

with normal editing (the current section editing behavior is definitely still not ideal), please keep us honest and remind us about it.

I hear you on the subject of muscle memory and confusing edit tabs. There

...

are a couple of things I'd say right now which may help mitigate this

issue

...

going forward, and I'd appreciate your suggestions as well.

1. We can reduce the issue by avoiding inconsistency between "Edit" and

...

"Edit source". I believe this is already on [[User:Jdforrester (WMF)|James']] agenda, and there was some community energy around this

as

...

...

well on [[WP:VPT]]. What I mean here is that right now, some namespaces still use wikitext by default. If those namespaces consistently had the

tab

...

labeled "Edit source", visually scanning for the right tab to click

would

...

...

be a lot easier. (Having VisualEditor on all Wikimedia projects, as it

soon

...

will be, will also help with those consistency issues.)

2. This is more of a personal tip for you: To support muscle memory, we

...

ensured that VisualEditor does not take over the existing keyboard

shortcut

...

for editing in source mode. If you've never given keyboard shortcuts a

try,

...

I strongly suggest it; they should work in all modern browsers. When

you

...

...

mouse over the tab, it gives you the shortcut indicator. So, I can just press Alt+Shift+E on any page to edit, and it will always edit in

wikitext

...

mode (Alt+Shift+V will edit in VisualEditor).

Finally, on the earlier point of measuring task efficiency -- this is

...

something anyone can help with. We may do some specific community

outreach

...

around this, but any efforts to document "It takes me X steps/seconds

to

...

do

...

this in VisualEditor, Y steps/seconds in wikitext" helps ''a lot''.

It's

...

...

worth noting that VisualEditor has its own set of keyboard shortcuts,

which

...

can help with common tasks such as linking (which I actually already

find

...

...

faster in VE). And I do think tasks like updating image links should ultimately be well-supported in VE (even if it's by means of plugins),

so

...

...

we should start tracking these types of use cases in Bugzilla.

--[[User:Eloquence|Eloquence]][[User:Eloquence/CP|*]] 07:19, 17 July 2013

...

(UTC)

-- (http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Mon, Jul 22, 2013 at 9:51 AM, Tyler Romeo tylerromeo@gmail.com wrote:

Seriously, though, I understand why the VE team might want to force everybody to use VE

That's a misrepresentation of the facts. We're not talking about "forcing people to use VE". We're talking about whether there should be a preference to hide all aspects of VE from the user interface. The default behavior is that both modes coexist. Nobody is forced to use VE, and it adds minimal JavaScript footprint if it is not used.

The default experience clearly still has room for improvement for users who prefer wikitext. In my view, in order of priority:

1) Section editing behavior - the hybrid link display is mildly annoying, and doesn't work for touch interfaces; 2) Inconsistent labels across namespaces - "Edit source" label should probably be consistently used; 3) Further tweaks to tab loading to minimize any delay in rendering.

If these issues are addressed now, the only one that remains for users preferring wikitext is getting used to the presence of a new tab in the interface, which I do think is a reasonable change to not offer a specific preference for. (I'm not talking about VE edit bugs/problematic edits in this context as that's a separate issue.)

Erik

On Mon, Jul 22, 2013 at 11:41 AM, John phoenixoverride@gmail.com wrote:

Minimal java-script load my ass,

Your language and tone are inappropriate. Please keep it civil.

I guess you must be using a fiber-optic connection. Most pages already have a lag due to the amount of JS needed to run the site. Jumping pages have been a normal thing since resourceloader (caused by lagging JS issues)

The initial JS loaded for VisualEditor is a whopping 2.9KB gzipped. I'd call that minimal. There is lots of other JS out there, but this thread is about VisualEditor.

Roan

On 23/07/13 04:36, Erik Moeller wrote:

1. Section editing behavior - the hybrid link display is mildly

annoying, and doesn't work for touch interfaces;

I think it's a bit more than mildly annoying, and I think it's the main reason users are so desperate to disable VE completely instead of simply not clicking on it.

Consider it from a cognitive point of view:

Half the time (e.g. on talk pages), the section edit link will go to the old edit page, and the other half, it will flash an "edit source" link at you for the 100ms or so it takes to stabilise the cursor position and execute a mouse click, and then it will launch the visual editor. Often, the user is punished for clicking on the wrong link by having their browser lock up for 15 seconds.

Habit formation is cleverly avoided by changing the function of the link depending on what namespace you are on.

I know that this crafty UI was introduced to encourage users to use the new editor. The trouble is, this assumes that users have no idea which editor they want to use, and thus will happily use whatever editor the JS can trick them into clicking. But, I suspect, most users have decided which editor they want to use before they start moving their mouse.

I think users should be encouraged to use VE by making VE really awesome, and by promoting its awesomeness, rather than by trying to trick them into using it.

-- Tim Starling

My apologies for the ham handed email.  I'm supportive of the opt out feature while ve is in beta.  Going forward I agree with the notion that experienced editors know what editor they want to use before the page completely loads.  I like the idea of a preference to select a default editor.  — Sent from Mailbox for iPhone

On Tue, Jul 23, 2013 at 9:32 PM, Rob Moen rmoen@wikimedia.org wrote:

I personally know for a fact nobody is trying to trick the user in this case.   We are simply trying to make editing easier for new editors without confusing them.  As a membwr f the visual editor team, I'm supportive of our advanced and seemingly more important editors opt-out during the beta.   — Sent from Mailbox for iPhone On Tue, Jul 23, 2013 at 21:23, Tim Starling <tstarling@wikimedia.org="mailto:tstarling@wikimedia.org">> wrote: On 23/07/13 04:36, Erik Moeller wrote:

...

1. Section editing behavior - the hybrid link display is mildly

annoying, and doesn't work for touch interfaces;

I think it's a bit more than mildly annoying, and I think it's the main reason users are so desperate to disable VE completely instead of simply not clicking on it. Consider it from a cognitive point of view: Half the time (e.g. on talk pages), the section edit link will go to the old edit page, and the other half, it will flash an "edit source" link at you for the 100ms or so it takes to stabilise the cursor position and execute a mouse click, and then it will launch the visual editor. Often, the user is punished for clicking on the wrong link by having their browser lock up for 15 seconds. Habit formation is cleverly avoided by changing the function of the link depending on what namespace you are on. I know that this crafty UI was introduced to encourage users to use the new editor. The trouble is, this assumes that users have no idea which editor they want to use, and thus will happily use whatever editor the JS can trick them into clicking. But, I suspect, most users have decided which editor they want to use before they start moving their mouse. I think users should be encouraged to use VE by making VE really awesome, and by promoting its awesomeness, rather than by trying to trick them into using it. -- Tim Starling _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Wed, 24 Jul 2013 07:35:02 +0200, Steven Walling steven.walling@gmail.com wrote:

This interaction was committed by a volunteer not on the VE team.[1][2] Ideally,VE would be good enough that we wouldn't need edit source links on sections at all. Personally I advocated for not including them by any method. However, people felt that it was important to give users a choice on section edit links, and that as opposed to a dropdown or simply displaying both links statically, using a progressive display was the more elegant way of showing both options. MatmaRex could not have been clearer about this on the patch.

1. https://bugzilla.wikimedia.org/show_bug.cgi?id=49666
2. https://gerrit.wikimedia.org/r/#/c/69984/

Not true; the patch was rewritten by Trevor, and he's marked as the author. My version was showing both of the links all the time, with no animations, and I still think it's a better solution.

On Wed, Jul 24, 2013 at 5:34 AM, John Erling Blad jeblad@gmail.com wrote:

There are good reasons why users want to turn off VE and the most important reason are not what most people in the thread seems to think. Users that have learned to use a crappy direct editing user interface tend to be faster on using that interface than more modern WYSIWYG editors. I tried to make a few test edits whit carefully planned actions and I could not edit as fast with VE as with the old crappy edit page. I think this is quite common. When editors tries to edit with the new editor they experience this and gets the feeling that VE itself is sluggish, but the real reason is that the user interactions slows down. The difference in editing speed i visible even at ordinary text with only minor wikicode, but as the amount of wikicode increases the diference grows.

I would love if the Visual Editor could have also wikicode edition capabilities with proper synthax highlighting. There is the Dot's syntax highlighter as a gadget but it doesn't come close to other code highlighters like Notepad++ Would that be possible?

Micru

I am getting real sick of the WMF developers shoving shity products down the throat of their users and saying FUCK YOU. That is the pattern that I have seen over the recent months starting primarily with Notifcations and now moving to VE. It really pisses me off that more and more sites are shoving crap into javascript that just plain sucks, is poorly written and extremely bloated. Since the devs implemented resource loader it has become harder and harder to block the poorly developed bloat that has crept into mediawiki. I used to be able to isolate the JavaScript file causing the issues (I remember BITS geolocation being a major hog) and just block it. Now thats not possible any longer. Users WANT a method for turning off an extremely bloated "Feature" keep in mind that the WMF Staff is dependent not only on donations by users, but also by what content they produce. Instead of fucking up stuff why dont the devs spend time going back and fixing bugs and issues that the community wants fixed. There are major features and bugs that have been open for over 5 years that need addressed. Lets stop trying to become facebook and remember what our goal here is.

VE needs a method for disabling the loading of the associated JavaScript, If users what to test VE again they can, but lets put this piece of shit to rest until its not a piece of shit

John

On Mon, Jul 22, 2013 at 12:51 PM, Tyler Romeo tylerromeo@gmail.com wrote:

On that note, I think we should start forcing MediaWiki developers to use Eclipse for PHP. Of course some people prefer using just a text editor, but I'm sure no matter what it'll be more efficient in Eclipse, and if it isn't we can just have Eclipse fix it.

Seriously, though, I understand why the VE team might want to force everybody to use VE, because otherwise users just "give up", so to say, because they don't like the change. But some people really just don't want to use VE, and I don't see why we should be forcing that upon them, especially if the community consensus is to add the user option back.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

On Mon, Jul 22, 2013 at 12:47 PM, C. Scott Ananian cananian@wikimedia.orgwrote:

...

On Mon, Jul 22, 2013 at 12:37 PM, Bartosz Dziewoński <

matma.rex@gmail.com

...

...

wrote:

...

The bug for that patch was just WONTFIXed, synchronizing information. https://bugzilla.wikimedia.**org/show_bug.cgi?id=50929#c16<

https://bugzilla.wikimedia.org/show_bug.cgi?id=50929#c16%3E

Just to accomodate people too lazy to chase through two links, in the interests of having a synchronized discussion I'm cut and pasting from

the

...

rationale given there:

{{Ping|Adam Cuerden}} Thanks for the thoughtful note. Some initial

thoughts

...

...

-- I'll jump in more when I can, but also pinging [[User:Okeyes (WMF)|Oliver]] and [[User:Whatamidoing (WMF)|Whatamidoing]] who can

help

...

...

with clarifications.

Our overall concern, and the reason we did not offer a preference, is

that

...

...

"out of sight, out of mind" makes it very hard for us to address the

kinds

...

of efficiency issues you mention. It makes it too easy for us to ignore

the

...

needs of users such as yourself as we improve VisualEditor. I actually

do

...

...

''not'' agree that the kind of task you describe needs to be inherently less efficient in VisualEditor, but I do agree that it'll take us a

while

...

...

to make VisualEditor a good tool for that case.

I really would like us to be increasingly scientific and systematic about

...

this -- enumerate the types of tasks that users perform frequently, and measure the relative task performance in VisualEditor and source mode.

I

...

...

will personally not be satisfied with the product until we can exceed

task

...

efficiency in the vast majority of cases.

If you've followed the deployment a bit, you'll note that even this week,

...

we've made some changes to improve task efficiency for templates and images. Inserting an image used to take two clicks; now it takes one. Filling in a template used to require manually selecting all

parameters;

...

...

now required parameters (as defined by templatedata) are pre-selected,

and

...

it takes a single click to add a new parameter. Etc.

So, in other words, we ''do'' care, a lot, about making this not only an

...

easy-to-use tool, but an efficient one. Many of us at WMF are

Wikipedians,

...

and we hate tools that don't do the job. Where VisualEditor doesn't get

the

...

job done, we need to know. Our hypothesis is that we ''can'' build a

tool

...

...

that's both powerful and discoverable, not just a nice UI for newbies.

And to be honest, we made the mistake of offering a quick and easy "out

of

...

...

sight, out of mind" preference before. When we did the Vector skin

rollout

...

in 2010, we offered a trivial "Take me back to the old look" option -- which lots of users took. Almost any change to a user interface [

http://www.designstaff.org/articles/how-to-avoid-mitigate-change-aversion-20... with resistance and objections]. As a recent non-WMF example,

...

...

did you see the reactions to Flickr's design change? I've rarely seen

so

...

...

much hatemail for a company in one place.

By making it easy to switch back, we effectively created two generations

of

...

...

users: the pre-Vector generation and the post-Vector users. Pre-Vector users, by and large, stayed with Monbook; post-Vector users stayed with Vector. There may have been legitimate efficiency reasons to stay with Monobook - things we could have improved in Vector, but didn't. In our drive to increase usability, we didn't pay sufficient attention to the needs of advanced users. And because of the "out of sight, out of mind" effect, we didn't have to.

To avoid this effect, with VisualEditor, you can't make it disappear

...

completely without resorting to gadgets or user scripts. You don't have

to

...

use it, but we encourage you to give it a try every once in a while to

see

...

the improvements and changes, and to point out those annoying bugs

which

...

we

...

should have long fixed and haven't. And to the extent that there are

things

...

about the new default user experience that we have to fix to not

interfere

...

with normal editing (the current section editing behavior is definitely still not ideal), please keep us honest and remind us about it.

I hear you on the subject of muscle memory and confusing edit tabs. There

...

are a couple of things I'd say right now which may help mitigate this

issue

...

going forward, and I'd appreciate your suggestions as well.

1. We can reduce the issue by avoiding inconsistency between "Edit" and

...

"Edit source". I believe this is already on [[User:Jdforrester (WMF)|James']] agenda, and there was some community energy around this

as

...

...

well on [[WP:VPT]]. What I mean here is that right now, some namespaces still use wikitext by default. If those namespaces consistently had the

tab

...

labeled "Edit source", visually scanning for the right tab to click

would

...

...

be a lot easier. (Having VisualEditor on all Wikimedia projects, as it

soon

...

will be, will also help with those consistency issues.)

2. This is more of a personal tip for you: To support muscle memory, we

...

ensured that VisualEditor does not take over the existing keyboard

shortcut

...

for editing in source mode. If you've never given keyboard shortcuts a

try,

...

I strongly suggest it; they should work in all modern browsers. When

you

...

...

mouse over the tab, it gives you the shortcut indicator. So, I can just press Alt+Shift+E on any page to edit, and it will always edit in

wikitext

...

mode (Alt+Shift+V will edit in VisualEditor).

Finally, on the earlier point of measuring task efficiency -- this is

...

something anyone can help with. We may do some specific community

outreach

...

around this, but any efforts to document "It takes me X steps/seconds

to

...

do

...

this in VisualEditor, Y steps/seconds in wikitext" helps ''a lot''.

It's

...

...

worth noting that VisualEditor has its own set of keyboard shortcuts,

which

...

can help with common tasks such as linking (which I actually already

find

...

...

faster in VE). And I do think tasks like updating image links should ultimately be well-supported in VE (even if it's by means of plugins),

so

...

...

we should start tracking these types of use cases in Bugzilla.

--[[User:Eloquence|Eloquence]][[User:Eloquence/CP|*]] 07:19, 17 July 2013

...

(UTC)

-- (http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Tue, Jul 23, 2013 at 10:28 AM, Derric Atzrott < datzrott@alizeepathology.com> wrote:

<snip> >Since the devs implemented resource loader it has become >harder and harder to block the poorly developed bloat that has crept into >mediawiki. I used to be able to isolate the JavaScript file causing the >issues (I remember BITS geolocation being a major hog) and just block it. >Now thats not possible any longer. <snip>

Slightly off topic, but for this problem at least you could try using ?debug=true which will turn off that portion of Resource Loader.

Thank you, Derric Atzrott

That would only work for a single page, the next link I click on the debug

flag is ignored. Such a method becomes unfeasible with any serious usage.

If Source editing is going to be supported for a long time, what reason is there for not allowing users to turn off a broken piece of software? I just did a quick look at bugzilla there are 618 open bugs for VE alone. The community is demanding the ability to disable this. Ive lost count on the number of pages that it has broken. It drives editors away and prevents new users from editing. What are the real pros for VE right now? Other than a few WMF staff saying *Because I said So* I haven't seen any real progress. Just like with notifications This was poorly thought out and poorly implemented long before it should have gone live.

Ive seen this posted elsewhere, but why wasnt this tested thoroughly and rolled out slowly to ensure minimal impact and minimal site breakage. The WMF shoved VE down everyone's throat at least 6 months before it should have gone site wide. (Why? just to meet some artificial deadline that they created themselves )

What should have happened was a scaled deployment process that slowly rolled out to ensure minimal negative impact. Here is just one example of how it should have been rolled out:

1 Closed Beta on major wikis (those who know the software can test it in an actual environment that's not in a lab) 1-2 Weeks 2 Open Opt-In Beta At least 60 days 3 Step back all bugs reported 4 Enable for a small group of users who understand the wiki (AKA enable for sysops) Minimal testing 60 days 5 Listen to feedback, fix bugs and address issues. 6 Incrementally roll out to larger sub groups in 2-3 weeks intervals 7 Once a working stable product without major issues has been developed roll out to all registered users 8. Stop re-assess impact, feedback and issues associated with the project, listen to users and resolve any outstanding issues. 9 Deploy to all users once a stable, bug free product is ready.

Until the time where you are going to force people to use VE and discontinue support for the Source Editor there should be a method for disabling VE. I know I am not alone stating that I hate to be someone's guinea pig. Ill switch over to a new product when I feel it offers a better product. I would rather not have stuff shoved down my throat and told its good for you. (If its being shoved down your throat it is rarely a better product)

John

Putting all of the issues aside, I'd like to know what the reason is for hiding the preference. Let's assume for a second that VE does not hinder users at all, that it's JS footprint is nonexistent, and that the interface changes aren't that bothersome (which, to an extend, are true). Even with all that, what reason is there to purposely deprive users of the choice to completely hide VE if they're sure they have no intention of using it?

Apparently the VE launch was pretty successful. What damage would be done by enabling this user option, and how bad is this damage that it requires overriding the community decision just to stop it?

On Mon, Jul 22, 2013 at 2:41 PM, MZMcBride z@mzmcbride.com wrote:

• What was the rationale for using ?veaction=edit rather than ?action=edit

for VisualEditor?

This. Who the hell thought this was a good idea.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

On 7/22/13, James Forrester jforrester@wikimedia.org wrote:

On 22 July 2013 11:45, Tyler Romeo tylerromeo@gmail.com wrote:

...

Putting all of the issues aside, I'd like to know what the reason is for hiding the preference. Let's assume for a second that VE does not hinder users at all, that it's JS footprint is nonexistent, and that the interface changes aren't that bothersome (which, to an extend, are true). Even with all that, what reason is there to purposely deprive users of the choice to completely hide VE if they're sure they have no intention of using it?

Adding a preference to disable VisualEditor in normal user preferences (rather than making it as easy as possible for gadgets to disable if people so chose) would be a lie.

It would imply that this is a preference that Wikimedia thinks is appropriate. This would be a lie. For a similar example, see the removal of the "disable JavaScript" option from Firefox 23.

It would imply that this is a preference that Wikimedia will support. This would be a lie. We have always intended for VisualEditor to be a wiki-level preference, and for this user-level preference to disappear once the need for an opt-in (i.e., the beta roll-out to production wikis) is over.

It would imply that Wikimedia thinks preference bloat is an appropriate way forward for users. This would be a lie. Each added preference adds to the complexity of our interface, increasing even further the choice paralysis and laughable usability of our existing preference system.

It would imply that Wikimedia thinks preference bloat is an appropriate way forward for expenditure of donor funds. This would be a lie. Each added preference adds to the complexity of our software - so increasing the cost and slowness of development and testing, and the difficulty of user support.

It would imply that Wikimedia can get rid of under-used preferences. This would be a lie. We do not have a successful track record of getting rid of preferences, even when used by a handful of our users, even when set away from default mostly by inactive accounts; accepting this form of product debt now on the spurious claim that we'll pay it off later is untrue.

It would imply that getting rid of preference later rather than now would in any way reduce the outcry. This would be a lie. The very few times we have done this, the arguments from those campaigning for retention are generally emotive and not based on the above points - that "it's just a little preference, not harming anyone", that Wikimedia "has enough money for just this one item", or that the preference is the only thing keeping the user from leaving - an argument that almost always is visibly proven untrue after the preference is removed.

Creating such a preference is a lie, and a lie I cannot endorse.

J.

James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.

jforrester@wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Really? Given the number of inane preferences in Special:Preferences (I'm looking at you preference to disable sending 304 status codes), this is where we're going to draw the line?

A preference for this seems fairly reasonable in my opinion. Especially given that visual editor is not at a fully feature complete state yet (For example, its not enabled in the project namespace as far as I understand)

--bawolff

On Tue, Jul 23, 2013 at 7:19 AM, Brian Wolff bawolff@gmail.com wrote:

Really? Given the number of inane preferences in Special:Preferences (I'm looking at you preference to disable sending 304 status codes), this is where we're going to draw the line?

And also considering the fact that there are going to be gadgets that will eventually be copy pasted into every wiki that has VE, to let people show/hide it. Unless I'm missing something, it doesn't look like a choice between 'have a user preference' and 'not have a user preference' and more like 'have a user preference that works consistently and can be supported' vs 'have people randomly copy paste code from wiki to wiki that just hides UI things, and might break across updates'.

+1 to doing this the right way.

-- Yuvi Panda T http://yuvi.in/blog

On Mon, Jul 22, 2013 at 7:17 PM, Tyler Romeo tylerromeo@gmail.com wrote:

On Mon, Jul 22, 2013 at 9:35 PM, James Forrester jforrester@wikimedia.orgwrote:

...

It would imply that this is a preference that Wikimedia thinks is appropriate. This would be a lie. For a similar example, see the removal

of

...

the "disable JavaScript" option from Firefox 23.

You still haven't explained why this preference is inappropriate.

This is slightly off topic, but removing that preference from firefox is a great idea. It's only used properly by power users, who would be able to do the same in about:config, or via noscript, or will add an extension to do it. That preference is almost always incorrect set by users who don't know what they are doing and it leads to a broken browser experience.

Maybe there's a comparison to be made, but there's not really a simple way to disable VE in MediaWiki other than by having a preference.

Assuming a proper implementation of edit/edit source I'm not sure what the big deal is, but I'm not a hardcore editor so I'm likely just not seeing it.

- Ryan

On Mon, Jul 22, 2013 at 10:25 PM, Ryan Lane rlane32@gmail.com wrote:

Assuming a proper implementation of edit/edit source I'm not sure what the big deal is, but I'm not a hardcore editor so I'm likely just not seeing it.

I don't edit that much myself, so I can't speak first-person here, but I think the primary reason some people want this is because they simply don't plan on using VE whatsoever. They are used to clicking on the Edit tab to get to the main editor, among other minor things. Also, from the WMF perspective, another pro of enabling the preference is that you don't piss off the community that is currently asking very adamantly for this.

Like I said before, though, we have to think of this as pros v. cons. Sure, the pros of enabling this user preference are not that huge (unless there's something else outside of what I mentioned above). However, there are seemingly no cons to enabling it. There are claims of it being too much of a hassle to maintain, which is absurd considering MW's extension infrastructure, and their are claims of it causing preference bloat, which is true, but if that's really the reason we would block this, then I think we should start throwing out other preferences while we're here.

In the end, unless there is some demonstrative reason for disabling this preference (especially the way it is now, using $wgHiddenPrefs, which is not what that variable was meant to be used for), the pros outweight the cons.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

Tyler Romeo wrote:

On Mon, Jul 22, 2013 at 9:35 PM, James Forrester jforrester@wikimedia.orgwrote:

...

Each added preference adds to the complexity of our software - so increasing the cost and slowness of development and testing, and the difficulty of user support.

Stop being so dramatic. This is clearly false.

...

Creating such a preference is a lie, and a lie I cannot endorse.

In conclusion, if you really think lying to the community is so bad, then I recommend the VE team stop doing so as well as stop shoving this propaganda down the community's throat as if VE is the second coming.

Actually, it would probably help if both sides of this debate stopped being so dramatic. No, VE is not the second coming -- of the deity or the devil. No, its developers shouldn't be jamming it down anyone's throats, but I think they do deserve to be at least a little bit proud of their accomplishment, because as we know it's been a very highly desired feature for a long time but has been very difficult to implement.

And on the other side, I don't think people should be calling it broken or a bad idea or dismissing it as something so repugnant that they want to ban it from their sight.

Now, don't get me wrong: I'm a low-level kind of guy, who hasn't used VE and probably never will; matter of fact just yesterday I was pining for the good old days of text formatting using troff. But I believe -- and I don't think this is a controversial belief -- that those of us who prefer markup as opposed to wysiwyg formatting are in a pretty tiny minority. Having a whole preference just so that a handful of people -- power users, no less! -- can hide one unused feature seems odd, a historical accident at best.

Here's a thought experiment: if visual editing had existed (with reasonable functionality) since day 1, would there ever have been a way to disable it, let alone a hue and cry over a lack of a way to disable it?

Now, given that it hasn't existed since day 1, a transition to its existence is bound to be wrenching, but my hunch is that in a year or two all this consternation (over VE's existence, or initial bugginess, or lack of disableability) will be pretty much forgotten.

(Seriously, how hard is it to choose "edit source" if that's what you want to do?)

On 23/07/13 11:35, James Forrester wrote:

It would imply that this is a preference that Wikimedia will support. This would be a lie. We have always intended for VisualEditor to be a wiki-level preference, and for this user-level preference to disappear once the need for an opt-in (i.e., the beta roll-out to production wikis) is over.

The feedback from established users [1] and the results from Aaron Halfaker's study [2] suggest that opt-in would be the most appropriate policy given VE's current level of maturity. That is, disable it by default and re-enable the preference.

A proponent of source editing would claim that the steep learning curve is justified by the end results. A visual editor is easier for new users, but perhaps less convenient for power users. So Aaron Halfaker's study took its measurements at the point in the learning curve where you would expect the benefit of VE to be most clear: the first edit. Despite the question being as favourable to VE as possible, the result strongly favoured the use of source editing:

"Newcomers with the VisualEditor were ~43% less likely to save a single edit than editors with the wikitext editor (x^2=279.4, p<0.001), meaning that Visual Editor presented nearly a 2:1 increase in editing difficulty."

On the Wikipedia RFC question "Wikimedia should disable this software by default?", there were 30 support votes and 17 opposed. But many of those 17 oppose votes assumed that VE is beneficial to new users. Now that we know that that isn't the case, the amount of support for enabling VE by default would surely be very small indeed. If it's not beneficial for either established or new users, why have it?

It's not like the VE team are sitting around with no testing to do, no features to add, and no bugs to work on. So the argument that you need people looking at VE in order to provide feedback seems shallow.

Round-trip bugs, and bugs which cause a given wikitext input to give different HTML in Parsoid compared to MW, should have been detected during automated testing, prior to beta deployment. I don't know why we need users to report them.

Perhaps the main problem is performance. Perhaps new users are especially likely to quit on the first edit because they don't want to wait 25-30 seconds for the interface to load (the time reported in [3]). Performance is a very common complaint for established users also.

[1] https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/RFC

[2] https://meta.wikimedia.org/wiki/Research:VisualEditor%27s_effect_on_newly_registered_editors/Results

[3] https://office.wikimedia.org/wiki/VisualEditor_user_tests

-- Tim Starling

The numbers are important. And perhaps what isn't being reflected well here is the genuine disappointment felt by so many in the enwiki community; there was more excitement about this project than probably any other that WMF has undertaken in the past 5 years. The sudden leap from feature-deficient alpha to deployment as default with untested major features eroded a great deal of the goodwill the community had for this much-requested feature. There still isn't any good explanation of why it didn't go alpha --> opt-in beta with the referencing and templates --> debug, debug, debug --> default deployment. It may not be coming through very clearly, but the editorial community *does* want this to work, and there's a lot of disappointment with what they got.

This was an error in judgment, but it does not need to be a fatal one. The important thing is to do some learning and apply it. Hold off on deploying this software as default editor on other projects until more of the bugs (especially performance related bugs) are resolved, but proceed with opt-in beta on more projects. They'll find bugs that enwiki hasn't found, and those bugs will be found by editors who are interested and motivated to test all kinds of use cases. Enable the opt-out button as a preference on enwiki, and give thought to making it not-default for IPs and new users. English Wikipedia has still paid the price of being the primary launch site, but there's no point in compounding it by making VisualEditor the default for all projects and all editors.

The knock-on effects of this problematic deployment will be felt for a long time, particularly its impact on other products that need VisualEditor to be widely accepted by the community to succeed (such as Flow). The portrayal of editors (and now volunteer and staff developers and engineers) as simply not understanding, or having unreasonable expectations, is not realistic. This was ready for beta testing on July 1; it wasn't ready for deployment to default. Your own internal memoranda (as can be seen by some of the links provided in this thread) indicate serious problems with performance. The publicly available data on Limn[1] is consistently showing less than 10% adoption by experienced users, and only 12% of all edits being done using VE.

Please reconsider the course of action. There is no benefit in putting other projects through this when you have more than enough issues to fix.

Risker

[1]http://ee-dashboard.wmflabs.org/datasources

On 23 July 2013 00:01, David Cuenca dacuetu@gmail.com wrote:

I'm glad that Tim is bringing some facts and numbers that back up what the community is demanding. To do otherwise will be to play tug-of-war which will lead to an even worse outcome.

Besides of enabling the preference, a good approach would be to activate or deactivate that preference depending on how much an user has been using (or not) Visual Editor in their last edits and to ask new users if they want to use VE or the plain text system. "New users" are not that new, since many of them have been editing anonymously before.

When there are more compelling reasons to do the switch (like real-time collaboration), users can have a higher incentive to do the switch.

Micru

On Mon, Jul 22, 2013 at 11:44 PM, Tim Starling <tstarling@wikimedia.org

...

wrote:

...

On 23/07/13 11:35, James Forrester wrote:

...

It would imply that this is a preference that Wikimedia will support. This would be a lie. We have always intended for VisualEditor to be a wiki-level preference, and for this user-level preference to disappear

once

...

the need for an opt-in (i.e., the beta roll-out to production wikis) is over.

The feedback from established users [1] and the results from Aaron Halfaker's study [2] suggest that opt-in would be the most appropriate policy given VE's current level of maturity. That is, disable it by default and re-enable the preference.

A proponent of source editing would claim that the steep learning curve is justified by the end results. A visual editor is easier for new users, but perhaps less convenient for power users. So Aaron Halfaker's study took its measurements at the point in the learning curve where you would expect the benefit of VE to be most clear: the first edit. Despite the question being as favourable to VE as possible, the result strongly favoured the use of source editing:

"Newcomers with the VisualEditor were ~43% less likely to save a single edit than editors with the wikitext editor (x^2=279.4, p<0.001), meaning that Visual Editor presented nearly a 2:1 increase in editing difficulty."

On the Wikipedia RFC question "Wikimedia should disable this software by default?", there were 30 support votes and 17 opposed. But many of those 17 oppose votes assumed that VE is beneficial to new users. Now that we know that that isn't the case, the amount of support for enabling VE by default would surely be very small indeed. If it's not beneficial for either established or new users, why have it?

It's not like the VE team are sitting around with no testing to do, no features to add, and no bugs to work on. So the argument that you need people looking at VE in order to provide feedback seems shallow.

Round-trip bugs, and bugs which cause a given wikitext input to give different HTML in Parsoid compared to MW, should have been detected during automated testing, prior to beta deployment. I don't know why we need users to report them.

Perhaps the main problem is performance. Perhaps new users are especially likely to quit on the first edit because they don't want to wait 25-30 seconds for the interface to load (the time reported in [3]). Performance is a very common complaint for established users also.

[1] https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/RFC

[2] <

https://meta.wikimedia.org/wiki/Research:VisualEditor%27s_effect_on_newly_re...

...

...

[3] https://office.wikimedia.org/wiki/VisualEditor_user_tests

-- Tim Starling

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Etiamsi omnes, ego non _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Mon, Jul 22, 2013 at 8:44 PM, Tim Starling tstarling@wikimedia.org wrote:

and the results from Aaron Halfaker's study [2]

As noted at the top of the page, the analysis is still in progress.

Importantly, there were many confounding variables in the test, some of which are already documented. This includes users being assigned to the test group that received VisualEditor whose browser did not properly support it (it would have literally just not worked if the user attempted to edit); these issues were fixed later. See https://meta.wikimedia.org/wiki/Research:VisualEditor%27s_effect_on_newly_re... for some of these issues, but like I said, analysis is still in progress and we'll need to see what conclusions can actually be drawn from the data.

A proponent of source editing would claim that the steep learning curve is justified by the end results. A visual editor is easier for new users, but perhaps less convenient for power users. So Aaron Halfaker's study took its measurements at the point in the learning curve where you would expect the benefit of VE to be most clear: the first edit.

Actually, as noted in the draft, because the test group was assigned at the point of account creation, we're not taking into account any prior experience using wikitext as an IP editor. 59% of respondents in the 2011 editor survey stated that they had edited as IPs prior to making an account, so we should assume that this is not an insignificant proportion: https://meta.wikimedia.org/wiki/Research:Wikipedia_Editors_Survey_November_2...

Round-trip bugs

If you have, like I have, spent hours looking at VisualEditor diffs, you'll know that these are relatively rare at this point. The bug category of "round-trip bugs" is sometimes used for issues that aren't accurately be described this way, e.g. users typing wikitext into VisualEditor, having difficulty updating a template parameter, or accidentally deleting content (sometimes due to bugs in VE).

Perhaps the main problem is performance. Perhaps new users are especially likely to quit on the first edit because they don't want to wait 25-30 seconds for the interface to load (the time reported in [3]). Performance is a very common complaint for established users also.

You're quoting a user test from June 10 which was performed on the following page, which I've temporarily undeleted:

https://www.mediawiki.org/wiki/Golden-Crowned_Sparrow

Editing this page in Firefox on a 6-year-old system only slightly faster than the tester's specs today takes about 5 seconds to initialize. In Chrome it takes about 3 seconds, in the ballpark of reloading the page into the source editor. Note that Gabriel put major caching improvements into production around June 7, which may not have been in effect for this user / this page yet.

Still, I think that the hypothesis that any actual negative impact of VE on new users is due to performance issues is very supportable. Performance is the single biggest issue overall for VE right now, and performance on long pages can absolutely be prohibitively poor. Improving it is the highest priority for the team.

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

On 23/07/13 15:23, Erik Moeller wrote:

Editing this page in Firefox on a 6-year-old system only slightly faster than the tester's specs today takes about 5 seconds to initialize. In Chrome it takes about 3 seconds, in the ballpark of reloading the page into the source editor. Note that Gabriel put major caching improvements into production around June 7, which may not have been in effect for this user / this page yet.

I tried editing [[Argentina]] on my laptop just now, it took 45 seconds of CPU time and 51 seconds of wall clock time before the percentage CPU usage began to drop. It's pretty slow.

Still, I think that the hypothesis that any actual negative impact of VE on new users is due to performance issues is very supportable. Performance is the single biggest issue overall for VE right now, and performance on long pages can absolutely be prohibitively poor. Improving it is the highest priority for the team.

Is there any estimate as to how much development time it might take to improve performance by an order of magnitude or so, as seems to be required?

-- Tim Starling

On 07/22/2013 10:44 PM, Tim Starling wrote:

Round-trip bugs, and bugs which cause a given wikitext input to give different HTML in Parsoid compared to MW, should have been detected during automated testing, prior to beta deployment. I don't know why we need users to report them.

500+ edits are being done per hour using Visual Editor [1] (less at this time given that it is way past midnight -- I have seen about 700/hour at times). I did go and click on over 100 links and examined the diffs. I did that twice in the last hour. I am happy to report clean diffs on all edits I checked both times. I did run into a couple of nowiki-insertions which is, strictly speaking not erroneous and based on user input, but is more a usability issue. As far as I know, these are caused by a couple usability kinks (1. wikitext entry in VE; 2. linktrail issues). 2. might already have been fixed in VE. 1. is trickier. But, from what I can tell, once these are fixed, they will greatly reduce the number of nowiki escape wrappers added.

This is not to mean that all is perfect in the Parsoid-VE world. But, as of now, I can say quite confidently that VE and Parsoid coordinate well to achieve an extremely high percentage of clean saves. There have been spectacular roundtrip (and parse) failures of course, and those will be there for a while, but they are the exception, not the norm. And, sometimes they are fixed by fixing templates [2] or broken wikitext in pages.

Barring nowiki issues (addressed separately above), given the state of VE and Parsoid as of today, they will not corrupt enwp pages in any significant way. Parsoid itself is regularly put to automated roundtrip testing on 160K pages [3] wherein we catch regressions and fix egregious failures. At this time, the round-trip failures we are addressing in Parsoid are edge cases. We are currently spending our efforts in improving edit support for VE (image support is the one big gap we currently have). We also have some gaps in the HTML output that we generate for wikitext which we are working to achieve parity with the existing PHP parser and this will affect the editability of those pages via VE.

Yes, we fixed some serious bugs in the first 2 weeks of deployment (rather than before deployment), but that is water under the bridge now. Round-trip errors are not an issue in the decision of the preference as far as I can tell.

The timing of the A/B test also seems to have created a lot of understandable confusion around the issue. Maybe a new A/B test is merited after some time.

Subbu.

1. https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&limit=5... 2. http://en.wikipedia.org/w/index.php?title=Template:Contradict-inline&dif... 3. http://parsoid.wmflabs.org:8001/stats

On 23 July 2013 02:32, Subramanya Sastry ssastry@wikimedia.org wrote:

On 07/22/2013 10:44 PM, Tim Starling wrote:

...

Round-trip bugs, and bugs which cause a given wikitext input to give different HTML in Parsoid compared to MW, should have been detected during automated testing, prior to beta deployment. I don't know why we need users to report them.

500+ edits are being done per hour using Visual Editor [1] (less at this time given that it is way past midnight -- I have seen about 700/hour at times). I did go and click on over 100 links and examined the diffs. I did that twice in the last hour. I am happy to report clean diffs on all edits I checked both times. I did run into a couple of nowiki-insertions which is, strictly speaking not erroneous and based on user input, but is more a usability issue.

I do not know where you get the idea that the nowiki insertions are user input errors. Almost without exception, nowiki insertions are done by VE and not by the user, and are inserted in ways that an editor would have no reason to expect one to appear.

<Snip>

The timing of the A/B test also seems to have created a lot of understandable confusion around the issue. Maybe a new A/B test is merited after some time.

You pretty much had one chance at A/B testing, and it's done now. You can't repeat the tests as long as VE is the default editor.

Risker

On Tue, Jul 23, 2013 at 4:32 PM, Subramanya Sastry ssastry@wikimedia.org wrote:

On 07/22/2013 10:44 PM, Tim Starling wrote:

...

Round-trip bugs, and bugs which cause a given wikitext input to give different HTML in Parsoid compared to MW, should have been detected during automated testing, prior to beta deployment. I don't know why we need users to report them.

500+ edits are being done per hour using Visual Editor [1] (less at this time given that it is way past midnight -- I have seen about 700/hour at times). I did go and click on over 100 links and examined the diffs. I did that twice in the last hour. I am happy to report clean diffs on all edits I checked both times.

I did run into a couple of nowiki-insertions which is, strictly speaking not erroneous and based on user input, but is more a usability issue.

What is a dirty diff? One that inserts junk unexpectedly, unrelated to the user's input?

The broken table injection bugs are still happening.

https://en.wikipedia.org/w/index.php?title=Sai_Baba_of_Shirdi&curid=1441...

If the parser isnt going to be fixed quickly to ignore tables it doesnt understand, we need to find the templates and pages with these broken tables - preferably using SQL and heuristics and fix them. The same needs to be done for all the other wikis, otherwise they are going to have the same problems happening randomly, causing lots of grief.

I presume this is also a dirty diff

https://en.wikipedia.org/w/index.php?title=Dubbing_%28filmmaking%29&curi...

In addition to nowikis, there are also wikilinks that are not what the user intended

https://en.wikipedia.org/w/index.php?title=Ben_Tre&curid=1822927&dif... https://en.wikipedia.org/w/index.php?title=Celton_Manx&curid=28176434&am...

Here is three edits to try to add a section header and a sentence, with a wikilink in the section header. (In the process they added other junk into the page, probably unintentionally.)

https://en.wikipedia.org/w/index.php?title=Port_of_Davao&action=history&...

A leading line feed in a parameter - what the?

https://en.wikipedia.org/w/index.php?title=List_of_Sam_%26_Cat_episodes&...

External links which should be converted to internal links:

https://en.wikipedia.org/w/index.php?title=Krishna_%28TV_series%29&diff=...

That is all in the last hour, and I've only checked ~100 diffs.

I appreciate that some of these are a result of user input, and the RC feed of non-VE edits will have similar problems exhibited by newbies, albeit different because it is the source editor. And it is great to see so many constructive VE edits. But you're not going to get much love by claiming that it is now stable and not causing broken diffs. In addition, VE can crash a Google Chrome tab, and it can cause (unsaved changes) dataloss in most browser configurations.

On 23 jul. 2013, at 18:06, Subramanya Sastry ssastry@wikimedia.org wrote:

...

A leading line feed in a parameter - what the?

https://en.wikipedia.org/w/index.php?title=List_of_Sam_%26_Cat_episodes&...

This is something I'll have to investigate.

This is probably actually desirable (lists starting at the beginning of the line). It should however have preserved the newline before the argument separator that is following this list value.

DJ

Why do you think those <nowiki> tags were added by the editors?

Risker

On 23 July 2013 15:32, Robert Rohde rarohde@gmail.com wrote:

In the interest of gathering slightly larger statistics, I manually reviewed 200 VE entries on recent changes.

I am classifying these as

• "Good" edit
• Test edits / newbie errors likely to happen in either editor (not VE's

fault)

• Obvious vandal edit (not VE's fault)
• Damaged source that renders correctly (e.g. VE altering source

formatting that most source editors like to maintain, mostly involving missing newlines)

• Test edits / newbie errors that occur with VE but were unlikely to

occur previously (e.g. people using lots of extra spaces / newlines to visually "format" the positioning of content on a page)

• Corrupted page content that appears to be caused by the unfamiliar

UI (e.g. <nowiki>[[Foo]]</nowiki>)

• Corrupted page content that appears to be directly caused by VE /

Parsoid bugs (e.g. dirty diffs)

For the sake of simplicity, I'm counting any edit that is well-formed and not obviously of destructive intent as "good" without consideration of whether it satisfies Wikipedia content policies such as NPOV, OR, etc. There are inevitably many edits whose content isn't appropriate or needs to be cleaned up, but I'm not worrying about those. In the rare case that an edit might fall in multiple categories, I'm counting it towards the most severe of the categories listed above (i.e. lower on the list). This only applied a handful of times.

Altogether, I rated the edits as follows:

• "Good": 157 (78.5%)
• Test / newbie edits (generic): 13 (6.5%)
• Obvious vandal: 7 (3.5%)
• Damaged source: 7 (3.5%)
• Test / newbie edits (VE oriented): 3 (1.5%)
• Corrupted page due to unfamiliar UI: 11 (5.5%)
• VE / Parsoid errors: 1 (0.5%) [This involved the editor spewing out

extra garbage when trying to save a page that started with malformed table syntax.]

That's better than I would have guessed before going into this exercise. In particular, Subbu appears to be correct that the true error rate for VE / Parsoid is relatively small (though I'd prefer the error rate be too small to notice in a test like this).

The tendency of users to add nowikis and create other corruptions due to the unfamiliar UI is still a concern though. This is not at all helped by the fact we have dozen of help pages that teach wiki syntax like "[[Foo]]" which are now directly unhelpful to people using VE. Over time, that will diminish somewhat as experienced users learn the new system, though if it is truly to be useful for new users we probably want to look carefully at the various ways new users may misunderstand the new UI. Also, I'm not thrilled by the examples of VE manipulating the use of newlines so that template parameters, categories, and other things sometimes run together in the source.

If the immediate goal is to ensure that using VE is not harmful for people who know how to use it, then the developers are probably getting pretty close. Given the nowikis and such, VE probably still causes higher levels of accidental harm when operated by unfamiliar users than I would personally be comfortable with. And of course, there is still a long ways to go in terms of feature completeness and usability before we can really discuss Erik's dream of having VE be perceived as better than source editing.

-Robert Rohde

On Tue, Jul 23, 2013 at 9:06 AM, Subramanya Sastry ssastry@wikimedia.org wrote:

...

Hi John and Risker,

First off, I do want to once again clarify that my intention in the

previous

...

post was not to claim that VE/Parsoid is perfect. It was more that we've fixed sufficient bugs at this point that the most significant "bugs"

(bugs,

...

not missing features) that need fixing (and are being fixed) are those

that

...

have to do with usability tweaks. My intention in that post was also not one to put some distance between us and the complaints, just to clarify

that

...

we are fixing things as fast as we can and it can be seen in the recent changes stream.

John: specific answers to the edit diffs you highlighted in your post. I acknowledge your intention to make sure we dont make false claims about VE/Parsoid's usability. Thanks for taking the time for digging them up. My answers below are made with an intention of figuring out what the

issues

...

are so they can be fixed where they need to be.

On 07/23/2013 02:50 AM, John Vandenberg wrote:

...

On Tue, Jul 23, 2013 at 4:32 PM, Subramanya Sastry ssastry@wikimedia.org wrote:

...

On 07/22/2013 10:44 PM, Tim Starling wrote:

...

Round-trip bugs, and bugs which cause a given wikitext input to give different HTML in Parsoid compared to MW, should have been detected during automated testing, prior to beta deployment. I don't know why we need users to report them.

500+ edits are being done per hour using Visual Editor [1] (less at

this

...

...

...

time given that it is way past midnight -- I have seen about 700/hour

at

...

...

...

times). I did go and click on over 100 links and examined the diffs.

I

...

...

...

did that twice in the last hour. I am happy to report clean diffs on all edits I checked both times.

I did run into a couple of nowiki-insertions which is, strictly speaking not erroneous and based on user input, but is

more

...

...

...

a usability issue.

What is a dirty diff? One that inserts junk unexpectedly, unrelated to the user's input?

That is correct. Strictly speaking, yes, any changes to the wikitext

markup

...

that arose from what the user didn't change.

...

The broken table injection bugs are still happening.

https://en.wikipedia.org/w/index.php?title=Sai_Baba_of_Shirdi&curid=1441...

...

...

If the parser isnt going to be fixed quickly to ignore tables it doesnt understand, we need to find the templates and pages with these broken tables - preferably using SQL and heuristics and fix them. The same needs to be done for all the other wikis, otherwise they are going to have the same problems happening randomly, causing lots of grief.

This maybe related to this: https://bugzilla.wikimedia.org/show_bug.cgi?id=51217 and I have a

tentative

...

fix for it as of y'day.

VE and Parsoid devs have put in a lot and lot of effort to recognize

broken

...

wikitext source, fix it or isolate it, and protect it across edits, and roundtrip it back in original form to prevent corruption. I think we

have

...

been largely successful but we still have more cases to go that are being exposed here which we will fix. But, occasionally, these kind of errors

do

...

show up -- and we ask for your patience as we fix these. Once again,

this

...

is not a claim to perfection, but a claim that this is not a significant source of corrupt edits. But, yes even a 0.1% error rate does mean a big number in the absolute when thousands of pages are being edited -- and we will continue to pare this down.

...

I presume this is also a dirty diff

https://en.wikipedia.org/w/index.php?title=Dubbing_%28filmmaking%29&curi...

...

Yes, this is a dirty diff where Parsoid reformatted a 2-line image

wikitext

...

source into one by removing a line break. Again, relative to the # of

edits

...

being made, these are not frequent -- that was all that I claimed, which

I

...

think is still true. But that said, this is a relatively minor and

harmless

...

change.

...

In addition to nowikis, there are also wikilinks that are not what the user intended

https://en.wikipedia.org/w/index.php?title=Ben_Tre&curid=1822927&dif...

...

...

https://en.wikipedia.org/w/index.php?title=Celton_Manx&curid=28176434&am...

...

You are correct, but this is not a dirty diff. I dont want to claim

this is

...

an user error entirely -- but a combination of user and software error.

...

Here is three edits to try to add a section header and a sentence, with a wikilink in the section header. (In the process they added other junk into the page, probably unintentionally.)

https://en.wikipedia.org/w/index.php?title=Port_of_Davao&action=history&...

...

What is the problem here exactly? (that is a question, not a challenge). The user might have entered those newlines as well.

...

A leading line feed in a parameter - what the?

https://en.wikipedia.org/w/index.php?title=List_of_Sam_%26_Cat_episodes&...

...

This is something I'll have to investigate.

...

External links which should be converted to internal links:

https://en.wikipedia.org/w/index.php?title=Krishna_%28TV_series%29&diff=...

...

This could be an enhancement to Parsoid. Thanks for the bug report :-).

...

That is all in the last hour, and I've only checked ~100 diffs.

I appreciate that some of these are a result of user input, and the RC feed of non-VE edits will have similar problems exhibited by newbies, albeit different because it is the source editor. And it is great to see so many constructive VE edits.

Thank you for acknowledging this!

...

But you're not going to get much love by claiming that it is now stable and not causing broken diffs.

I did not make that specific claim, but it is possible that my tone was

more

...

aggressive than I intended it to be. Just so there is no confusion, VE/Parsoid can still cause dirty/broken diffs, but I think the claim is

that

...

at this time, the vast majority of ongoing edits do not corrupt wikitext source and where there are diffs, we have narrowed that down to a couple

of

...

causes (where VE/Parsoid inserts nowiki wrappers) which are being fixed.

...

In addition, VE can crash a Google Chrome tab, and it can cause (unsaved changes) dataloss in most browser configurations.

Subbu.

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Please change the subject and use a different thread if you intend to discuss the usefulness or accuracy of VE, because as I just said, that's not the subject of this thread.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

On Tue, Jul 23, 2013 at 3:44 PM, Daniel Barrett danb@vistaprint.com wrote:

Risker asks:

...

Why do you think those <nowiki> tags were added by the editors?

I can't speak for the original poster, but the last time I used VE, it added unwanted <nowiki> tags by itself. You can see an example in my most recent bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=51829

DanB _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Tue, Jul 23, 2013 at 1:42 PM, Roan Kattouw roan.kattouw@gmail.comwrote:

On Tue, Jul 23, 2013 at 12:44 PM, Daniel Barrett danb@vistaprint.com wrote:

...

Risker asks:

Of course those <nowiki> tags weren't added by the editors, VE doesn't let you do that directly. What I think Robert was talking about (thanks for that analysis, BTW!) is edits where the user typed something like "[[Foo]]" into the editor, and Parsoid, in order to achieve a truthful rendering of "[[Foo]]", wraps it in <nowiki> tags. That's a case of "we did what the user asked us to do, although the user probably didn't mean that".

...

These kinds of technically-correct-but-probably-not-what-you-wanted issues are a bit tricky. They're on our list of things to deal with though.

FWIW, the WYSIWYG editor for the Socialtext wiki handles these cases well, and has since at least 2007 or so. I think Wikia is (or was) using some derivative of this "Wikiwyg" editor. Regardless, it might be a useful oracle for VE behavior.

Whoops, didn't realize this thread had been forked off while I was out to lunch, and so I responded to the other thread. Sorry about that :(

On Tue, Jul 23, 2013 at 1:11 PM, Steve Summit scs@eskimo.com wrote:

This is a likely enough mistake, and the number of times you really want explicit double square brackets is small enough, that it's worth thinking about (if it hasn't been already) having VE detect and DTRT when a user types that.

VE does detect this and warn the user, but there's a bug that makes the warning bubble appear out of view if you're not scrolled all the way up to the top. One of our team members is working on fixing that right now.

Roan

On Tue, Jul 23, 2013 at 2:14 PM, John Vandenberg jayvdb@gmail.com wrote:

There is an enhancement for that.

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

IMO the current behaviour isnt correct. There are so few instances that nowiki is desirable, that the current VE should refuse to accept wikitext (at least [[ and {{, and maybe ==, # and * at beginning of line, etc ), until at least such time as they have sorted out all the other bugs causing this to happen unintentionally. If the user needs to input [[ or {{ they can use the source editor. Or the VE could walk the user through each nowiki and either a) ask the user to confirm they want the obvious fix done automatically for them, or b) help them fix the problem. Before saving.

We disagree on that one then. VisualEditor is meant to hide wikitext entirely. The primary focus is on people that don't know wikitext. I agree that we should keep nowiki-fication to a minimum and get rid of the other bugs that cause this to happen, but I think the action we currently take when a user types in wikitext (which is to warn them and say "this won't work") is appropriate. VE is meant to be a visual editor, not a visual-except-with-weird-shortcuts-that-only-make-sense-if-you-know-the-legacy-markup-we-used-before-your-time editor.

That's my opinion. Actual product direction is not something I'm in charge of, that's James F's job, but AFAIK our current product direction is similar to what I just said.

nowiki is also being inserted at beginning of lines.

https://es.wikipedia.org/w/index.php?title=Yacimiento_de_Son_Forn%C3%A9s&... https://fr.wikipedia.org/w/index.php?title=Joel_Lindpere&curid=5580501&a...

That's because the lines start with a space, which triggers a <pre> if not nowiki-ed. Obviously the correct thing to do there is just remove the space, but we haven't fixed that yet.

instead of lists

https://es.wikipedia.org/w/index.php?title=Jorge_Eslava&diff=68542729&am...

Once again that's people typing wikitext into VE, which is not supported.

There are 24 open bugs for 'visualeditor nowiki'

https://bugzilla.wikimedia.org/buglist.cgi?title=Special%3ASearch&quicks...

A lot of those are parts of symptoms of other bugs, and I'm pretty sure a few of them are duplicates. <nowiki> often appears when something else goes wrong and Parsoid attempts to fix things.

Roan

On Mon, Jul 22, 2013 at 8:44 PM, Tim Starling tstarling@wikimedia.org wrote:

"Newcomers with the VisualEditor were ~43% less likely to save a single edit than editors with the wikitext editor (x^2=279.4, p<0.001), meaning that Visual Editor presented nearly a 2:1 increase in editing difficulty."

For the record, this datapoint included in the draft (!) analysis was due to faulty instrumentation. The correct numbers show only a marginally significant difference between VisualEditor and wikitext for an edit within 72 hours [1], with the caveats already given in my earlier response.

Erik

[1] https://meta.wikimedia.org/wiki/Research:VisualEditor%27s_effect_on_newly_re...

James Forrester wrote:

​Creating such a preference is a lie, and a lie I cannot endorse.

Oh, for Christ's sake, James. The last thing this thread needs is very bad pseudo-poetry. And that's not a lie.

What we need is for you and Erik to recognize that you're wrong and to make this right. Is there anyone besides you and Erik who agree with the position you're taking here?

You may not respect my opinion or the opinion of the many editors who have expressed the same opinion on-wiki, but I would think you could show a little professionalism and a little deference to your colleagues and peers, _all_ of whom have tried, as diplomatically as possible, to tell you that you're wrong without completely undermining your role as the Product Manager of VisualEditor.

You're very quickly exhausting good will both inside and outside the Wikimedia Foundation. You're eroding public support for VisualEditor and _every future project_ you'd like to work on/lead at the Wikimedia Foundation. And for what? Please be reasonable and do the right thing.

MZMcBride

On Mon, Jul 22, 2013 at 6:35 PM, James Forrester jforrester@wikimedia.org wrote:

It would imply that Wikimedia thinks preference bloat is an appropriate way forward for expenditure of donor funds. This would be a lie. Each added preference adds to the complexity of our software - so increasing the cost and slowness of development and testing, and the difficulty of user support.

I want to elaborate on this point a bit, because some of the complexity cost may have gotten lost in the discussion so far.

It is true that providing a mechanism to hide all evidence of VisualEditor, as it currently exists, from the user interface entirely is utterly trivial, from a technical standpoint.

However, it is important to note that VisualEditor is not purely a means of editing pages, but will also provide, in future,

- a mechanism for quickly performing simple metadata manipulation (e.g. categories); - a subset of rich-text editing functionality for edit summaries, log entries, etc.; - a default interface for posting or replying to comments (in Flow); - etc.

On the first point, right now, we're approaching categories and similar page metadata from the point of view of the editing surface as an entrypoint. This makes sense if you simply try to map all aspects of markup (which is inherently positional, even where it carries no positional value like categories) into an editing interface. VE is at least providing a "Page Settings" dialog that gets rid of the positional context for categories, etc.

However, from a user's standpoint, it still doesn't make a ton of sense to do it that way. If I just want to add a category, I shouldn't have to invoke an editing surface at all. Similarly, if I want to turn a page into a redirect, I shouldn't have to edit the page at all. As most of you know, some gadgets like HotCat already operate on a similar principle.

The VisualEditor team is going to revisit some of these types of edit operations from the standpoint of "what's the fastest and most intuitive way to perform this operation" rather than "how do we integrate this with the editing interface".

So, when a user has "disabled VisualEditor", should those affordances then also disappear, if they happen to be provided through the VisualEditor MediaWiki extension? Should VE be hidden from view in contexts where it could be safely and speedily initialized, on new content without the complexity of existing pages?

As VisualEditor becomes more pervasive in the user experience, the complexity of maintaining a preference in a consistent and non-confusing manner will go up, and the cost of having users who could otherwise successfully use VE not see it will increase as well. Users who hate VE for editing articles with templates might not hate it for writing comments, but if they have that preference set, they might never see it for the latter use case.

This is one other reason why we think it's preferable to focus on ensuring that the user experience _with VE present_ is minimally disruptive, rather than creating a preference that completely hides VE from view, and could in future be potentially misleading and/or harmful to the user experience.

In other words, as we add VE in other contexts, we'll also want to make sure that source mode is easily accessible in all those contexts, and that there is always a default fallback on browsers where VE can't be used.

I'm not saying that we can't find a compromise here - just that there's more long term complexity than one might see immediately. One compromise I could imagine is to offer a preference for the preferred _default_ editor, and honor it consistently (in the labeling of the tabs, in whatever mode gets primary presence in contexts where we can't offer a choice, etc.).

Erik

On Tue, Jul 23, 2013 at 2:35 AM, Erik Moeller erik@wikimedia.org wrote:

On the first point, right now, we're approaching categories and similar page metadata from the point of view of the editing surface as an entrypoint. This makes sense if you simply try to map all aspects of markup (which is inherently positional, even where it carries no positional value like categories) into an editing interface. VE is at least providing a "Page Settings" dialog that gets rid of the positional context for categories, etc.

However, from a user's standpoint, it still doesn't make a ton of sense to do it that way. If I just want to add a category, I shouldn't have to invoke an editing surface at all. Similarly, if I want to turn a page into a redirect, I shouldn't have to edit the page at all. As most of you know, some gadgets like HotCat already operate on a similar principle.

Why should VE be doing this if you're not entering the editor. HotCat (and the future extension based on it) can handle categories just fine. The VE team should focus on fixing its current issues before attempting to introduce new features.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

I just want to be absolutely clear, for the purposes of solving this problem and staying on topic, we are *not* discussing:

* Whether VE is a good product or not (it clearly is) * Whether VE should be deployed or not (it already is) * Whether VE should have an option to be disabled (it already has)

The real root of this discussion is whether or not the method through which VE is disabled is done as a Gadget or as a user preference. Both methods are already implemented, it's just a matter of a configuration variable.

With that said, I'd like to see more points on what real motivation there is to force users to have a gadget to do something that an existing user preference already does.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

On Tue, Jul 23, 2013 at 10:59 AM, Derric Atzrott < datzrott@alizeepathology.com> wrote:

...

...

However, from a user's standpoint, it still doesn't make a ton of sense to do it that way. If I just want to add a category, I shouldn't have to invoke an editing surface at all. Similarly, if I want to turn a page into a redirect, I shouldn't have to edit the page at all. As most of you know, some gadgets like HotCat already operate on a similar principle.

Why should VE be doing this if you're not entering the editor. HotCat (and the future extension based on it) can handle categories just fine. The VE team should focus on fixing its current issues before attempting to introduce new features.

I agree with Tyler here. This should really be deployed as a separate extension that perhaps makes use of Visual Editor. I also agree with the sentiment that we need to fix the current issues before we try to add more features, though looking towards the future is still reasonable.

Also I don't see why we can't work out that problem though when it arrives. Currently we have a very immediate issue though of the masses politely requesting and then demanding that this option be added back. If we need to remove it again later, I don't see why we can't.

There were a large number of us who argued that this deployment was inappropriate to begin with, and I personally still stand by that. Visual Editor is not yet ready for the masses and the masses have made it clear that they don't want to use it (see source edits vs visual edits as discussed earlier). We're not asking that you disable Visual Editor as the default editor, if you still feel that it needs to be the default in order to collect the data you need for bug testing, that's fine by me (though I continue to disagree with the decision), go ahead and do that. For the people though that do not foresee themselves using Visual Editor anytime soon, it would be nice for them to have an option that isn’t a hack.

I know I'm repeating arguments here that have already been covered in previous posts, but I really think that adding the option back is the way to go. I would go as far as to say enable the option and then continue the discussion as to whether or not the option is appropriate. Every day that passes that it is not around is another huge PR hit for all of us developer types.

From what I have seen on this mailing list the past few days, please correct me if I am wrong, is that the community feels frustrated that the product team for Visual Editor is failing to acknowledge their needs. Enabling this preference would likely clear the air a lot and allow us to have a much saner discussion as to the direction this project needs to go.

Thank you, Derric Atzrott

ps. Really looking forward to when Visual Editor is done. This has been the most exciting extension I've seen in a long time and I really do want it to succeed. I've seen a large many people turned off by Wikitext, but we can't afford to create the rift we are making right now.

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Thank you for changing your mind. I might have missed something, but is there any schedule for when VisualEditor will be considered 'out of beta'? Or is it simply a case of the VE team deciding that it's stable enough?

Alex Monk

On Wed, Jul 24, 2013 at 2:55 AM, James Forrester jforrester@wikimedia.orgwrote:

Because I understand the level of concern that this matter is causing, I am changing my mind on this. For the duration of VisualEditor's "beta" period, there will be an opt-out user preference. This will be deployed tomorrow morning, San Francisco time. Once VisualEditor is out of 'beta', this preference will be removed.

Alex,

On Jul 23, 2013, at 7:22 PM, Alex Monk krenair@gmail.com wrote:

Thank you for changing your mind. I might have missed something, but is there any schedule for when VisualEditor will be considered 'out of beta'?

You have not missed something. There is no schedule yet for "out of beta" and it's still to early to make an accurate estimate for that.

Or is it simply a case of the VE team deciding that it's stable enough?

It's not going to be as simple as this either. ;-)

Take care,

terry

Tyler Romeo,

On Jul 23, 2013, at 8:55 PM, Tyler Romeo tylerromeo@gmail.com wrote:

On Tue, Jul 23, 2013 at 9:55 PM, James Forrester jforrester@wikimedia.orgwrote:

...

I hope that as few users as possible will choose this way to degrade their experience and deprive the community of their input. Instead of endlessly arguing the point about this, I'd rather my team and I spending our time working to make our sites better.

I don't understand. Are you purposely trying to instigate this matter?

Whoa. Them's fighting words! :-D

All of a sudden just because somebody prefers editing source code they're "depriving the community".

I prefer editing in source mode (at least based on my edit history). But I don't feel the need to turn on this preference. I didn't find it too hard to click "Edit Source" after the first day. We are not talking about people who prefer to edit source at all. We are talking about people who find clicking "Edit Source" so inconveniencing that they need to enable a gadget to remove it completely from the UI. Unless you really want to go all phoenixoverride on how 2.9K is the end-of-wikipedia-as-we-know-it.

For full disclosure, the VE team reports to me so maybe that makes me biased. I don't know. I think this makes me embarrassed and a little guilty that I don't use VE more. :-D

Or do you seriously believe that there is literally nothing better than VE and that VE is the choice for everybody?

You may not have meant it, but this is a fallacy of False Choice. What is being talked about isn't "forcing" people to use VE, but hiding VE from the UI completely. There's a lot in the UI on the wikis, I have never used, nor plan to, so really this sturm and drang among engineers about what makes correct UI or good product design. Engineering has weighed in as to the patch as it stands, and this is a product decision. As you put it earlier:

The real root of this discussion is whether or not the method through which VE is disabled is done as a Gadget or as a user preference. Both methods are already implemented, it's just a matter of a configuration variable.

With that said, I'd like to see more points on what real motivation there is to force users to have a gadget to do something that an existing user preference already does.

Which is really a way of saying, "This isn't an engineering issue (yet), so what is the product and UI reasoning here?"

The reasoning from product (James and Erik earlier in this thread, as well as the FAQ linked to by C Scott) was well thought out in the choice to refuse this patch. Equally well thought out was the reversal of such a decision.

(By well thought out I mean better reasoned than either I personally would have made, or seen in the discussion on this thread. But then again, I'm an engineer, I don't go dictating to product mangers how to design the product or designers how to do UI. Instead I, and I expect the same from my team, to inform product managers and designers as the engineering consequences and costs. I believe if we make decisions that are informed from (but not dictated by) engineering, product, design, data and the community, we end up with a better outcome. Weird as it may sound, I assume good faith on their part and they have yet to let me, or my teams, down.)

Once VisualEditor is out of 'beta', this preference will be removed.

What you meant to say is that when VE comes out of "beta", you'll post to this mailing list again so we can discuss whether the user preference is still appropriate. And if it's decided that it's no longer needed, then it will be removed.

No. I may be wrong, but I think he said what he meant to say exactly as he said it.

It's a valid interpretation of good faith complaints about the VE rollout. E3 has a opt-out preference against experimental features. To the extent that VE is a beta product, which nobody denies, then it would behoove us to make a similar option available to VE for when VE is in "beta." That reasoning is very sound.

I've read the discussion on this thread, and I found none of it actually addresses the reasoning guiding the VE feature to not allow this preference. Erik has given a long discussion why, from an engineering perspective, a no-op right now would add technical debt in the future and complicate the product roadmap today. James has given a long discussion why, from a product perspective, adding the opt-out would be lying to the users about VE. All of that is nearly identical to the FAQ reposted by Scott. Even James's reversal on the opt-out is consistent with that original reasoning (same reasoning, different outcome).

What I read in direct response to those three e-mails often (not always) consisted of a lot of snark, and a fundamental mistrust of product experts to be experts in…product. I read some data and studies that were linked to that were misused and against specific admonitions by the data analysts (I prefer to think it was an accidental misreading of the studies), I read some discussions that disputed some other data that informed the reasoning that were, while factual, deceptive (e.g. taking page times on huge pages that even the best HTML editors die on). BTW, I do not think any of that was necessarily bad faith, I feel that people here, in their passion of the moment, did not read closely what was being said. I know I've been guilty of selective reading, when I am emotional.

I also read a lot of very good faith complaints and discussion. Some of it was deemed off-topic on a thread that is entirely on-topic for an engineering list. But none of this refuted the actual reasoning and a good amount of it supported it. It did, however, speak to the fact that a preference vs. none is a choice that should be re-examined. A number of my engineers took those good faith issues and lobbied on your behalf for the preference to be added. They lobbied based on the reasoning product used in their original decision.

On Jul 23, 2013, at 12:12 PM, Bartosz Dziewoński matma.rex@gmail.com wrote:

On a side note, I find it interesting how none of the actual VE and Parsoid developers replied here, apart from Roan, Chris and Subbu on off-topic technical issues (thanks for that).

I am glad that they stuck to actual engineering issues too. With their discipline to stick to engineering, they make me look far better than I deserve as their "manager." And, if you saw their behavior off-list on your behalf, you'd be surprised even more.

I'll take exception to them being "off-topic technical issues" on a mailing list that is [Wikitech-l]. But that's me. :-D

Take care,

terry

On Jul 25, 2013 6:18 PM, "Tyler Romeo" tylerromeo@gmail.com wrote:

On Thu, Jul 25, 2013 at 2:16 AM, Terry Chay tchay@wikimedia.org wrote:

...

Whoa. Them's fighting words! :-D

Yeah I'm sorry if that came off as aggressive, but this entire

conversation

has had the air of "the VE team has decided this, but maybe they'll be gracious enough to compromise with you". Hell, even when James "changed

his

mind", the email was more of a "well that's what we thought as well, so we'll allow you to have this, but only under our conditions".

I assume good faith, but after the "and that would be a lie" email, it was kind of hard to maintain that assumption. Just once I'd like to see a discussion that doesn't dismiss other people's arguments and opinions.

Also, I found the VE statistics pretty interesting. :)

Erik has given a long discussion why, from an engineering perspective, a

...

no-op right now would add technical debt in the future and complicate

the

...

product roadmap today. [...] All of that is nearly identical to the FAQ reposted by Scott.

The only discussion of this nature was when Erik was discussing possible future features for VE. If any of those features come to fruition, then I would understand removing the user option, but right now those features do not exist.

No. I may be wrong, but I think he said what he meant to say exactly as he

...

said it.

It's a valid interpretation of good faith complaints about the VE

rollout.

...

E3 has a opt-out preference against experimental features. To the extent that VE is a beta product, which nobody denies, then it would behoove

us to

...

make a similar option available to VE for when VE is in "beta." That reasoning is very sound.

I'm aware that was what he meant. I was being sarcastic. Like I said before, this was along the same lines of "the VE team decides all and nobody else has a say", which is the wrong way to approach this. If we're supposed to be a community, why wouldn't the first option be to ask the community before making such changes?

I'm still wondering, when the call was made to disable this option, was it expected this would cause massive resistance? If not, what is the WMF planning to do to better judge that in the future (because imo this was a predictable reaction)? And if so, why was this done silently?

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Jul 25, 2013 8:02 PM, "Tyler Romeo" tylerromeo@gmail.com wrote:

On Thu, Jul 25, 2013 at 1:11 PM, Martijn Hoekstra <

martijnhoekstra@gmail.com

...

wrote:

...

I'm still wondering, when the call was made to disable this option, was

it

...

expected this would cause massive resistance? If not, what is the WMF planning to do to better judge that in the future (because imo this was

a

...

predictable reaction)? And if so, why was this done silently?

It wasn't decided. There was a bug with the user preference where the

label

on the preference was incorrect. In order to fix this, the option was disabled.

That's a de facto decision isn't it? Somebody figured flipping that switch without discussing it with the wikis first was a good idea. The question still stands: if they didn't expect this fall out, why not, and if they did, why keep quiet?

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Jul 25, 2013 8:09 PM, "Tyler Romeo" tylerromeo@gmail.com wrote:

On Thu, Jul 25, 2013 at 2:05 PM, Martijn Hoekstra <

martijnhoekstra@gmail.com

...

wrote:

...

That's a de facto decision isn't it? Somebody figured flipping that

switch

...

without discussing it with the wikis first was a good idea. The question still stands: if they didn't expect this fall out, why not, and if they did, why keep quiet?

Well the thing is it wasn't turned off because they wanted to turn it off. It was turned off because the message was incorrect, and the development required to fix it would have taken a significant amount of time. It does sort of count as a de facto decision, but I don't imagine community

fallout

would have been taken into account since it was an engineering decision

and

not a product decision.

I find that somewhat hard to believe, but if it is true, should that worry us? I'm not sure that we should be comfortable with changes like these not giving pause to our engineers.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 25 July 2013 14:20, Tyler Romeo tylerromeo@gmail.com wrote:

On Thu, Jul 25, 2013 at 2:15 PM, Martijn Hoekstra < martijnhoekstra@gmail.com

...

wrote:

...

I find that somewhat hard to believe, but if it is true, should that

worry

...

us? I'm not sure that we should be comfortable with changes like these

not

...

giving pause to our engineers.

Well to be quite honest it was a pretty reasonable decision. I mean, if enabling an option all of a sudden broke Wikipedia, it makes sense to disable that option until it is fixed. Maybe the issue wasn't so big a deal such that it needed to be immediately disabled, but nonetheless it's a decision I trust the operations team to make.

The preference didn't break anything. It had been active for months during the alpha testing. It was a conscious decision not to permit its continued use after the deployment on July 1, and the way that it was "disabled" was by hiding it.

Those of you who know more about the system than do I pointed out that hiding the preference wasn't the appropriate step and if the VE team wanted to remove the option, it should be written out on their end. But the preference had been active for months before the July 1 deployment.

Risker

On 25 July 2013 11:00, Tyler Romeo tylerromeo@gmail.com wrote:

On Thu, Jul 25, 2013 at 1:11 PM, Martijn Hoekstra < martijnhoekstra@gmail.com

...

wrote:

...

I'm still wondering, when the call was made to disable this option, was

it

...

expected this would cause massive resistance? If not, what is the WMF planning to do to better judge that in the future (because imo this was a predictable reaction)? And if so, why was this done silently?

It wasn't decided. There was a bug with the user preference where the label on the preference was incorrect. In order to fix this, the option was disabled.

​That's just flatly wrong. Removing the preference was always the intention and had been mentioned several times​. The reminder that we needed to fix the issue immediately because it was affecting MediaWiki.org in a number of ways including the preference wrongly showing up caused me into fixing the issue.

The problem about the alpha opt-in preference label needing to be manually updated to cover what namespaces the alpha is enabled in has not been fixed yet (and probably won't be by the team, given that this preference is not long for this world).

J.

I have avoided getting involved so I could stay focused on fixing bugs and making improvements to VisualEditor.

This thread has served it's purpose; to surface various arguments about whether the preference to disable VisualEditor should be hidden or not. The conclusion has been reached. The preference is now available to opt out while VisualEditor is in beta. The patch as been deployed, and we all need to get back to work.

I would like to politely ask us to put this thread to rest so we can all get back to our respective tasks at hand.

Thank you all for your participation, I am glad we were able to resolve this.

- Trevor

On Thu, Jul 25, 2013 at 12:45 PM, Tyler Romeo tylerromeo@gmail.com wrote:

On Thu, Jul 25, 2013 at 3:23 PM, James Forrester jforrester@wikimedia.orgwrote:

...

That's just flatly wrong. Removing the preference was always the

intention

...

and had been mentioned several times.

See here it is again. Was is absolutely necessary to say I was "flatly wrong"? This thread began with mentions of the original patchset in which the $wgHiddenPrefs was enabled *because of the messages error* so I don't see how it was such a terrible conclusion to come to.

I made the call about a year ago, and mentioned it in several of the

...

dozens of mailing list and on-wiki posts made about the development of VisualEditor since then. Clearly my communication about it wasn't read,

or

...

wasn't understood, by the people who subsequently complained, but I wouldn't describe it as being "done silently".

Could you maybe link to where you emailed wikitech about this, because I just searched my Gmail and found no such email.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I made the call about a year ago, and mentioned it in several of the dozens of mailing list and on-wiki posts made about the development of VisualEditor since then. Clearly my communication about it wasn't read, or wasn't understood, by the people who subsequently complained, but I wouldn't describe it as being "done silently".

Users respond to things that happen to them and especially at the point in time when they are negatively affected by something. Its unrealistic to expect users to respond to comments about a piece of software before they have to deal with it.

This thread has served it's purpose; to surface various arguments about whether the preference to disable VisualEditor should be hidden or not.

It's debatable if this thread was ever really about that.

-bawolff

On 25 July 2013 10:11, Martijn Hoekstra martijnhoekstra@gmail.com wrote:

I'm still wondering, when the call was made to disable this option, was it expected this would cause massive resistance? If not, what is the WMF planning to do to better judge that in the future (because imo this was a predictable reaction)? And if so, why was this done silently?

​I made the call about a year ago, and mentioned it in several of the dozens of mailing list and on-wiki posts made about the development of VisualEditor since then. Clearly my communication about it wasn't read, or wasn't understood, by the people who subsequently complained, but I wouldn't describe it as being "done silently".

​Yours,

On 25 July 2013 17:17, Tyler Romeo tylerromeo@gmail.com wrote:

I assume good faith, but after the "and that would be a lie" email, it was kind of hard to maintain that assumption. Just once I'd like to see a discussion that doesn't dismiss other people's arguments and opinions.

It would also be nice to see WMF staff not using the term "power users" as a snarl word. Perhaps this will happen.

- d.

On Mon, Jul 22, 2013 at 3:00 PM, Antoine Musso hashar+wmf@free.fr wrote:

The reason I did not deploy that change on sight it is that it goes against bug 48666 which asked to hide the preference:

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

Since I was not willing to enter an revert war in both Gerrit and Bugzilla, I thought the best would be to talk about it among the eng community.

Completely understandable, but I should note that the reason that bug was filed and merged had nothing to do with whether the preference should be enabled or not. It was just hidden because the messages were confusing. So rather than fixing the interface messages, they just hid the preference instead.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

Le 23/07/13 21:12, Bartosz Dziewoński a écrit :

On a side note, I find it interesting how none of the actual VE and Parsoid developers replied here, apart from Roan, Chris and Subbu on off-topic technical issues (thanks for that).

I am myself not replying because I don't want to be involved. I will happily apply any change if there is a clear acknowledgement by all parties.

Meanwhile I am waiting for a consensus to form in one way or another one.