Remove 'visualeditor-enable' from $wgHiddenPrefs

classic Classic list List threaded Threaded
101 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Yuvi Panda
On Tue, Jul 23, 2013 at 7:19 AM, Brian Wolff <[hidden email]> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Tyler Romeo
In reply to this post by James Forrester-4
On Mon, Jul 22, 2013 at 9:35 PM, James Forrester
<[hidden email]>wrote:
>
>  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.


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

Like others have said, this is not a choice between having a user
preference or not having it. It's a choice between having a consistently
functional user preference or pseudo-maintained gadgets doing the same
functionality. That adds even more bloat than another checkbox in the
Editing section (which, by the way, was just reorganized anyway).


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

Stop being so dramatic. This is clearly false.


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

This doesn't have anything to do with this discussion. It's already been
expressed that this will not be an under-used preference, and that numerous
members of the community want this feature.


> ​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.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Ryan Lane-2
On Mon, Jul 22, 2013 at 7:17 PM, Tyler Romeo <[hidden email]> wrote:

> On Mon, Jul 22, 2013 at 9:35 PM, James Forrester
> <[hidden email]>wrote:
> >
> >  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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Brian Wolff
On 7/22/13, Ryan Lane <[hidden email]> wrote:

> On Mon, Jul 22, 2013 at 7:17 PM, Tyler Romeo <[hidden email]> wrote:
>
>> On Mon, Jul 22, 2013 at 9:35 PM, James Forrester
>> <[hidden email]>wrote:
>> >
>> >  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
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Offtopic, but I think a good comparison could be made to the (former)
"external-editor" preferences. Anybody who actually used the external
editor feature did not use the preference. Many people accidentally
selected the preference and totally screwed everything up.

</utterly offtopic aside>

--bawolff

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Tyler Romeo
In reply to this post by Ryan Lane-2
On Mon, Jul 22, 2013 at 10:25 PM, Ryan Lane <[hidden email]> 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 | [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Brad Jorsch (Anomie)
In reply to this post by Ryan Lane-2
On Mon, Jul 22, 2013 at 10:25 PM, Ryan Lane <[hidden email]> wrote:
>
> 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.

I suppose the closest comparison to the Firefox situation would be if
the preference still functioned but was not shown on
Special:Preferences. Power users could still set the preference via
the API, which would be more or less the equivalent of using
about:config in Firefox.


--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Tim Starling-2
In reply to this post by James Forrester-4
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


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Steve Summit
In reply to this post by Tyler Romeo
Tyler Romeo wrote:

> On Mon, Jul 22, 2013 at 9:35 PM, James Forrester <[hidden email]>wrote:
>> 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?)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

MZMcBride-2
In reply to this post by James Forrester-4
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



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

David Cuenca Tudela
In reply to this post by Tim Starling-2
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 <[hidden email]>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_registered_editors/Results
> >
>
> [3] <https://office.wikimedia.org/wiki/VisualEditor_user_tests>
>
> -- Tim Starling
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



--
Etiamsi omnes, ego non
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Erik Moeller-4
In reply to this post by Tim Starling-2
On Mon, Jul 22, 2013 at 8:44 PM, Tim Starling <[hidden email]> 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_registered_editors/Results#Limitations
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_2011

> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Risker
In reply to this post by David Cuenca Tudela
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 <[hidden email]> 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 <[hidden email]
> >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_registered_editors/Results
> > >
> >
> > [3] <https://office.wikimedia.org/wiki/VisualEditor_user_tests>
> >
> > -- Tim Starling
> >
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> Etiamsi omnes, ego non
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Nicolas Vervelle-4
In reply to this post by Erik Moeller-4
I was glad to see some WMF members speak their mind against the current
stance from Erik and James.
But when I see Erik answer, I'm clearly understanding that WMF management
is simply being blind.
Erik, if I read correctly your reply :

   - You still don't have analysed the A/B test period : first evidence
   show that it has a negative feedback but you think further analysis could
   show otherwise. But, with first evidence pointing to negative feedback, you
   keep going on rolling out VE to as many people as possible without making
   sure before that this won't have more negative results.
   - "Performance is the single biggest issue for VE" : ouah... are you in
   denial ?

Nico


On Tue, Jul 23, 2013 at 7:23 AM, Erik Moeller <[hidden email]> wrote:

> On Mon, Jul 22, 2013 at 8:44 PM, Tim Starling <[hidden email]>
> 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_registered_editors/Results#Limitations
> 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_2011
>
> > 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
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Nicolas Vervelle-4
In reply to this post by Risker
Thanks Risker,

I think you've summarized the position of many experienced users.
100% agreed.

Nico


On Tue, Jul 23, 2013 at 8:14 AM, Risker <[hidden email]> wrote:

> 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 <[hidden email]> 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 <[hidden email]
> > >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_registered_editors/Results
> > > >
> > >
> > > [3] <https://office.wikimedia.org/wiki/VisualEditor_user_tests>
> > >
> > > -- Tim Starling
> > >
> > >
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > [hidden email]
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> >
> >
> >
> > --
> > Etiamsi omnes, ego non
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Subramanya Sastry
In reply to this post by Tim Starling-2
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=500&tagfilter=visualeditor
2.
http://en.wikipedia.org/w/index.php?title=Template:Contradict-inline&diff=prev&oldid=560522227
3. http://parsoid.wmflabs.org:8001/stats


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Erik Moeller-4
In reply to this post by James Forrester-4
On Mon, Jul 22, 2013 at 6:35 PM, James Forrester
<[hidden email]> 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

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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Risker
Erik, please stop and listen.  Almost without exception, people from all
areas of the Wikimedia community are calling on a re-evaluation here.  It's
lovely to have this vision of the Mediawiki future.  But until you get
VisualEditor right, you need to get your feet back on the ground.  People
were asking for a VE-like editing interface for years, and you're getting
close but you aren't there.  However, people haven't asked for different
ways to do categories (and in fact, different projects use categories in
different ways).  People weren't clamoring for many of the features in
notifications (and it took months to get it functioning at the level of the
features it replaced), and they've not asked for most of the features that
are being highlighted with Flow.

And none of it matters if you cannot provide a good enough VE platform to
make it attractive to experienced editors. Pull back on the investment in
these other projects until you have this one right.  For all the
disagreements there may be, I don't think anyone really wants to believe
that you'd rather 90% of experienced editors leave than have to change your
vision.

Risker


On 23 July 2013 02:35, Erik Moeller <[hidden email]> wrote:

> On Mon, Jul 22, 2013 at 6:35 PM, James Forrester
> <[hidden email]> 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
>
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Tim Starling-2
In reply to this post by Erik Moeller-4
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


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

K. Peachey-2
In reply to this post by Subramanya Sastry
On Tuesday, July 23, 2013, Subramanya Sastry wrote:
>
> 500+ edits are being done per hour using Visual Editor


500+ people are making edits with the default editor, I'm pretty sure
(without doing stats on it)  that a lot of them wouldn't be experienced
enough to kill it off


--
-- Sent from Gmail Mobile on my iPod.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Risker
In reply to this post by Subramanya Sastry
On 23 July 2013 02:32, Subramanya Sastry <[hidden email]> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123456