Description

Add button to the WikiEditor and VisualEditor toolbars for switching back and forth mid-edit – T49779, blocked by T104663

Change the VE-MW integration to not add a new tab, make it look like the "Edit" tab is active; on page load, re-write the URL of the "edit" button to go to VE or WE based on users' last choice (site default applies if no pref, or for anons, no cookie) – T114530

The last two comments have identified two specific problems with having two tabs, not one:

Users who accidentally click the wrong tab

Potential users who aren't sure which edit tab to pick, and therefore might decide to not edit at all

The underlying problem here, I think, is that the two tabs are almost the same. Same font, same coloring, and very similar wording ("Edit" versus "Edit source"). Plus "Edit source" isn't clearly understandable to other than those who do programming ("source code").

Suppose the two tabs were clearly different (font, coloring, whatever), and they read "VisualEditor" and "Wikitext editor". (For example, "Wikitext editor" could be on two lines, and in a smaller font.) Then the chances of clicking on the wrong tab are essentially nil.

One obvious objection: these captions would make it more difficult for people to realize that they an edit Wikipedia. But, in fact, surveys have repeatedly found that the vast majority of readers don't realize that they can edit Wikipedia, despite the "Edit" tab, and for those who do, the vast majority are afraid to do so. Given that, different labeling on the tabs might well be intriguing enough to get more people to click on an editing tab, rather than fewer people.

As far as cognitive burden goes, I'd argue that when the choice is clear - there are two different interfaces - the burden is minimal. What's more important is to minimize the penalty for clicking on a tab, and realizing that it doesn't lead to somewhere you want to be. That's why it's important for pages to load quickly, for editing, and why having a clearly visible "Cancel" option is a good thing. With minimal penalty for clicking in the "wrong" place, possible editors and novice editors aren't going to have a negative impression of Wikipedia's options.

The more I read and the more I think about it, the more it seems that a single edit tab for two editors is just a bad idea. Two editors = two tabs is simple. All the options for merging them are a mess.

In particular I have to agree with He7d3r. I have substantial experience with Flow, "whatever-I-used-last-time" is AWFUL. You don't even need to bother saving the last-used mode for Flow.... you can simplify the code and just call random() mode each time. I wouldn't notice any difference. I constantly have to clean up the mess when it gives me a random mode and craps up my post with with nowikis.

I guess I see why this change would be beneficial (especially to new users), but couldn't there be an option to switch it off somewhere?

I know all about how more preferences introduce more permutations for devs to test as well as a performance hit, so perhaps I'm being selfish here. On the other hand, coding up a gadget to get my two tabs back would be a massive UX pain (because gadgets take a little time to load, so there would be a small delay before the two tabs popped up).

Edit: Apparently this preference (or something like it) is planned, so I don't object to anything here anymore.

I guess I see why this change would be beneficial (especially to new users), but couldn't there be an option to switch it off somewhere?

