Reading/Web/MobileFrontend and Minerva

< Reading‎ | Web
Jump to navigation Jump to search

MobileFrontend currently does lots of things. This causes confusion. Here, I hope to shed light on how the extension is architected.

What does installing MobileFrontend do?[edit]

Installing MobileFrontend currently has several outcomes:

  • It ships various new experiences and capabilities such as:
    • the ability to render Wikidata descriptions in skins
    • The Special:Nearby page
    • The Special:Upload page
    • It adds a Special:MobileOptions page to allow anonymous users to configure device specific options
    • For the record I don't think it should do any of these things.
  • It installs the MediaWiki Minerva skin which can be installed as a desktop or mobile skin
  • It sets up an infrastructure for sites managing a separate mobile and desktop experience
    • A temporary ResourceLoader "targets" system to limit JavaScript/CSS that can make it onto mobile browsers
    • It allows you to default to a different skin on a mobile domain via MFDefaultSkinClass. 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
      • You can blacklist pages via MFNoMobilePages to force desktop skin on pages which shouldn't be rendered on mobile.
      • The MobileFormatter class has special handling directed at the main page of Wikimedia projects via MFSpecialCaseMainPage. This is not helpful to 3rd parties.
      • There are experiments to lazy load references and move the first paragraph before the infobox.
      • It overrides various special pages in core with new mobile friendly versions include Special:Contributions, Special:Watchlist, Special:Preferences (unused), the history page (Special:MobileHistory)


  • 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

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

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

For example the Vector mobile skin has lazy loaded image HTML but does not actually load the images via JavaScript

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

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

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.

Draft proposal[edit]

I'd like to see us have a clear separation in MobileFrontend about what relates to the Minerva skin and what relates to the MobileFrontend skin. They can live in the same repository (potentially with Minerva as a submodule) and Minerva can depend on MobileFrontend concepts but it helps us think about what's a MobileFrontend concept vs what's a Minerva(skin) concept.

I'd be open to enabling the Minerva desktop skin on, as I'm mostly interested in improving the codebase and separation of concerns relating to formatting mobile content and rendering mobile content.