Wikipedia:VisualEditor/Improvements

VisualEditor is probably the future. The ongoing default state RFC, while certainly run in good-faith, does not seem to be particularly constructive.

We need to focus on real, actionable improvements that can be made to the software to make it less annoying/painful/cumbersome/awful.

Section edit links

• Animation is hella annoying
• Figure out a way to kill the animation as soon as possible
  • "Compounded annoyance" is incredibly dangerous
• Relevant bug: bugzilla:50540

• Make section edits work; considerably improves the editing experience half a dozen different ways, especially by not requiring a full page load.

Easy opt-in/opt-out

• Special:Preferences is clunky and disruptive to editor workflow
• Provide a switch exposed in the standard view or edit modes that can completely disable or enable VisualEditor
  • Perhaps genericize this switch to include all "beta" features
  • Personal tools link?
  • Sidebar section?
• Relevant bug: bugzilla:52355

Advertise beta-ness

• Users felt mis-led by the lack of warning that VisualEditor is beta software
• Add an appropriate notice/message/warning to the interface
  • Hmmmm, there's already "? BETA" text at ?veaction=edit
    • Make this more prominent?
• Relevant bug: bugzilla:52366
  • • Non programmers do not necessarily know what Beta means in this context. Programmers would ordinarily expect something to be more tested and closer to being ready before it was released to casual users. Slow, unreliable, experimental version would be a much better warning if this is going to be up at all. Should it be improved the warning can be toned down accordingly.
      • Absolutely. This is a really good point that relates to the sub-point I'm about to add below.

Software is alpha, not beta

• As beta software makes plainly clear, beta software is intended when there's nearly a complete feature set. We don't have that here. We need to resume calling the software alpha until there's a much more complete feature set.

Needs to support more browsers

• Currently v/e only works on certain browsers and doesn't support a lot of older machines. In one sense that is good, people with older machines but up-to-date browsers are going to be getting the worst experience with V/E as it runs very slowly on old machines. But as a general principle, the WMF should henceforth aim to support its global editorship, not just those who can afford the latest machines.

Needs to give acceptable results on the kit that our editors use

• V/E was written on fast modern PCs and designed to take advantage of their processing power. That's good for the developers personal career development as it lets them hone their skills on new tech. But while a development house can work on the assumption that a lot of new software is bought to go with new PCs and if software is written for the fastest PCs around, the people who actually pay for software probably pay to keep their hardware up-to-date; The WMF is different, and needs to communicate that to developers. A brave move, and one that would actually solve this mess, would be to do an equipment swap - trade the PCs that the WMF has bought for its developers to write code on with the oldest PCs being used by volunteer editors in the third world and by unemployed editors in the first world. That would guarantee that future WMF code was written to work on older machines and would help bridge the gulf between the devs and the editors. It would also put some good machines into the hands of some of our contributors.

Needs to support more alphabets that just the 26 letters of standard English

There are many drawbacks to having the English Wikipedia as the test bed for new software, one is that we have a somewhat unadventurous alphabet. Recently I was talking to one of our Welsh language editors, and apparently they've been told to use copy and paste for some of their special characters. Obviously that needs fixing, but longer term we need to move away from testing new releases on our largest wiki - get things working on some smaller wikis first and then roll out to larger ones. There are plenty of small wikis that would volunteer for testing if that meant they got to show their problems to the developers, and it would do much to repair relations between the WMF and the community if software "enhancements" and tests other than security patches required community assent for implementation.

Consistency of user interface

It is a basic usability principle that the same control should consistently have the same effect, but:

• "Edit" sometimes gets you VE and sometimes the Wikitext editor.
• The button to start the "Save your changes" dialogue, and the one to finally save the page, are both labelled "Save page". Existing users are thoroughly used to the idea that "Save page" is what you click when you are finally sure that your edit is correct, and it should be kept for that; the first one should be something else, perhaps "Proceed" or "Apply your changes".

Autofill edit summary

I don't know whether it is Windows 7 or Firefox that does it, but with the Wikitext editor when you start to type an edit summary a context-sensitive list of possibilities, based on previous usage, is presented on which you have only to click. For repetitive tasks like restoring contested PRODs this is extremely helpful - I didn't realise how helpful until I found myself having to type the full edit summary each time in VE.