[EPIC] Enable editing for mobile users without JavaScript and kill Special:MobileEditor code in MobileFrontend
Closed, ResolvedPublic8 Story Points

Description

With minor work and the removal of Special:MobileEditor this seems possible.
I started a proof of concept patch to demonstrate: https://gerrit.wikimedia.org/r/267199

  • Remove the hook that redirects all action=edit's to Special:MobileEditor when wgMFAllowNonJavaScriptEditing=true
  • Add editor ResourceLoader module skins.minerva.fallbackeditor to pages with action=edit
  • Style anon warning box with warningbox class (might require change in core)
  • lead edit icon should be visible https://gerrit.wikimedia.org/r/347126
  • Reduce size of the license text and warning messages making more space for the editing form https://gerrit.wikimedia.org/r/347127
  • Decrease size of text area so for logged in users without an anon warning box the buttons below it are visible on a standard mobile screen.
  • Update MobileFormatter to output action=edit in the URLs of edit links
  • skins.minerva.editor should hijack edit links
  • Edit icon should be styled to the right without non-js as it is in JS preferably with icon, but be careful with how many icons are pulled down
  • cancelLink, mw-editButtons-pipe-separator and editHelp should be hidden in mobile view - they look cramped.
  • Discussion link should not show on editor
  • Page actions - edit and watch should not show on editor
  • Enable wgMFAllowNonJavaScriptEditing=true on the beta cluster to allow testing
  • Verify non-JS editing works on beta cluster
  • Test run on one production wiki
  • Enable wgMFAllowNonJavaScriptEditing=true on production and investigate impact on editing
  • Remove wgMFAllowNonJavaScriptEditing and allow editing without JavaScript by default based on good results

Post-removal of wgMFAllowNonJavaScriptEditing:

  • Remove Special:MobileEditor

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson moved this task from Tasks to Epics on the MobileFrontend board.Jul 27 2016, 4:51 PM
Jdlrobson renamed this task from Enable editing for mobile users without JavaScript and kill Special:MobileEditor code in MobileFrontend to [EPIC] Enable editing for mobile users without JavaScript and kill Special:MobileEditor code in MobileFrontend.
Jdlrobson removed Sumit as the assignee of this task.
Jdlrobson added a project: Epic.

Change 271594 abandoned by Jdlrobson:
Override Copyright warning message for Minerva

Reason:
Hi Sumit I'm abandoning this in case someone else wants to work on it (that can obviously be you). Luckily this change will be preserved in Gerrit for whoever wants to take another go at it! Thank you for trying!

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

Checking in, the current state of reality if you enable non-JS editing (simulated iPhone 5, which is already generous for low-end):

StateNowAfter T111088 (using PS23 of 231600)
First view
Save boxes

Issues from this:

  • heading-holder has 20px padding-top, to give space for the in-other-languages button that's not there. Easy fix?
  • Padding on the sides of the input box could probably be slimmed-down to give marginally more space (especially when there's so little of it).
  • This should probably be using a monospace font
  • The OOUI-ification makes the checkboxes much more accessible in touch environments, but the padding's too big on the checkboxes and too small on the buttons.

Other issues:

  • You can't edit the whole page (but you can create it).
  • You can't edit section 0 unless you URL-hack it.
  • Collectively, this means that on pages where there's no sections yet, you can't do anything.
  • You can create the page if you manage to URL-navigate to it, but red links are suppressed and

The save buttons are not in view on open, but they're also never going to be as soon as the keyboard opens, so I'm not too worried.

Overall I feel this is quite close.

Checking in, the current state of reality if you enable non-JS editing (simulated iPhone 5, which is already generous for low-end):

Remember this is not just non-JS editing. Slow connections may hit this page accidentally so I suggest that we give them a good experience too.

The save buttons are not in view on open, but they're also never going to be as soon as the keyboard opens, so I'm not too worried.

Please do worry!! :) We've found buttons hidden below the fold to be less discoverable. We hit this issue with Special:MobileOptions - saves there halved when we accidentally pushed it below the fold. Most mobile interfaces I see surface the save buttons at the top of the screen on mobile and I'd suggest we'd be wise to do that - imo that's the only blocker here and there's plenty of space under the header to move them to be consistent with other products/our own!

I'd also suggest reducing the size of the license text. It's inconsistent with how we do licenses in every other place on the mobile site and I'd be worried about consistency (cc @Nirzar and @Volker_E )

You can't edit section 0 unless you URL-hack it.

Not sure what you mean by that? The edit icon at the top of the mobile interface defaults to lead section. There is no full page editing without VisualEditor.

