Reading/Web/MobileFrontend and Minerva

MobileFrontend is the extension that provides a mobile site for MediaWiki/Wikipedia.

Minerva is a responsive skin tailored and optimised for mobile users.

However the boundaries between the two are not clear. MobileFrontend currently does lots of things it shouldn't. This causes confusion. Here, I hope to shed light on how the extension is architected.

What does installing MobileFrontend do?

Installing MobileFrontend currently has several outcomes:

• It ships various new experiences and capabilities:
  • the ability to render Wikidata descriptions in skins
  • It adds a Special:MobileOptions page to allow anonymous users to configure device specific option
    • This uses the FeatureManager class to allows extensions to register and enable/disable features that can be enabled/disabled in settings.
  • (For the record I don't think it should do any of these things.)
• It provides the mobile.startup component library
  • This predates Codex and provides mobile workflows for editing, languages and image viewing. It can be used by skins.
• It sets up an infrastructure for sites managing a separate mobile and desktop experience
  • It allows you to default to a different skin on a mobile domain via MFDefaultSkinClass which defaults to minerva. This is useful for wikis who are trying to migrate from an existing desktop friendly MediaWiki instance to a mobile friendly instance and want to migrate slowly.
    • The extension updates the footer of the skin to have a desktop view / mobile view link
    • Any request using DeviceDetection that is recognised as mobile will be shown the mobile skin
  • It allows you to transform the content you ship to mobile devices in the mobile skin
    • It provides a MobileFormatter class that transforms the HTML provided by the MediaWiki parser that has been created primarily for desktop users to make it render better on mobile.
    • It allows you to define css selectors of elements that are not mobile friendly and should be removed via the MFRemovableClasses configuration variable
    • It allows you to lazy load images in the mobile version of a skin MFLazyLoadImages
    • The ability to disable responsive images using MFStripResponsiveImages
    • The ability to move the first paragraph before the infobox.
    • It overrides various special pages in core with new mobile friendly versions of Special:Watchlist, the diff page Special:MobileDiff and the history page (Special:MobileHistory)

tldr

• MobileFrontend checks if you are in mobile or desktop mode.
• In desktop mode nothing happens
• In mobile mode it ships transformed mobile-friendly content to the configured mobile skin and redirects non-mobile friendly special pages to mobile friendly versions
• In mobile mode, a JavaScript component library for mobile is added.

Why it is not helpful to think of MobileFrontend and Minerva as the same thing?

It confuses our abstractions - we put Minerva specific code into MobileFrontend and vice versa.

For example the Vector mobile skin has section collapsing.

We are unclear/forget about the abstractions and use things that are not always available. This leads to bugs such as PHP warnings related to footer V2 when run Minerva in desktop mode and SkinMinerva and SkinMinervaBeta should not know about MobileContext

Outsiders see MobileFrontend as a big extension that does too much

That's because it's doing 3 things. This lack of understanding can lead to frustration/conflict. It actually hides the good work we've done.

We cut corners

By living in the same repo, MobileFrontend allows us to cut corners. Wikidata descriptions not in core? Stick them in MobileFrontend! Don't want to go through the hassle (security review, setup costs) of setting up a Nearby extension? Add it to MobileFrontend etc...

Lost opportunity for 3rd party mobile skins

It's probably not obvious to 3rd parties that they can change the mobile skin just like the desktop skin. It would be good to see non-Wikimedia looking mobile skins out in the wild. Wouldn't it?

... but why do we care about Minerva as a desktop skin?

because... as Morpheus from the Matrix might say... there is no "desktop" skin..

A skin should just be a skin. If we have the same mental model of what MobileFrontend and Minerva do differently, this should be obvious.

Some 3rd parties don't need MobileFrontend

but they would look mighty fine with a Minerva skin and all the design work that Nirzar, Alex and all the designers who came before him have put in.

It keeps us accountable to the rest of the MediaWiki ecosystem

If we don't care, we should build a web app or an app that doesn't depend on MediaWiki and make that explicit, but while we are in this ecosystem we should play by the rules.

Cost is low

The perceived cost might seem high, but if you reflect a little it isn't. We don't have many bugs about desktop Minerva. When we encounter issues, they are a little tricky to solve, but more of a nuisance than anything. This is primarily because we don't expose the skin to desktop users in production, but also because of the way it is architected. In theory there's little that could go wrong unless MobileFrontend code ends up in Minerva.

We get desktop features for free

Look! Minerva page previews!!!! (If you're logged in, make sure Page Previews are turned on; or look at it while not logged in.)

Encourages us to upstream

Where we hit issues we should solve them for everyone rather than just Mobilefrontend. This helps us when we build things like Page Previews.

Helps people understand and support the good work we are doing

Currently many developers look at MobileFrontend and all the things it is doing and because it is so big, switch off. Separating the skin portion from MobileFrontend will show core developers that MobileFrontend is doing interesting and useful things that could and should be consolidated with core.

We can on the long term remove the need from MobileFrontend

It's my belief that everything MobileFrontend does should be in core. My hope is by making it more visible about what we are doing there we can speed up those conversations.

... Why shouldn't we?

Increased workload through visibility

Currently we disable Minerva from showing in desktop preferences. Enabling Minerva here would make desktop users aware of the skin. This has pros and cons. For instance, it might provide an easier path for editors to preview content (by appending ?useskin=minerva). On the negative side, it may lead to more awareness of problems with the skin which may lead to more bug reports and requests for improvements to special pages. This is not necessarily a bad thing, but it could be overwhelming.

Proposal for fixing

Jon Robson talks about a strategy for solving the problem and making the distinction between the two clearer in User:Jdlrobson/Views_on_MobileFrontend_and_Minerva