User:Jdlrobson/Musings about the future of MobileFrontend

Related: User:Jdlrobson/Views_on_MobileFrontend_and_Minerva

Many people are quick to jump on the "MobileFrontend is an abomination!", "MobileFrontend should be in core!", "MobileFrontend sucks!" bandwagon but very few of those people have actually done MobileFrontend development. This has been a continuous point of pain for the reading web team (previously the mobile web team) and has been frustrating as we are all keen to see the back of it. I've written up these notes to get across my feelings on the subject and about how we go about moving towards this utopia.

Please do not edit this page, but feel free to fork it and add a link to the bottom of the page to your own thoughts on this subject.

What does MobileFrontend do?

Mobile skin vs response skin

The most useful features of the MobileFrontend extension, in my opinion, is the ability to run a different skin on a different domain. The debate about whether you should have a separate mobile experience or use a responsive desktop experience has many good arguments on both sides and really the answer to this is "it depends". MobileFrontend now and in the future needs to provide this functionality for our software to tailor to both of these arguments. It's important to remember that regardless of what the decision for that question is for Wikimedia sites, the same answer might not necessarily hold for a 3rd party MediaWiki user.

This, of course, could live in core.

In practice

Choice of skin is already configurable on a site basis although some skins need to update themselves to make themselves mobile friendly.

// With MobileFrontend installed invoke `mobile skin` by appending ?useformat=mobile&useskin=vector
$wgMFDefaultSkinClass = "SkinMinerva"; // Use Minerva as the skin used in the mobile site (default).
$wgMFDefaultSkinClass = "SkinVector"; // Use Vector as the skin used in the mobile site.
$wgMFDefaultSkinClass = "SkinBlueprint"; // Use Blueprint as the skin used in the mobile site.
//... and so on.

// You can then surface your mobile site on a different URL
// a mobile URL scheme that turns "en.wikipedia.org" into "en.m.wikipedia.org":
$wgMobileUrlTemplate = "%h0.m.%h1.%h2";

A series of hooks will adapt the skins footer for mobile mode, including updating the footer of the skin viewed as the mobile site to include a "desktop site" link. In theory, these hooks should also allow a mobile site to render different menus for mobile and desktop versions of the skin.

Next steps:

• Disentangle menu code from Minerva so that other skins can use it. Tracked in https://phabricator.wikimedia.org/T65459
• Port the device detection code / mobile skin loading code to core. Tracked in https://phabricator.wikimedia.org/T100402

Optimised Special Pages

Various special pages in MediaWiki core have not been built with mobile in mind. Many of these are incredibly important and changes to them are hard due to legacy code and backwards compatibility (many of these pages used table-based layouts). Some of these pages to work on a mobile screen need to be completely rewritten, but this is a costly activity that needs good coordination with existing communities to ensure that their needs are met.

The MobileFrontend extension currently replaces the watchlist, preferences, history, diff and contributions pages with its own versions that are optimised for mobile viewing. These versions are only enabled when the page is viewing inside the mobile mode of the site.

Fixing these pages in core is a gradual process, but has been traditionally slow.

In an ideal world, none of these optimisations would be needed.

A good case study of how we improved an experience and then upstreamed the results to core is the login and sign up pages. Historically these lived in the MobileFrontend extension but now these changes have bubbled up to core.

Next steps:

• Refactor the code in core for these special pages so that it can be re-themed for mobile using media queries (big task!)

A mobile friendly skin called Minerva

The bulk of the MobileFrontend code is the implementation of a MediaWiki skin built for mobile. This skin is JavaScript heavy and very different from traditional MediaWiki skins in that it is aggressively mobile first. Many editors dislike the intentional simplicity of this skin, but it seems to be quite popular with readers. There are also various Google Chrome extensions for redirecting the desktop site to the mobile site.

I believe that by allowing more choice to editors in their mobile experience, via user preference configuration, we can appease both groups.

It is unfortunate that the Minerva skin lives inside MobileFrontend and it is of my opinion that we should move this out as soon as possible. There are however various blockers to making this happen.