Collectively, this means that on pages where there's no sections yet, you can't do anything.

You can edit the lead section and add headings in it....

You can create the page if you manage to URL-navigate to it, but red links are suppressed and

Red links are not a problem. We do not suppress them on the mobile site and you can edit. Only apps suppress them.

The save buttons are not in view on open, but they're also never going to be as soon as the keyboard opens, so I'm not too worried.

Please do worry!! :) We've found buttons hidden below the fold to be less discoverable. We hit this issue with Special:MobileOptions - saves there halved when we accidentally pushed it below the fold. Most mobile interfaces I see surface the save buttons at the top of the screen on mobile and I'd suggest we'd be wise to do that - imo that's the only blocker here and there's plenty of space under the header to move them to be consistent with other products/our own!

You can't put the save / etc. buttons above the licence text, so you'd have to instead make the button into a form submit to the next page where it's shown, which gives you all of the downsides of the VE/NWE model (not able to see the summary and content at once) and all of the downsides of non-JS (not able to move back and forth)

I'd also suggest reducing the size of the license text. It's inconsistent with how we do licenses in every other place on the mobile site and I'd be worried about consistency (cc @Nirzar and @Volker_E )

Sure, though of course Legal would need to sign that off.

You can't edit section 0 unless you URL-hack it.

Not sure what you mean by that? The edit icon at the top of the mobile interface defaults to lead section. There is no full page editing without VisualEditor.

Collectively, this means that on pages where there's no sections yet, you can't do anything.

You can edit the lead section and add headings in it....

Observe:

Page with JavaScriptPage without JavaScript

Note that the section 0 edit link is missing. (As is the watchlist star, which I care less about but is still non-JS-accessible in desktop.) I assumed this was intentional, but if it's a bug it'd be good to fix. :-)

You can create the page if you manage to URL-navigate to it, but red links are suppressed and

Red links are not a problem. We do not suppress them on the mobile site and you can edit. Only apps suppress them.

Oh, neat. My apologies. :-)

Elitre added a subscriber: Elitre.Mar 24 2017, 7:33 PM

