Page MenuHomePhabricator

On non-SET wikis (two edit tabs), links to new pages (red links) should open the user's preferred editor (last used)
Closed, ResolvedPublic

Description

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.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change 511016 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[operations/mediawiki-config@master] Simplify VisualEditor config variables (1/2)

https://gerrit.wikimedia.org/r/511016

Change 511029 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[operations/mediawiki-config@master] Simplify VisualEditor config variables (2/2)

https://gerrit.wikimedia.org/r/511029

Change 511315 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] Special-case redlink URLs to load preferred editor

https://gerrit.wikimedia.org/r/511315

Change 511016 merged by jenkins-bot:
[operations/mediawiki-config@master] Simplify VisualEditor config variables (1/2)

https://gerrit.wikimedia.org/r/511016

Mentioned in SAL (#wikimedia-operations) [2019-05-23T22:13:06Z] <jforrester@deploy1001> Synchronized wmf-config/InitialiseSettings.php: T223793 Add wmgVisualEditorIsSecondaryEditor to InitialiseSettings (duration: 00m 49s)

Change 511029 merged by jenkins-bot:
[operations/mediawiki-config@master] Simplify VisualEditor config variables (2/2)

https://gerrit.wikimedia.org/r/511029

Mentioned in SAL (#wikimedia-operations) [2019-05-23T22:17:51Z] <jforrester@deploy1001> Synchronized wmf-config/CommonSettings.php: T223793 Read wmgVisualEditorIsSecondaryEditor in CommonSettings (duration: 00m 48s)

Config simplification landed in production.

Mentioned in SAL (#wikimedia-operations) [2019-05-23T22:19:38Z] <jforrester@deploy1001> Synchronized wmf-config/InitialiseSettings.php: T223793 Drop wmgVisualEditorSingleEditTabSecondaryEditor and wmgVisualEditorSecondaryTabs from InitialiseSettings (duration: 00m 48s)

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

image.png (52×367 px, 5 KB)

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.

Change 512732 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[operations/mediawiki-config@master] Fix order of "Edit" tabs when multi-tab mode used on single-tab wiki

https://gerrit.wikimedia.org/r/512732

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.

@matmarex Added to https://meta.wikimedia.org/wiki/Tech/News/2019/23 with some restructuring to make the sentences simpler and shorter. Please take a look and make sure it still makes sense, and feel free to edit as necessary.

Change 512732 merged by jenkins-bot:
[operations/mediawiki-config@master] Fix order of "Edit" tabs when multi-tab mode used on single-tab wiki

https://gerrit.wikimedia.org/r/512732

Mentioned in SAL (#wikimedia-operations) [2019-05-28T22:49:49Z] <jforrester@deploy1001> Synchronized wmf-config/CommonSettings.php: SWAT Fix order of edit tabs for multi-tabs on SET wikis T223793 (duration: 00m 57s)

We can merge the code change now, too.

Change 511315 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Special-case redlink URLs to load preferred editor

https://gerrit.wikimedia.org/r/511315

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.

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.

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

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

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:
https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#Новое_поведение_красных_ссылок

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.

What do you think, @stjn and @jeblad ?

image.jpeg (394×1 px, 64 KB)
image.jpeg (568×1 px, 66 KB)
image.jpeg (556×1 px, 78 KB)

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.

I think you may want @ppelberg to see this, not me. TY!

The problem here is that new editors and not logged-in editors should have the visual editor for default, as the old editor is more difficult for them to understand.

@Theklan I don't want a long debate of VE-vs-Wikitext here, but in short the data and the general community both strongly disagree. File:2018-10_Wikimedia_editing_interface_retention.png data shows desktop& mobile interface-retention rates for VE are about half of the interface-retention rates for the wikitext editor. Foundation Research:VisualEditor's_effect_on_newly_registered_editors shows that VE utterly fails to provide the intended benefits for new users, and results in massively slower editing and lower rates of new users successfully making an edit. Global edit counts show the wikitext editor is overwhelmingly the primary editor, chosen as the best tool for the job by almost everyone. On wikis where VE is the default, new users rapidly abandon it and quickly shift to wikitext for a majority of edits. The Foundation attempted to roll out a VE-default for new users with SET deployment - two wikis (one being EnWiki) wrote hacks for the sitewide javascript to change the default and a third wiki unanimously demanded it be reversed. This effectively halted any further deployment of SET. It was clear that the community was not going to tolerate a Visual default, and management behind SET apparently lost interest in further SET deployment if it wasn't going to include a VE-default.

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.

JTannerWMF subscribed.

Please close out this task

marcella subscribed.

Assigning to @ppelberg for product manager response or resolution.

Aklapper removed a subscriber: marcella.

Removing task assignee due to inactivity as this open task has been assigned for more than two years. See the email sent to the task assignee on August 22nd, 2022.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome!
If this task has been resolved in the meantime, or should not be worked on ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!