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 more useful. This page is about suggesting and / or discussing concrete proposals to improve VE features. Bug reports and other abstract comments should probably go to Wikipedia:VisualEditor/Feedback‎‎.

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.

Add a character inserter for those whose computer's inserter is insufficient

Tracked in Phabricator
Task T52296

VisualEditor supports full Unicode (though there are some language input-related issues which are still being worked on). However, it currently lacks a character inserter, leaving that task for the built-in tools in operating systems (e.g., on a Mac use ⌥ Option+e+a to produce á or ⌥ Option+i+a to produce â). Adding a character inserter would help these users.

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.

 Fixed, I'm pleased to see! It's now consistent, with "Edit source" and "Edit ^beta".

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

This is due to the edit summary box (it's not even labeled as such in the interface!) using a text area box rather than a text input box. See bugzilla:52133.

The edit summary box is, in fact, labeled in the interface: "Edit summary (Briefly describe the changes you have made)". And "Edit summary" is a wikilink. -- John Broughton (♫♫) 16:37, 7 August 2013 (UTC)