User:Jdlrobson/Views on MobileFrontend and Minerva
Recommendations
[edit]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
[edit]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
[edit]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
[edit]Problem 1d - Replace Special:EditWatchlist with Special:ReadingList
[edit]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)
[edit]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.
[edit]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
[edit]Problem 1 - removing Special:MobileWatchlist, Special:MobileContributions and Special:MobileHistory
[edit]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
[edit]https://phabricator.wikimedia.org/T109277
Problem 1b - removing Special:Contributions
[edit]Minerva renders differently from Vector via CSS (skinStyles).
Problem 1c - removing Special:MobileHistory
[edit]https://phabricator.wikimedia.org/T305113
Problem 3 - Moving Special:Nearby to a more suitable extension
[edit]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
[edit]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
[edit]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
[edit]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
[edit]We should just remove this page. ListFiles is good enough.
Problem 9 - Remove the targets system
[edit]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
[edit]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
[edit]In parallel with the desktop refresh
[edit][✅ ] 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
[edit][ ] 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)