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

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 - 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 9 - 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:

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

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

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

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
We will move Echo code to Echo extension.