That edit icon is easily revealed. In the existing view, we have nothing to link to hence why it's there. It can be displayed as part of wrapping up the work here.
After T111088 is applied it seems the main issues relate to use of space - seems easy enough to recover the space between heading and text area, shrink license size (I don't see why this needs legal sign off as they already signed off on the license text size in the editor overlay). Also I wonder if the heading "Editing Foo (section)" really need to be heading font-size. This doesn't seem like much work, if we wanted to spend a day focusing on this I think we could resolve these problems promptly.

That edit icon is easily revealed. In the existing view, we have nothing to link to hence why it's there. It can be displayed as part of wrapping up the work here.

Cool. Could we move it to the same level as the heading to save those ~ 30px of vertical height, or would that be difficult for other reasons?

After T111088 is applied it seems the main issues relate to use of space - seems easy enough to recover the space between heading and text area, shrink license size (I don't see why this needs legal sign off as they already signed off on the license text size in the editor overlay).

Oh, right, I thought you meant changing the text, not changing its font size. Yeah, that's totally fine. :-)

Also I wonder if the heading "Editing Foo (section)" really need to be heading font-size.

Yeah, if we could shrink it a fair bit that'd also save users vertical space, which is the main premium.

This doesn't seem like much work, if we wanted to spend a day focusing on this I think we could resolve these problems promptly.

Nice. I'd be very happy to help.

Krinkle added a subscriber: Krinkle.Apr 5 2017, 1:16 AM
This comment was removed by Krinkle.

Change 347126 had a related patch set uploaded (by Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Lead section edit icon should be visible when no-js editing is enabled

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

Change 347127 had a related patch set uploaded (by Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Improve layout of fallback editor

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

Jdlrobson updated the task description. (Show Details)Apr 7 2017, 10:36 PM

So I've made some changes above to compact the information into the space available. Logged in users will see the buttons at the bottom of the page. Anonymous users however will need to scroll past the warning box which I assume is the intention :)


We may want to consider hiding the minor edit and watch this page boxes. With OOjs UI the buttons get pushed below the fold and I don't think they are vital to the editing experience. I would hazard a guess that a small % of our editors actually use those boxes on desktop and in the current mobile editor we don't surface them.

Can anyone in your team provide code review here? My team have not been involved in this work and under the reading banner I'm going to struggle to get code review support :)

Change 347126 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Lead section edit icon should be visible when no-js editing is enabled

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

Looks good; merged your patches (except for the hygiene one which has a blip).

OK, one last thing:

If you're logged out, the mobile menu has no log-in option in no-JS mode. However, if you try to edit using the no-JS fallback editor, you're prompted to login, and following the link successfully works. Is it missing from the menu for performance reasons, reducing the load for non-JS users?

Change 347127 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Improve layout of fallback editor

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

Two nitpicks for the future:

  • Could we remove the <i> tag around the copyright warning in consideration of CJK languages. (And probably make a tad smaller, you said it's done in a font-size like everywhere else, still)
  • Put margin-top: 0.5em; on the edit summary

Change 349114 had a related patch set uploaded (by Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Reveal login/logout buttons when non-js editing is available

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

Isn't editpage-copywarn a MediaWiki message provided by the wiki?

If you're logged out, the mobile menu has no log-in option in no-JS mode. However, if you try to edit using the no-JS fallback editor, you're prompted to login, and following the link successfully works. Is it missing from the menu for performance reasons, reducing the load for non-JS users?

Addressed in https://gerrit.wikimedia.org/r/349114

Nirzar removed a subscriber: Nirzar.Apr 19 2017, 11:05 PM
kaldari removed a subscriber: kaldari.Apr 19 2017, 11:10 PM

Change 349114 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Reveal login/logout buttons when non-js editing is available

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

Change 349274 had a related patch set uploaded (by Jforrester):
[operations/mediawiki-config@master] Enable mobile non-JavaScript editing on all MobileFrontend wikis

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

Any updates on this or any help needed?
Patch is -2 with comments "Needs announcing, decision on release process."

Elitre added a comment.EditedJun 1 2017, 9:10 AM

Probably the task for CLs hasn't been filed yet? (I thought T163929 was it.)

EDIT: I have now filed it to reflect that we had already had some conversation around this.

Change 361455 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Enable mobile non-JavaScript editing on ptwiki

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

Change 361455 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable mobile non-JavaScript editing on ptwiki

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

Change 349274 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable mobile non-JavaScript editing on all MobileFrontend wikis

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

Mentioned in SAL (#wikimedia-operations) [2017-07-18T13:16:45Z] <zfilipin@tin> Synchronized wmf-config/mobile.php: SWAT: [[gerrit:349274|Enable mobile non-JavaScript editing on all MobileFrontend wikis (T125174)]] (duration: 00m 44s)

Mentioned in SAL (#wikimedia-operations) [2017-07-18T13:18:18Z] <zfilipin@tin> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:349274|Enable mobile non-JavaScript editing on all MobileFrontend wikis (T125174)]] (duration: 00m 43s)

Mentioned in SAL (#wikimedia-operations) [2017-07-18T13:19:28Z] <zfilipin@tin> Synchronized wmf-config/InitialiseSettings-labs.php: SWAT: [[gerrit:349274|Enable mobile non-JavaScript editing on all MobileFrontend wikis (T125174)]] (duration: 00m 43s)

Change 365997 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/MobileFrontend@master] Hygiene: Drop MFAllowNonJavaScriptEditing and Special:MobileEditor

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

Jdforrester-WMF changed the point value for this task from 1 to 8.

Change 367688 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Hygiene: Drop MFAllowNonJavaScriptEditing and Special:MobileEditor

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

Jdlrobson moved this task from Needs triage to Triaged on the Mobile board.Jul 25 2017, 5:50 PM

Change 367688 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Hygiene: Drop MFAllowNonJavaScriptEditing and Special:MobileEditor

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

Jdforrester-WMF closed this task as Resolved.Jul 26 2017, 6:41 PM
Jdforrester-WMF removed a project: Patch-For-Review.
Jdforrester-WMF updated the task description. (Show Details)
Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptJul 26 2017, 6:41 PM

Change 365997 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Hygiene: Drop MFAllowNonJavaScriptEditing and Special:MobileEditor

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

MaxSem removed a subscriber: MaxSem.Jul 26 2017, 6:52 PM
Jdlrobson added a subscriber: atgo.Jul 26 2017, 6:59 PM

Where can we follow the analysis?

This is a huge landmark for Wikipedia mobile and I'd be interested in how this is reacted to by people with phones like Opera Mini and UC browser who previously couldn't edit.

Is this something New-Readers is tracking @atgo ?

atgo added a subscriber: DFoy.Jul 26 2017, 11:55 PM

Thanks for the ping @Jdlrobson . Not something we've been tracking, but glad to see it's happening! I'd love to be in the loop for any analysis that happens, though this is outside the scope of New Readers.

@DFoy - FYI.

waldyrious added a subscriber: waldyrious.
Elitre awarded a token.Aug 6 2017, 5:30 PM