Mailing List Archive

Remove 'visualeditor-enable' from $wgHiddenPrefs
This isn't an appropriate list for this, but MaxSem and hashar told me to
post it here anyway, so here goes.

There's a patch[1] to remove 'visualeditor-enable' from $wgHiddenPrefs,
essentially allowing for disabling VE on a per-user basis again. It has
overwhelming community support, but the VisualEditor team is refusing to
acknowledge it, and ops say it's "none of their business".

Can something be done about it?

[1] https://gerrit.wikimedia.org/r/#/c/73565/


--
Matma Rex

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
On Mon, Jul 22, 2013 at 10:40 AM, Bartosz Dziewoński
<matma.rex@gmail.com> wrote:
> This isn't an appropriate list for this, but MaxSem and hashar told me to
> post it here anyway, so here goes.
>
> There's a patch[1] to remove 'visualeditor-enable' from $wgHiddenPrefs,
> essentially allowing for disabling VE on a per-user basis again. It has
> overwhelming community support, but the VisualEditor team is refusing to
> acknowledge it, and ops say it's "none of their business".
>
> Can something be done about it?
>
> [1] https://gerrit.wikimedia.org/r/#/c/73565/
>
>
> --
> Matma Rex
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I'm confused, did we really disable the option to opt out of visual
editor solely because that was easier than updating the description
for the preference?

--bawolff

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
I wasn't aware the preference was hidden. Interesting. This should
definitely be merged and deployed.

*-- *
*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 9:47 AM, bawolff <bawolff+wn@gmail.com> wrote:

> On Mon, Jul 22, 2013 at 10:40 AM, Bartosz Dziewoński
> <matma.rex@gmail.com> wrote:
> > This isn't an appropriate list for this, but MaxSem and hashar told me to
> > post it here anyway, so here goes.
> >
> > There's a patch[1] to remove 'visualeditor-enable' from $wgHiddenPrefs,
> > essentially allowing for disabling VE on a per-user basis again. It has
> > overwhelming community support, but the VisualEditor team is refusing to
> > acknowledge it, and ops say it's "none of their business".
> >
> > Can something be done about it?
> >
> > [1] https://gerrit.wikimedia.org/r/#/c/73565/
> >
> >
> > --
> > Matma Rex
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> I'm confused, did we really disable the option to opt out of visual
> editor solely because that was easier than updating the description
> for the preference?
>
> --bawolff
>
> _______________________________________________
> 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
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
The bug for that patch was just WONTFIXed, synchronizing information.

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

--
Matma Rex

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
And now it's REOPENED. I'd like some justification rather than the VE team
saying "it's our product, so we decide".

*-- *
*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: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>
>
>
> --
> Matma Rex
>
> ______________________________**_________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<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
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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>


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-2012-04-24.htmlwill 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)


--
(http://cscott.net)
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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.org>wrote:

> 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>
>
>
> 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-2012-04-24.htmlwillbe 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)
>
>
> --
> (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
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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_consensus_of_editors



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.org>wrote:
>
> > 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>
> >
> >
> > 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-2012-04-24.htmlwillbemet 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
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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

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

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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.org>wrote:
>
> > 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>
> >
> >
> > 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-2012-04-24.htmlwillbemet 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
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
I support merging and deploying <https://gerrit.wikimedia.org/r/73565> as
soon as possible. That said, there are still open questions in my mind.

C. Scott Ananian wrote:
>Erik Moeller wrote:
>>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 wonder what the cost of taking this paternalistic / "I didn't hear that"
approach is. As I see it, there are two major costs to be measured:

1. the usability and performance impact for users who are using older
equipment; and

2. the further erosion of community support and goodwill by attempting to
force this new feature down the throats of every editor.

I think everyone can acknowledge that VisualEditor involves _a lot_ of
client-side JavaScript and that there is measurable performance
degradation for users who have older equipment. From this, two questions
flow:

* Has this performance degradation been studied before deciding that users
must rely on their own home-grown hacks to disable VisualEditor?

* What was the rationale to require that users enable additional
client-side JavaScript in order to disable a larger heap of JavaScript?

Like many of the VisualEditor developers, I'm fortunate to be using a
newer machine with a modern Web browser so I can't actually test or answer
this question, but:

* If I were using an older version of Firefox or some other unsupported
browser: do I still receive all of the unneeded client-side JavaScript and
interface clutter from VisualEditor?

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

Regarding community support and goodwill, this is really in fact outside
the scope of this mailing list, but it probably serves as a good example
as any of a dangerous technocracy. It also particularly resonates with
volunteer projects such as Wikimedia wikis, of course.

As Tyler R. points out in this thread, for some users, they'll always want
to view the page source. A few more questions:

* Is there any modern Web software that includes a visual editor but
excludes a built-in option to disable it?

* How do you justify dramatically defying user expectations by forcing
users to put a home-grown user preference under the "Gadgets" tab rather
than under the "Editing" tab?

* How do you justify the wasted effort that will be required not only on
one wiki but on every wiki that will inevitably enable this same gadget
user preference for themselves?

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

MZMcBride



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
Minimal java-script load my ass, 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)