Of course, this is part of the system. There's an awful lot of speculation in this thread where people haven't looked at the code (because it doesn't exist yet) and are deciding that instead of asking questions, they will make up a boogeyman and then oppose it.

Given how much this feature has been requested by existing community members over the past few years, I'm disheartened that some have chosen to ignore those requests and make claims about it.

I'm going to repeat most of an earlier comment, because I think it gets to the heart of the issue, and because no one has responded to it:

Two specific problems have been identified as being caused by having two edit tabs, not one:

Users who accidentally click the wrong tab

Potential users who aren't sure which edit tab to pick, and therefore might decide to not edit at all

The underlying cause of the first problem - the one that existing community members have complained about over the past few years - is that the two tabs are almost the same. Same font, same coloring, and very similar wording ("Edit" versus "Edit source"). Plus "Edit source" isn't clearly understandable to other than those who do programming ("source code").

There is another "solution" besides a single tab: make the two tabs were clearly different : font, coloring, whatever. And change the text so that one says "VisualEditor" and the other says "Wikitext editor". (For example, "Wikitext editor" could be on two lines, and in a smaller font.) Then the chances of clicking on the wrong tab are essentially nil.

As for whether brand new editors would be better off with one tab or two, I can assert that they would not, and proponents of a single tab can assert that they would, but the only real evidence would be from A/B testing. Until (if ever) that takes place, why not make a modest investment of time in changing the two tabs so that they are clearly different, to reduce or eliminate the confusion that is causing editors to complain?

I'm going to repeat most of an earlier comment, because I think it gets to the heart of the issue, and because no one has responded to it:

Two specific problems have been identified as being caused by having two edit tabs, not one:

Users who accidentally click the wrong tab

Potential users who aren't sure which edit tab to pick, and therefore might decide to not edit at all

The underlying cause of the first problem - the one that existing community members have complained about over the past few years - is that the two tabs are almost the same. Same font, same coloring, and very similar wording ("Edit" versus "Edit source"). Plus "Edit source" isn't clearly understandable to other than those who do programming ("source code").

No. This is profoundly and totally mis-understanding the problem. The problem is not "you can't distinguish the two editors even though they're different", it's "the two editors are different even though they don't need to be".

The objections, quite rightly, are mostly that there is no reason to add yet another control into the already-bloated interface that MediaWiki provides (two edit tabs when editing is a single action). It is grossly disrespectful to readers' and editors' time to add more controls to the interface, and though we felt we had to do it at first, this was always part of the plan since at least 2012.

A secondary point is that we as a community have spent 15 years explaining to people that they need to click 'edit'; having two such things is confusing and undermines the excellent out-reach work people have been doing.

The "people click the wrong tab" (but know the difference between them) idea is not a significant driver of change, because though mildly irritating it isn't a big issue. However, "people click the tab that's wrong for them" (because they don't understand the difference) is an issue.

Also, all these comments about design, how it should work etc. should be on the task about that, T114530. This is just the overall switch-over task.

Jdforrester-WMF renamed this task from Provide a single edit tab which has both visual and wikitext modes and allows on-the-fly switching between them to Migrate wikis to use a single edit tab which has both visual and wikitext modes and allows on-the-fly switching between them.Nov 9 2015, 7:14 PM

I think a single tab would be better than two, but I also think a preference here would be useful.

When editing a page:

Remember last editor I used [the default]

Always prefer visual editor

Always prefer wikitext editor

Always ask me

Yes, that's what is planned, except "ask me" will be "retain having two edit tabs".

I can think of one other way that 'Always ask me' could be implemented that would also allow users to pick between 'retain having two edit tabs' option and the previously proposed 'Display a menu' option that has, as of now, been rejected, while also integrating the 'Remember last editor I used' option. It would have the following options:

'When editing a page' group of radio buttons:

'Always prefer VisualEditor'

'Always prefer wikitext editor'

'Allow access to both editors via…:' (drop-down menu:)

'…separate tabs.'

'…a drop-down menu.'

Checkbox for the 'Remember last editor I used' option (grouped with the drop-down menu's second option somehow since it only makes sense with that.)

The first two options could also be combined into an 'Always prefer…' drop-down menu with options for VisualEditor and the normal wikitext editor if desired. The 'Remember last editor I used' checkbox would either turn the drop-down menu into a combo button of some sort, and I can think of a couple different designs for that:

Have the button say something like 'Edit…' and have a drop-down menu indicator caret next to it that expands into a menu containing options for '…with the wikitext editor' and '…with VisualEditor,' the most recently used of which, if remembered, would be indicated with some sort of highlight, icon, or text string (perhaps 'Most recently used editor' or 'You used this editor last time?') Clicking the button would punt you to the editor you last used, and clicking the drop-down arrow would allow to decide whether or not you wanted to override that.

Make checking the 'Remember last editor I used' checkbox could move the 'Edit…' label off of the combo button and to the left of it, changing it to say something like 'Edit with:,' allowing the combo button itself to display your most recently used editor and making clicking on that combo button's drop-down arrow overlay the button with a menu containing options for both editors.

Another possible design could be a sub-paned list of available editors, each of which could be enabled or disabled at will, with a radio button next to each option in a 'Default editor' column. Not choosing any editor as a default (that is, deselecting the currently selected 'Default editor' radio button, thereby leaving them all blank) would requiring a user to use either different tabs or a drop-down menu, as specified in a drop-down menu below the sub-pane, to select the editor they want to use each time they want to edit a page, though I don't see that option being used much. The 'Remember last editor I used' checkbox could then also move under the sub-pane, perhaps only being enabled when users don't select a default editor.
Regardless of whatever design eventually comes into use, explaining to users that an editor can't be used in a namespace should be relatively simple: the relevant tab or menu item could be dimmed, and a tooltip and/or a message upon entering edit mode explaining why the editor they expected can't be used in the namespace in which they are currently located (this latter option would probably be more useful for users who either have a default editor or use the editor they last used, especially if access in this manner were made more prominent.) Also, I agree any changes made to editor access should not interfere with current gadgets (wikEd, in particular, comes to mind, since it replaces the wikitext editor with a more sophisticated one.) Anyway, those are my thoughts concerning possible designs for a new editor-picking interface.

For wikis where VE isn't the default choice, on an IP's edit-click, set a cookie of a random number, and allow direction to WE or VE based on some threshold (so ramped-up change is possible) – X
For such wikis, slowly increase the switchover with testing to ensure it's not disruptive – X.

Jdforrester-WMF, could you please clarify? It's very possible I'm misreading this, but it sounds like you just declared an unconditional force over of all wikis to a VE-default as part of the single-edit-tab project.

For wikis where VE isn't the default choice, on an IP's edit-click, set a cookie of a random number, and allow direction to WE or VE based on some threshold (so ramped-up change is possible) – X
For such wikis, slowly increase the switchover with testing to ensure it's not disruptive – X.

Jdforrester-WMF, could you please clarify? It's very possible I'm misreading this, but it sounds like you just declared an unconditional force over of all wikis to a VE-default as part of the single-edit-tab project.

Yes, you're mis-reading. This is how we would do the much-asked-for A/B test for anonymous users about which editor we prompt them with, which has been requested from (amongst other wikis) the English Wikipedia for several years now. Obviously we're not going to just do it without talking to the wikis first. :-)

I have a question concerning the user preferences. If I choose to use the old wikitext editor as my personal default editor, do I need to switch from VE to WT manually and individually on every wiki and every device I use or will there be an easy way to make this decision with global effect? This is quite important to me, because as a globally active user I edit several hundred different wikis and my slow internet connection does not appreciate VisualEditor at all.

Visual Editor is not a good editing UI. It's highly confusing, hard to navigate, extremely heavyweight and is full of bugs. None of the Russian editing gadgets work with it, and those gadgets are essential for productivity. I therefore strongly oppose merging the tabs for the old-style editor and VE, as the latter is clearly not yet ready for production.

I have a question concerning the user preferences. If I choose to use the old wikitext editor as my personal default editor, do I need to switch from VE to WT manually and individually on every wiki and every device I use or will there be an easy way to make this decision with global effect? This is quite important to me, because as a globally active user I edit several hundred different wikis and my slow internet connection does not appreciate VisualEditor at all.

Hey @Vogone. Unfortunately, because every wiki is configured individually per community request, we can't have a single setting that applies to all wikis. In your case I'd recommend using a script to mass-set your preferences the way you like them.

@Jdforrester-WMF
I earlier asked if the WMF was going to try to push a VE-default as part of the single-edit-tab deployment. You said you wouldn't do that without talking to the wikis first.

I am rather dismayed to see that VE was defined as the "primary" editor on Polish wiki, with apparently zero community discussion. I am even more dismayed to hear that the WMF has apparently defined "VE-primary" for ALL wikis except EnWiki.

I went to Polish Wiki to see how single-edit-tab works. I created a new account, I clicked edit. My browser froze up waiting for VE to load, because the default VE-primary editor is made to load first. After VE eventually finishes loading, a new user is then given a menu which directs them into the VE-default if they click to "continue" editing. In order to get the wikitext editor they have to click a confusing "Switch" to trigger a load of the "secondary" editor. Then it gets even worse. I closed the tab without making any selection. When I opened a new tab and clicked edit, I was shoved directly into VE-default.

Is it the WMF position that VE will be slipped in as default editor as part of single-edit-tab deployment, without discussion, for all wikis except EnWiki?

I could be mistaken, but I suspect most wikis consider the wikitext editor to be the primary editor.

At first I hoped that it would have been possible to stick with the 'double edit tab', or at least that the 'single edit tab' would have made easier to get rid of VisualEditor, but I actually had a very similar experience to @Alsee's. Forcing users into trying an editor at the cost of disrupting the flow, no matter how good the editor may be, is harmful.

@Ricordisamoa, based on the information we have, very few editors are choosing to have two tabs. For example, here are the numbers from the Polish Wikipedia, after they had been in Single Edit Tab mode for about two weeks. There are 4,000 active editors there each month (at least one edit).

Only 300 of them chose to have two tabs.

About 800 had chosen to have one tab that always opens their favorite editing environment (usually the wikitext editor).

Everyone else (an unknowable number, but probably on the order of 2,000 logged-in editors) stayed with the default (one tab that leads to whatever editor you opened last – which is the wikitext editor for more than half of highly experienced editors).

This is a "round numbers" estimate, but the dual-tab system, despite being my own personal preference, seems to be chosen by only about 10% of editors there.

I would be interested in hearing from any communities that expect to see significantly more editors choosing the dual-tab system. (I asked people at the English Wikipdia to tell me what preference they expected to choose, but nobody answered that part of my question.)

Polish Wikipedia, anonymous user, cookies & storage disabled, any article, click Edytuj. VisualEditor seems to be loading, but the progress bar stops at the end. I cannot edit any part of the page. And because VE hijacks URLs, I can't even get to the wikitext editor by appending "?action=edit" to the address. I must disable JavaScript to edit. That is INTOLERABLE (bold, all caps).

Whenever the system is unable to set temporary preferences, it should display both tabs or at least give users the ability to choose the editor every time. And that must happen without having the whole VisualEditor load first.

i really do not understand why you guys keep fighting for having visual editor as only option for years. just show both tabs, and let the users switch off one of them in the rare case a user really has a strong preference.