On non-SET wikis (two edit tabs), links to new pages (red links) should open the user's preferred editor (last used) – visual or wikitext. Currently they always open the wikitext editor.
|Open||Theklan||T223228 The Great Basque Redesign|
|Resolved||Esanders||T223705 Make visual editor the default editor for redlinks at euwiki|
|Open||None||T194128 Enable creation of new articles straight with Visual Editor in elwiki|
|Open||ppelberg||T223793 On non-SET wikis (two edit tabs), links to new pages (red links) should open the user's preferred editor (last used)|
- Mentioned In
- T223339: Re-run metrics from VE on mobile report
T225316: Clicking on "edit source" beside a section open the visual editor on the French Wiktionary (due to broken local gadget)
T223705: Make visual editor the default editor for redlinks at euwiki
T194128: Enable creation of new articles straight with Visual Editor in elwiki
T152593: Redlinks should open the respective editor that's set in the user or global settings
T54162: VisualEditor: If VisualEditor is the primary editor, type=create and type=fulltext buttons should point to VE, not WT editor
- Mentioned Here
- T114530: Change VE integration to only use one edit tab
T212848: Make edit notices more visible in Visual Editor
T55441: VisualEditor: Where VisualEditor is the primary editor, redlinks in read mode should open VE (not wikitext editor)
We should announce this, the change has been requested several times by folks from various wikis. (Also, in case it has unintended consequences – which I hope it doesn't, but the initialization code is complicated due to how many options there are – an early notice would make problems easier to resolve.)
Proposed Tech News text:
On wikis that have separate tabs for visual and wikitext editor, clicking a link to create a new page (red link) will now correctly open your previously used editor, rather than always the wikitext editor.
I guess we're too late for Tech/News/2019/22 (to be sent 27 May), so this would go in Tech/News/2019/23 (3 June). We should make sure the code also goes out in the week of 3 June, so we should merge https://gerrit.wikimedia.org/r/511315 after next branch cut (no sooner than 29 May).
@Whatamidoing-WMF noticed that the config simplification had a minor unintended consequence: on single-edit-tab wikis, where visual editor is secondary (for new users, clicking the [Edit] tab opens wikitext), if you picked "Show me both editor tabs" in preferences, the order of the tabs changed from [Edit] [Edit source] to [Edit source] [Edit].
I think this behavior would have made sense if it worked this way from the start, but now it’s a surprising change, and I'm going to undo it. This problem affects two wikis, enwiki and frwiktionary. So far no users seem to have reported the problem (checking Wikipedia:Village pump (technical) and Wiktionnaire:Questions techniques), so hopefully it wasn't a big inconvenience.
Turns out today is a WMF holiday, so the soonest opportunity to deploy the fix is tomorrow evening: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20190528T2300. I think it can wait for another day, given the lack of complaints.
For those that use all three editors, both VisualEditor and WikitextEditor2017 is unusable for template editing, this is a awkward change as it has now become pretty much random which editor is used. The reason it is pretty much random which editor opens is because it is pretty much random which editor the user last used. It seems like some devs thinks the choice is static, but it is not, users change back and forth all the time.
It isn't often I complain about changes, but in this case I really would like this change to be removed, or fixed so users somehow can expect how the system works. As it is now the user must know what he used last time he edited, which is confusing at best. (And yes, we already have complaints at nowiki.)
So please make a better solution, ASAP!
It seems like some devs thinks the choice is static, but it is not, users change back and forth all the time.
We switch back and forth just as much as any other users, that's why we go to great lengths to preserve changes when switching.
For users that use both editors we can't know which editor they want to use when they click a red link, so our best guess is the editor they last used. It appears that you always want to use the wikitext editor when opening red links, but there will also be users who always want to use the visual editor when opening red links. In this case the best solution is to make a best guess and provide an easy tool to change mode if that guess is incorrect.
This seems like a minor inconvenience for experienced users who often switch between editors (and therefore will know how to switch back to the editor they want), compared the situation before where newer users who had only ever used the visual editor were being shown the wikitext editor, and not even knowing how to get back to VE.
That said I appreciate you may have a use case where it would be convenient to explicitly specify a preferred editor for red links, in which case you could file a follow-up task to create a preference for that.
Without going into specifics; some users will nearly always open a red-linked article in plain old wikitext editor because the initial editing consists mostly of non-content-text, it is mostly markup. Not sure what you would call “brødtekst” in English. For those users it is a major inconvenience to use the visual UI and try to navigate a pointer-based interface.
This change has one glaring problem. Most projects have edit notices for people trying to create new pages. This text displays fine in standard wikitext editor, but in any visual editor (we should have a better name for them) it gets shoved away into a small box which usually ends up not fitting the screen. Moreover, an average editor will probably close these notices since they are shown to them once in a tertiary position that gets in the way of editing.
I’ve already said that VisualEditor should change its treatment of edit notices in T212848, but it is an even more important concern for new page creation flow. As I’ve tested on ru.wikipedia.beta.wmflabs.org, VisualEditor gets open by default for most editors, so with this change we will be essentially retiring the standard edit notice without asking anyone.
There are new complaints about this change at nowiki, w:no:Wikipedia:Torget#Merkelig når en skal opprette artikkel. Previous complaint at w:no:Wikipedia:Torget/Arkiv/2019/juni#Visual editor når man oppretter artikler.
I'd counter that existing edit notices are useless on mobile devices, so the problem is the design of the current edit notices which assume desktop screen sizes...
P.S. similar problems used to exist with amboxes etc. For that an api was wrapped around some logic that knows that amboxes often have a 'short' version (for when grouped inside certain other amboxes). I'd argue that something similar needs to happen for edit notices. A separation of data and presentation, and variety in length of description depending on wether you see the 'smaller' version or the bigger version. But someone will need to put in the effort to drive those changes on the wiki's
While I think that this is a problem, the visual editor differs in appearance on mobile and desktop quite a bit, so mobile needs are not a big argument for doing the worse thing on desktop.
This is pretty anecdotal, since we can’t even hear from our readers on this, but one editor in Russian Wikipedia literally complained about this change because they didn’t notice the small modal where all the information is being hidden:
But seeing no activity here, I guess this change becomes permanent and full effects of it on non-English communities wouldn’t be known for ages.
Edit: There’s also the fact that any new editor has to get through not one, but two modals in the current way, since there’s also the annoying ‘Welcome to Wikipedia!’ popup that everyone probably clicks through.
For those who are having issues with being given the most-recent editor for redlinks, could we adapt the existing SET preference setting? (English settings pictured below.)
The current option “Show me both editor tabs” could be split into “Show me both tabs – prefer visual editor” and “Show me both tabs – prefer source editor”. This avoids having a separate 3-way selection
just for new pages.
I'm assuming for the non-SET wikis you could surface just a subset of the five options: remember last, always visual for new pages, always source for new pages (with appropriate wording of course). The other two options don't make sense if two edit tabs are always showing for everybody.
I'm not a huge fan of remember last (which is why I choose two tabs on en.wp), but I do see it as a reasonable approach for logged-out users and for those who don't want to dive into tweaking their preference settings.
After reading discussions on some other tasks, it's not just redlinks but a variety of things that have action=edit. And it seems some others have found the remember-last-used behaviour problematic in general: e.g. T114530 @Elitre, @Alsee
My proposal above could help people on SET wikis also.
Back to the main issue, "load last used" is an awful default. We need to get rid of it, not expand it to new places. While "last used" may work for anyone who only uses one editor, for anyone who ever switches editors it is functionally equivalent to a user interface that that calls Random(). It is an extremely bad user experience for the interface to behave in a chaotic, unexpected, or unpredictable fashion. Last-used was a harmful "compromise" in the struggle between the the Foundation and the community over which editor is primary. We really need to find a way to end that struggle. We really need to work from a single actual-default. People who prefer the other editor can just set a preference for the opposite default.
It has been posted a new complaint at nowiki over this change, w:no:Torget#Hvorfor veksler det mellom VE og rediger kilde-modus når jeg skal opprette nye artikler? (Why does it swap bewtween VE and editing source mode when I'm creating new articles?).
I'm considering starting a vote over requesting rollback of this issue at nowiki, but I strongly hope to avoid that.