User:Jdlrobson/Views on MobileFrontend and Minerva

Recommendations

MobileFrontend should be reduced to two functions:

1) Allowing a different skin to run on a mobile domain

2) Providing a MobileFormatter to massage HTML and optimise it for mobile users with slower connections

Anything else is not in scope for the MobileFrontend project and should be reconsidered.

The MobileFrontend mobile.startup library should be replaced by Codex components that can be used in both the Minerva and Vector 2022 skins
Special:MobileOptions special page should be replaced with a dialog that can be used on Vector 2022 to support settings for anonymous users.
The remaining MobileFrontend special pages (Special:Watchlist, Special:EditWatchlist Special:MobileHistory, SpecialMobileLanguages, MobileDiff) should be removed from MobileFrontend once suitably replaced using skinStyles and/or updates in MediaWiki core.

Current challenges

MobileFrontend and Minerva continue to unnecessarily confuse developers of MediaWiki and 3rd parties who want mobile sites. The functions they serve are useful but their value is impacted by the fact they do too many unnecessary things which is a consequence of decisions made during the timeline of the project.

Analysis of problem

MobileFrontend should be reduced to two functions:

1) Allowing a different skin to run on a mobile domain

2) Providing a MobileFormatter to massage HTML and optimise it for mobile users with slower connections

Currently, MobileFrontend does not do this. In addition to the above it also does these unnecessary things:

1) Provides several special pages that replace existing ones in core e.g. Special:Watchlist, Special:Contributions and Special:MobileHistory, Special:EditWatchlist

2) it provides JavaScript functionality that can be used by a skin to provide better mobile experiences

3) It provides Special:Nearby

4) It provides Special:MobileLanguages (for language selection without JavaScript),

5) It provides Special:MobileDiff (allowing inline diffs)

6) It provides Special:MobileOptions (for mobile skin preferences and providing a beta mode with a feature management system for adding experimental features for anonymous users.)

7) It provides Special:MobileMenu (for non-JS menu support in mobile skins)

8) It provides Special:Uploads (a redundant page that duplicates functionality of Special:ListFiles)

9) It restricts certain JavaScript/CSS modules from loading on pages to improve the performance of the site.

All of these things are workarounds for larger problems, and to have a sustainable and mobile friendly MediaWiki we must look to eliminate the above issues.

In the future, MediaWiki users should be able to either install a responsive skin that serves their mobile and desktop traffic or they should be able to install a basic MobileFrontend which allows them to serve a different skin to their mobile domain users. This page outlines how I think we need to get there and what the larger problems are.

Unsolved problems

Problem 1d - Replace Special:EditWatchlist with Special:ReadingList

The mobile edit watchlist acts like a reading list. It should be phased out in favor of the new reading list feature.

Problem 2 - The MobileFrontend JavaScript library (mobile.startup)

This library exists as OOUI adoption never took off. Ideally this library should be unified with OOUI or a new component library that lives in core. This is a large project.

https://phabricator.wikimedia.org/T281930

Problem 6 - Replace Special:MobileOptions with a JavaScript dialog that works across skins.

Special:Preferences is overwhelming. The BetaFeatures extension only works on logged in users. Certain features in Special:MobileOptions use localStorage rather than logged in so work for non-logged in users.

A) If we stop caring about beta testing on anons, we should remove the beta mode

B) We should explore creating a page like Special:Preferences that is leaner and relates to reading preferences only. This would be useful for desktop too. I'm hoping in the desktop refresh project we find an opportunity to create such a page and expose it in Minerva and remove the Special:MobileOptions page.

https://phabricator.wikimedia.org/T91201

Solved problems

Problem 1 - removing Special:MobileWatchlist, Special:MobileContributions and Special:MobileHistory

An expensive decision was made that we needed to improve certain special pages for readers so that they could understand their purpose while maintaining the status quo for desktop users. These designs can and should be consolidated. This needs to be either done by challenging the requirement to keep desktop change free, or by providing mark up changes that support the mobile equivalent designs.