Features

The Minerva skin is unlike many other skins in that it provides new implementations of experiences tailored better for mobile users, by building from scratch it allowed itself to not be constrained by having to build upon existing established desktop interfaces. It leans heavily on overlays to enhance content. Unlike traditional skins categories and languages are not shipped in the initial HTML payload (to avoid clutter and keep first paint down) and are instead hidden behind buttons that must be clicked. The skin also features as JavaScript editor and a JavaScript version of talk pages so a user can easily jump back and forth between the talk and page. The reusable components powering these features would potentially be useful to other skins and ideally would be upstreamed to core/other extensions (for example the editor would be better provided by VisualEditor), but given these tools have been designed mobile first they would look out of place as is with Vector.

Blockers

There are 3 issues I see with moving Minerva outside of MobileFrontend.

The OOjs UI like library that's not in core

The Minerva skin was conceived before OOjs UI existed and as a result, came up with its own templating based approach similar to Backbone. Although the Minerva skin now uses OOjs heavily, seldom does it use OOjs UI. Many of the widgets in the MobileFrontend extension would be of use to other mobile skins, for example the `mobile.pagelist` module is used by the Nearby feature to render a list of pages as well as the search widget on the Minerva.skin

It's of my opinion that Minerva could have a soft dependency on MobileFrontend and when MobileFrontend is not installed simply operate in a limited non-JavaScript mode. This would allow us to move quickly while the required modules are incorporated into libraries that live in core that other extensions can use.

Verdict: Not a real blocker, if we take the soft dependency route.

PHP Libraries in MobileFrontend also used by Minerva

MobileUI, MobilePage, MFResourceLoaderParsedMessageModule and MenuBuilder are all used by the Minerva skin. The MenuBuilder library is also used by The Special:MobileMenu page, the MFResourceLoaderParsedMessageModule is used by certain modules that need it in MobileFrontend and MobileUI is used by the optimised special pages.

MobileUI, MobilePage and MFResourceLoaderParsedMessageModule are all useful and should be in core.

Verdict: The MenuBuilder arguably belongs in MobileFrontend (see "Mobile skin vs response skin") but it could also belong to Minerva.

Minerva coupled with MobileContext

The SkinMinerva makes use of MobileContext quite a lot and it really shouldn't. MobileContext should only be needed inside the MobileFrontend hooks when deciding to show a different skin for a mobile site and all the necessary rewriting of skins should happen there. This doesn't look too tricky to disentangle.

Verdict: Should be easy to disentangle once the menu code problem has been resolved.

Next steps:

