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