The designs are not too far apart - the most notable difference being that the mobile site groups change by the day (https://en.m.wikipedia.org/wiki/Spain?action=history) whereas the desktop site has no grouping. If groupings were added to the HTML desktop we could unify these two pages with just CSS (for example hiding the new groupings in Vector).

https://phabricator.wikimedia.org/T210168

Problem 1a - removing Special:MobileWatchlist

https://phabricator.wikimedia.org/T109277

Problem 1b - removing Special:Contributions

Minerva renders differently from Vector via CSS (skinStyles).

Problem 1c - removing Special:MobileHistory

https://phabricator.wikimedia.org/T305113

Problem 3 - Moving Special:Nearby to a more suitable extension

Special:Nearby depends on the mobile.startup library, so either problem 2 needs to be solved or the entire special page needs to be rewritten in OOUI or Vue.js (which is currently in core). We ported the feature to a new extension built in Vue.js called Extension:NearbyPages.

https://phabricator.wikimedia.org/T66316

Problem 4 - Removing Special:MobileLanguages

Currently this page lives in MobileFrontend. IN https://phabricator.wikimedia.org/T326829 we decided for SEO reasons that it's preferable to include the language links in the page for Minerva skin, and then remove this page.

Problem 5 - Replace Special:MobileDiff with ?diff=<rev>&diff-type=inline

Single column diffs would be useful in core. With some changes the existing core page can be altered to be responsive. It's a matter of when rather than if. https://phabricator.wikimedia.org/T117279

Problem 7 - Remove Special:MobileMenu

We can render the menu using a CSS only solution. If the main menu in Minerva works without JS we can do away with this page.

Problem 8 - Replace Special:Uploads with Special:ListFiles

We should just remove this page. ListFiles is good enough.

Problem 9 - Remove the targets system

MobileFrontend uses a target system. Modules that are not marked as mobile are not loaded at all. This is a long and winding road, but to solve it, we need to review all modules that don't express a target and make sure their loading strategy makes sense. Many modules load when they are not necessary. Instead they should load small lightweight bootstrapping modules. Popups provides a good example of how this works.

https://phabricator.wikimedia.org/T127268

Problem 10 - Break Minerva hard dependency on MobileFrontend

The mw.mobileFrontend object should not be used inside Minerva. Desktop Minerva (without MobileFrontend) should be reduced to a skin with:

A) A working main menu that works without JS (https://phabricator.wikimedia.org/T225213)

B) A working watch star using code from core (https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/540169/)

C) A working search (As part of the desktop refresh project we should unify search in Minerva and Vector and NewSkin)

D) A working notifications button via Echo

All other code should only load when MobileFrontend is installed. That code should potentially be moved to the `mobile.init` module in MobileFrontend.

A Roadmap

In parallel with the desktop refresh

[✅ ] We should remove Special:Uploads (T233985) solve problem 8

[✅ ] We should move Echo code from Minerva/MobileFrontend to Echo extension. (T221007)

[✅] We will make the main menu work without JS to solve problem 7 and 10A (T225213)

[] When cache allows we will drop Special:MobileMenu to cleanup after solving problem 10.

[ ✅] The watchstars in MobileFrontend and Minerva will make use of core's watchstar code to solve problem 10B (T234970)

[ ✅]] The MobileFrontend search will be restricted to Minerva when running under the mobile target system. When desktop Minerva, the search in core will be used solving problem 10C.

[ ✅] The hard dependency of Minerva on MobileFrontend will be dropped (T171000) solving problem 10

[ ] Code inside Minerva that uses mw.mobileFrontend will be moved to mobile.init inside MobileFrontend and made to work on all skins operating on the mobile domain.

[✅] The unified diff provided by Special:MobileDiff should be moved into core. Diffs would support the side by side view and the unified mode.

[✅] MobileFrontend should use the wikidiff2 inline diff mode in core and InlineDifferenceEngine will be deprecated (https://gerrit.wikimedia.org/r/#/c/558677/)

[✅] We'll remove the code for inline diffs in MobileFrontend (T240622)

[✅ ] We'll update the styling of the Minerva desktop diff page so it can be used instead of Special:MobileDiff (T240624)

[✅ ] We'll drop Special:MobileDiff to solve problem 5 (T117279)

[ ✅] Special:MobileLanguages is going to be useful for other skins. It will likely be needed for desktop refresh. It should be put in core and solve problem 4 (T104660)

[ ] as part of the desktop refresh project, we should commit to turning off beta (T237290) solving problem 6A

[ ] as part of the desktop refresh project, Special:MobileOptions should be replaced with a "change device settings" overlay that works on both mobile and desktop solving problem 6B (T233741)

[ ] The easiest way to solve problem 1 is to use AMC special pages for all. A more tedious solution would be to make changes to the HTML to support replicating these pages with CSS only. What happens depends on discussions with product and design. This problem is captured in an entire phabricator board.

[ ] All modules that have not specified 'mobile' across all extensions and core will be audited. Any modules that load unconditionally on pages will be flagged via tasks requesting that their code is reduced to code that loads via mw.loader.using or mw.requestIdleCallback. As a result desktop performance should improve by shipping less bytes of JS and CSS identifying the blockers of problem 9.

[✅ ] The targets system will be scrapped solving problem 9

[✅ ] For Nearby maybe we don't need to solve problem 3 but a simple way would be to reimplement the entire feature in Vue.js as recommended frontend group. This special page would be provided by a new extension.

[ ] Minerva's mobile.startup would slowly be converted to components in the new framework and moved into Minerva/core as appropriate. This would solve problem 2 [ ] MobileFrontend is now allows a different skin to run on a mobile domain and providing a MobileFormatter to massage HTML and optimise it for mobile users with slower connections. It should have no other purpose.

Echo-specific

[ ] The desktop implementation of Echo that runs on Minerva desktop should be the same as the implementation on mobile. It will be improved to be responsive and mobile friendly. (T226125)

[ ] The custom mobile implementation of Echo should be scrapped in favor of the desktop version (T226125)