Page MenuHomePhabricator

Give mobile editor a way to edit more than just a single section at once
Closed, ResolvedPublic

Description

MobileFrontend + MinervaNeue only expose section-editing. This is (presumably) for general performance reasons, making it easier for someone on a mobile device / cell data to edit just a small part of a huge article.

However, some editing tasks need / are-made-easier-by access to the full text of the page. We should give editors a way to access the full text.

Up for debate: make this easily-accessible to all editors, or stick with the current state of only exposing section-editing through the UI? (It's legitimately confusing that the edit-button at the top of the page next to the other page-level actions currently only opens the editor to the introduction section of the article, for instance.)

Event Timeline

DLynch created this task.Jun 11 2018, 3:48 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 11 2018, 3:48 PM

On the talk page overlay we add a link at the bottom of the overlay for access to the talk page itself ("Read as wiki page"). Maybe something similar would work here?

MobileFrontend + MinervaNeue only expose section-editing. This is (presumably) for general performance reasons, making it easier for someone on a mobile device / cell data to edit just a small part of a huge article.

It's actually for a variety of reasons

  • usability. It's easier to edit a smaller corpus of text.
  • technical reasons with the API (I seem to remember JS preview was very slow/impossible in the editor - that may be different now VE is more mature)
  • consistency - sections are first class citizens in MinervaNeue (e.g. section collapsing).

Change 439621 had a related patch set uploaded (by DLynch; owner: DLynch):
[mediawiki/skins/MinervaNeue@master] Allow editor access to the full page's wikitext

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

That patch makes it so that visiting a ?action=edit URL will load the full page's text in the overlay editor. Sort of a preserve-the-status-quo patch.

Change 439968 had a related patch set uploaded (by DLynch; owner: DLynch):
[mediawiki/skins/MinervaNeue@master] Suppress display of wikitext editor on action=edit

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

This patch needs a product decision before I can merge it.

DLynch added a subscriber: Deskana.Jun 14 2018, 3:34 PM

From @Deskana I guess? (It's mobile, but it's also editing, so...)

I want to make sure I'm understanding this fully first.

The premise of this task is that some editors find it useful to be able to edit the entire wikitext of the article using the mobile view or MinervaNeue skin. This functionality is presently not exposed in the mobile view or MinervaNeue skin: the edit pencil at the top of the page loads the first section, and any other section edit pencils only load that section. This raises more questions than it answers for me. Who are these people? How often do they do this? What is it that they're trying to do?

Anyway, the above patch proposes to resolve this issue by allowing editors to append ?action=edit to their URLs to be able to edit the whole page, e.g. I'm on the page https://en.m.wikipedia.org/wiki/Maksym_Salamakha, I add ?action=edit to the URL, and navigate to https://en.m.wikipedia.org/wiki/Maksym_Salamakha?action=edit, and see the whole wikitext. This functionality isn't exposed anywhere in the interface. The editor in question has to know the magic password. As an iteration, that sounds fine to me: having that functionality is better than not having it. That said, I'm not sure it really achieves much, since nobody will really know the magic password, and doing it on mobile devices will be a bit of a pain.

If all the above is correct, and you're asking me for a yes or no on the change, my answer is yes. :-)

@Deskana: That all sounds correct.

As an added point, it's also functionality that did exist already, in the form of ?action=edit links loading the wikitext editor on the page. (Generally seen by users who either knew how to do it manually, or who were switching from desktop to mobile via the relevant links / adding "m." to the URL.) I earlier made it harder to use, when I had the mobile editor notice these action=edit links and trigger its overlay for them, so this patch makes the experience consistent again.

That said, I'm not sure it really achieves much, since nobody will really know the magic password, and doing it on mobile devices will be a bit of a pain.

Yeh the magic password bit doesn't help this problem. mobileeditorsuppress is not exactly easy to remember and is also hard to type on mobile. I personally don't think this gains much unless it's linked to in the interface.

Who are these people? How often do they do this? What is it that they're trying to do?

As someone who uses the fallback wikitext editor quite often, I can say it's sometimes useful to be able to edit the entire article under some circumstances and it's useful to have the option to switch between that and the JS editor (just as it's useful to sometimes edit in VE and sometimes in wikitext). One example that comes to mind is rearranging or correcting broken section markup (I do this often on Wikivoyage). This was the workaround for those who needed to do that, by editing the URI. With this recent change the workaround is now to switch to desktop which is a much worse experience for people like me who struggle with Vector on mobile. I can give more concrete examples as I encounter them. I'm guessing @Ignazio and @Daimoana have similar needs so would be nice to hear from them.

I'd like to see a better solution for that use case then the currently proposed one - preferably a way inside the editor to jump from the editor to full page mode in a similar way to the talk overlay, but action=edit was nice as it was discoverable by editors and didn't confuse non-editors as it wasn't prominent in the UI.

I should note, previously it was also possible to right click on an edit icon to open the non-JS editor. It's not possibly any more either.

To flip the question, what is the motivation for auto redirecting 'action=edit' to the editor? What is gained?

Regardless of what we do it sounds like we need to document why we do this in the code.

Yeh the magic password bit doesn't help this problem. mobileeditorsuppress is not exactly easy to remember and is also hard to type on mobile. I personally don't think this gains much unless it's linked to in the interface.

Do you actually need the HTML-form editor instead of the mobile editor overlay? That's all the mobileeditorsuppress parameter would get you here that either visiting an action=edit URL or changing the #/editor/0 to #/editor/all in the URL wouldn't.

I don't think the HTML form editor is necessary (at least for my use case) but maybe useful on a slow connection. If #/editor/all worked and (importantly) was accessible from the editor overlay that would satisfy my use case.

For what it's worth, I'm thinking of this ticket as a two-part thing. Part one is the existing patches which will restore the ?action=edit behavior of getting the full text, and part two would be working out the right place to put the UI to expose it more thoroughly. (I'd argue that the edit button at the top of a mobile page next to all the other page-level actions should trigger /all, but there's probably an argument to be had here...)

Jdlrobson added a comment.EditedJun 14 2018, 5:01 PM

Sounds like a plan. Benefit of lead section editing is that if you want to edit the bottom of the section it's very easy to find. Most of the time (only in my experience) full page editing is not useful on mobile.

@Jdlrobson I just reported what Ignazio pointed out at village pump :-) From my POV I have to say that I never ever use mobile version, and this is valid for every site. So actually I don't have ane specific need, although I guess being able to edit the full page would be helpful in many circumstances, and I also find kinda mandatory a button to access it. Unfortunately, right now I cannot give any other info :-)

Change 439621 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Allow editor access to the full page's wikitext

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

Jdlrobson added a comment.EditedJun 14 2018, 11:02 PM

Remember Minerva is also a desktop skin (to dogfood I use this skin on desktop)

I just discovered today, this has also broken the desktop editing experience.

If you click the edit icon on desktop before VisualEditor has fully loaded (which can take a long time on even a fastish connection you get a broken workflow)
https://en.wikipedia.org/wiki/Barack_Obama?action=edit&useskin=minerva

On desktop, editing the entire page should be the norm. It used to be...!

DLynch added a comment.EditedJun 15 2018, 4:36 AM

@Jdlrobson The merged patches should mean that the case you show there will result in the full article appearing in the editor. You can see it on beta: https://simple.wikipedia.beta.wmflabs.org/wiki/Barack_Obama?useskin=minerva&action=edit

...not that VisualEditor and Minerva-on-desktop play together terribly nicely in this case, in general. I cannot claim that we do well at regularly testing it in non-Vector situations.

...not that VisualEditor and Minerva-on-desktop play together terribly nicely in this case, i

It was definitely usable before. I've been using them and my only pain point so far has been the toolbar placement.

The merged patches should mean that the case you show there will result in the full article appearing in the editor.

The overlay shouldn't be loading on desktop though. Overlays only really make sense on a mobile/tablet device. VE used to work with their workflow, but now doesn't as switching from the editor claims its not supported. I have to manually put in https://simple.wikipedia.beta.wmflabs.org/wiki/Barack_Obama?useskin=minerva&veaction=edit but even then the editor loads on top of it.

The following workflows are now broken:

Reading the original bug report in T185729, it seems you don't want to target action=edit in the Minerva JavaScript .. only action=veedit.. and only on the mobile domain. Can I ask that we revert this patch and try again to solve T185729 given all this new information? IMO that change has done more harm than good. :/

The overlay shouldn't be loading on desktop though. Overlays only really make sense on a mobile/tablet device.

It does, though. This is independent of this whole patch-set. Click any edit button on a desktop-Minerva page that's not the initial section edit button, and it loads the overlay to edit that section.

Only reason it's not loading the overlay from the initial button, at that, is because there's what looks like a bug. It can't find the initial section because it's checking for a MobileFormatter-specific bit of markup, while other section-detection code isn't, so the code hits an edge case when trying to decide how to override the initial edit button -- it knows there are multiple sections, but it can't find the initial section, and there's no case to handle that apparently-impossible state.

Note that the initial button which loads the ?action=edit page still has the tooltip "edit the lead section of this page".

I'd be happy to entertain a "Minerva shouldn't use overlays on desktop" argument, but that's not the actual current state of affairs, and there's a lot of refactoring of Minerva that would need to happen to make it more aware of whether it's on mobile and stop registration of overlay routes in that case. (It'd be fairly simple to just stop it hooking those other section edit links, though.)

https://simple.wikipedia.beta.wmflabs.org/w/index.php?useskin=minerva&title=Barack_Obama&venoscript=1#/editor/all provides an odd workflow - I see the editor and then the editor loads.

That's what the not-yet-merged patch (https://gerrit.wikimedia.org/r/439968) will fix. It'll make it behave the same as visiting a veaction=edit page on desktop -- a placeholder "editor is loading page".

https://simple.wikipedia.beta.wmflabs.org/wiki/Barack_Obama?useskin=minerva&veaction=edit (loads VE in background and then wikitext editor on top)

This I'll need to look at, because you're right, it's weird.

It does, though. This is independent of this whole patch-set. Click any edit button on a desktop-Minerva page that's not the initial section edit button, and it loads the overlay to edit that section.

Sure but that's something we want to get away from and up till now has only been because we haven't been able to give it attention. That aside, the editor was behaving correctly when working on a desktop skin until this change. My hope is that we can look at the user's viewport to determine whether to show an overlay or something else. The editor is the only one that has a something else up until this point.

Only reason it's not loading the overlay from the initial button, at that, is because there's what looks like a bug. It can't find the initial section because it's checking for a MobileFormatter-specific bit of markup, while other section-detection code isn't, so the code hits an edge case when trying to decide how to override the initial edit button

It's a feature. This is how we determine if Minerva is operating in desktop or mobile mode for the time being, since desktop doesn't make sections first class. I wrote that code purposely to not open the editor.

Note that the initial button which loads the ?action=edit page still has the tooltip "edit the lead section of this page".

That's definitely an oversight, but obviously easy to fix.

there's a lot of refactoring of Minerva that would need to happen to make it more aware of whether it's on mobile and stop registration of overlay routes in that case

We're giving attention to this this year :). One of the goals is Minerva being separated from MobileFrontend which will make it a desktop skin (see https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFrontend_%26_MinervaNeue_frontend_architecture) so this is why I'm being so fussy. Happy to chat through hopes/plans around that on a hangout if that will be helpful. If action=edit redirects to the mobile editor that's fine, but I don't think it should be doing that on desktop when the editing experiences are more powerful then the overlay equivalent (on MediaWiki.org for instance there is wikitext syntax highlighting).

Change 439968 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Suppress display of wikitext editor on action=edit

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

Change 441569 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/skins/MinervaNeue@master] Revert "Suppress display of wikitext editor on action=edit"

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

Change 441569 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Revert "Suppress display of wikitext editor on action=edit"

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

Vvjjkkii renamed this task from Give mobile editor a way to edit more than just a single section at once to g9aaaaaaaa.Jul 1 2018, 1:05 AM
Vvjjkkii removed DLynch as the assignee of this task.
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed subscribers: gerritbot, Aklapper.
Daimona renamed this task from g9aaaaaaaa to Give mobile editor a way to edit more than just a single section at once.Jul 1 2018, 9:39 AM
Daimona assigned this task to DLynch.
Daimona raised the priority of this task from High to Needs Triage.
Daimona updated the task description. (Show Details)
Daimona added subscribers: gerritbot, Aklapper.
Cirdan added a subscriber: Cirdan.Jul 3 2018, 5:07 AM
Deskana triaged this task as Normal priority.Aug 17 2018, 9:29 AM

Should this be moved to QA?

Esanders added a subscriber: Esanders.

Calling this done, and filing T203151 to continue discussion around exposing this in the UI.

Deskana closed this task as Resolved.Sep 2 2018, 1:03 PM