• Disentangle menu code from Minerva so it lives inside MobileFrontend.skin.hooks.php and can be used by other skins.
• Review config variables that are prefixed with wgMF that live in SkinMinerva::getSkinConfigVariables and move to generic hooks. Rename Minerva specific ones so they are prefixed with wgMinerva
• Remove MobileContext usage from files in the includes/skins directory (https://phabricator.wikimedia.org/T125588)
• Move Minerva into a separate repository https://phabricator.wikimedia.org/T71366 with a soft dependency on MobileFrontend
• When Minerva skin is detected, prevent autoloading of skin classes inside MobileFrontend.
• Security review the new Minerva skin and get deployed to the cluster

Serving optimised content to mobile devices (MobileFormatter)

MobileFrontend provides a MobileFormatter that transforms content in ways designed to optimise content for mobile traffic. Currently, we are working to improve on this aspect of the extension to improve the experience of MediaWiki sites for 2G connections.

The MobileFormatter in current form wraps sections in container elements and allows the removal of certain elements via CSS class name selectors. It also includes some code which special cases the main page for mobile usage. This code is not really needed and is a workaround for badly formatted editor based content. We should be actively trying to engage our communities to reformat their main pages so that they do not need special casing and follow in the example of Wikidata which has a perfectly responsive main page design.

Soon it will be possible to use any skin in mobile mode applying these same transformations.

It's already been suggested that we should move this into a composer library and I full-heartedly agree.

During the current quarter we are continuing this work to include lazy loading images and more aggressive HTML transformations.

It's unclear whether these changes would also be useful to the desktop skin. Optimising content is a trade-off and it should be considered whether a desktop user on a fast connection would want an optimisation such as lazy loaded images.

A note about ResourceLoader Targets

ResourceLoader targets were added to force standardisation on certain libraries to keep JavaScript and CSS bloat down on the mobile site. jQuery UI for example replicates a lot of work that can be done via the OOjs UI. It is irresponsible to load two libraries that do the same thing. When operating in mobile mode a subset of the libraries are allowed. On the long term the plan should be to remove these, but this requires reimplementing many existing parts of the codebase in the preferred available libraries. Developers are forced to rethink their modules for mobile.

Similar a MediaWiki:Mobile.css wiki page is provided rather than MediaWiki:Common.css to avoid shipping unnecessary styles to the client.

Next steps:

• Move MobileFormatter and HtmlFormatter into composer libraries
• Continue optimising the mobile experience for skins operating in mobile mode inside MobileFormatter and generic hooks.
• Engage community liaisons and remove main page special casing (see https://phabricator.wikimedia.org/T32405)
• Consider whether the JavaScript for section toggling would be useful on all mobile variants of skins e.g. Vector (currently we do not load any JS to invoke it)

New Special Page features

Over time, MobileFrontend has been a place for new ideas.

These are the Nearby feature, Special:Uploads, Special:MobileLanguages, and the ill-fated user profiles.. Now it has matured, we recognise this was an anti-pattern and have begun splitting out new features. For instance recent experiments with Gather and RelatedArticles have been done outside the extension.

Next steps:

• Continue to upstream / move these features to separate extensions including Nearby, removal of User:Profile (currently in progress)
  • Nearby
  • Languages
  • Uploads
  • UserProfile

What should it do?

It is of my opinion MobileFrontend should be very light and provide the following functionality:

• Allow the sysadmin to wire up a separate mobile site that uses a different skin
• Provide optimisations to the content to improve loading.

That said, both these things could arguably be supported by core.

If not supported by core, I don't think MobileFrontend should die, but I think the above specialisations are useful for sysadmins who want to provide alternative mobile site experiences with optimised content. I think it's an open question to whether the optimisations happening in MobileFormatter should happen to the desktop experience at all.

In the future, it's possible Wikimedia may want to drop the MobileFrontend extension from its sites and use a single responsive skin as the default for all users (maybe Minerva, maybe Vector, maybe a new skin called Vecterva ). By making these changes now, we allow our community to be empowered to make that decision in the not so distance future.

We should empower our community to be able to make that decision in future.

A roadmap

• Given that Minerva accounts for the majority of code in MobileFrontend it is of my opinion that we should prioritise pulling this out. It's my opinion that with a smaller codebase and with less tight coupling/ambiguity between Minerva and MobileFrontend we will write better cross-skin experiences.
• It's a no-brainer that the special pages in MobileFrontend need to be pulled out and/or their ideas need to bubble up into core.
• The generic frontend libraries used by Minerva could arguably be useful to other skins who want to operate in a mobile mode. Over time these libraries might want to be rewritten in OOjs UI or put into core as a library that extends OOjs.

Step by step to split out Minerva

• First we need to generalise the menu generation in MobileFrontend so that it is not tied to Minerva. For instance we'd want to link to Special:MobileOptions in mobile mode and Special:Preferences in desktop mode.
• Remove any reference to MobileContext in SkinMinerva
• Once this is done we should update the autoloading of classes in MobileFrontend to not autoload Skin classes when Minerva skin is already present.
• I've built a migrate script that will port the necessary bits of code from MobileFrontend to a Minerva repository. This would result in a skin that is dependent on MobileFrontend being installed.
  • We'd run it after obtaining security review
  • deploy the Minerva extension to the cluster
  • Remove the code from MobileFrontend
  • Update the Minerva repository so MobileFrontend is a soft dependency