User:Jdlrobson/Views on MobileFrontend and Minerva

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.

Goal
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

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.

Problem 1 - removing Special:MobileWatchlist, Special:MobileContributions and Special:MobileHistory
An expensive decision was made that we needed to improve these 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).

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.

Problem 3 - Removing Special:Nearby
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 (which is currently in core). We could also just leave it in MobileFrontend. It's existence here is not a big deal.

Problem 4 - Special:MobileLanguages
Currently this page lives in MobileFrontend but it could be easily added to Minerva or core. The reason it is not in core is that only one skin uses it - Minerva. The desktop refresh project may change that and make putting this in core an easier sell.

Problem 5 - Special:MobileDiff
Single column diffs would be useful in core. It's a matter of when rather than if. https://phabricator.wikimedia.org/T117279

Problem 6 - Special:MobileOptions
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.

If we stop caring about beta testing on anons, 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.

Problem 7 - 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- Special:Uploads
We should just remove this page.

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

Problem 10 - Minerva has a hard dependency on MobileFrontend (because of problem 2)
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.

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)

[ ] The desktop implementation of Echo now running on Minerva desktop will be improved to be responsive and mobile friendly.

[ ] The mobile implementation of Echo should be scrapped in favor of the desktop version solving problem 10D (T226125)

[ ] Make the main menu work without JS (T225213) and drop Special:MobileMenu to solve problem 7 and 10A

[ ] 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. We might also want to explore merging this functionality with the visual diff code if it's okay to depend on JS being available 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, Special:MobileOptions should be replaced with a "change device settings" overlay that works on both mobile and desktop solving problem 6 (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.

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

After a framework is decided by the Frontend Architecture Working Group
[ ] maybe we don't need to solve problem 3 but a simple way would be to reimplement the entire feature in OOjs UI or whatever new framework is proposed by the 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.