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