On Mon, Jul 22, 2013 at 2:36 PM, Erik Moeller <erik@wikimedia.org> wrote:

> 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
>
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> _______________________________________________
> 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
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
Le 22/07/13 15:40, Bartosz Dziewoński a écrit :
> This isn't an appropriate list for this, but MaxSem and hashar told me to
> post it here anyway, so here goes.
>
> There's a patch[1] to remove 'visualeditor-enable' from $wgHiddenPrefs,
> essentially allowing for disabling VE on a per-user basis again. It has
> overwhelming community support, but the VisualEditor team is refusing to
> acknowledge it, and ops say it's "none of their business".
>
> Can something be done about it?
>
> [1] https://gerrit.wikimedia.org/r/#/c/73565/

Thank you Bartosz :-)


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.

I do not have a specific opinion about it.


--
Antoine "hashar" Musso


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
On 23/07/13 04:36, Erik Moeller wrote:
> 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.

No, we're talking about whether the preference to hide all aspects of
VE should be in the "gadgets" tab or the "editing" tab.

We're also talking about whether that preference should be technically
consistent across all wikis, or whether it should be done in a
wiki-specific manner.

If the preference was consistent across all wikis, then we could
easily do statistics on its use. If, in a year or so, we feel that the
users who disabled VE should reconsider it, we could send them a
message or display a popup. It's also possible to do this with gadget
preferences, just more difficult.

Now that the gadget is in place and widely used, I can't really
believe that this is about encouraging the use of VE. To me, it looks
like a token gesture by WMF demonstrating support for VE, but without
any perceivable impact aside from angering VE's detractors. It's a
foot in the ground; a position taken. It's a message to the old guard
that their opinions will be ignored. As such, it's not surprising that
the old guard are upset.

If it was up to me, I would try to win them over with awesome
features, rather than prod them with a stick.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
On Mon, Jul 22, 2013 at 6:49 PM, 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?
>
> 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)
>
>
This.

I'm usually the first person in line to kill preferences, but I agree with
Brian and
Tim here and I think you're making a huge mistake here. This isn't a
preference
that changes absolutely anything, it just &disables* functionality. So
everyone is
aware of how much code is required to support this, I'll reproduce it below:

<<< VisualEditor.hooks.php
// User has the 'visualeditor-enable' preference set
$skin->getUser()->getOption(
'visualeditor-enable',
/*default=*/ false,
// HACK: Allows us to suppress the option in preferences when it's on
for all.
/*ignoreHidden=*/ true
) &&
[snip]
public static function onGetPreferences( $user, &$preferences ) {
$preferences['visualeditor-enable'] = array(
'type' => 'toggle',
'label-message' => 'visualeditor-preference-enable',
'section' => 'editing/beta'
);
return true;
}
VisualEditor.hooks.php;

That's it. There's nothing complex about this....the first part is included
in a
large if block that already checks for browser support and so forth, and
looks
pretty simple. The latter is boilerplate preference stuff.

Considering we've never made any plans to kill the source editor (or is that
all a farce as well?), then there's no other functionality that VE has to
take
care of. If a user doesn't want the preference, let them turn it off and
then VE
can go about its business.

Again, I'm usually the first to say "yes, kill the preference" but really
we've
got a dozen more screwed up preferences and this one is completely sane.
I'll also mention it seems to have overwhelming support from both the
community as well as some other developers.

-Chad
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
On Mon, Jul 22, 2013 at 9:35 PM, James Forrester
<jforrester@wikimedia.org>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 | tylerromeo@gmail.com
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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.org>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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
On 7/22/13, Ryan Lane <rlane32@gmail.com> wrote:
> 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.org>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
> Wikitech-l@lists.wikimedia.org
> 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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Remove 'visualeditor-enable' from $wgHiddenPrefs [ In reply to ]
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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 2 3 4  View All