Talk:Reading/Web/MobileFrontend and Minerva

About this board

Missing "Why is it helpful to have them in the same repository..." section

3
Phuedx (WMF) (talkcontribs)

For example:

  • If MobileFormatter changes the way that content is transformed, then Minerva is likely to be updated soon after – it's unlikely (but possible) that a change to Minerva would cause a change in MobileFormatter soon after.
  • Vendoring libraries on a per-extension basis is hard.
Jdlrobson (talkcontribs)

I forgot to add "IN progress" which I've done now and I've started filling in new sections. I've also outlined a draft proposal to give a sense of where I'm going with all this. I hope this clarifies my thinking a little more.

I'm curious if you could go into more detail about "a change to Minerva would cause a change in MobileFormatter soon after.'

Can you give an example?

From my perspective if these two components are separate they should be agnostic to

changes.

I see purpose of MobileFormatter is to provide content in a well defined format to Minerva.

The desktop version of Minerva (useformat=desktop&useskin=minerva) doesn't use MobileFormatter at all.

Can you expand on Vendoring libraries on a per-extension basis is hard?

Which libraries would both Minerva and MobileFrontend make use of?

I should note my main concern is making it possible to separate in future the two repos, not to necessarily pull them apart. A git submodule might help with problems like these, but right now I'm not seeing concrete examples of where we'd need to vendor libraries between them.

Phuedx (WMF) (talkcontribs)

Sorry for not getting back to you sooner, @Jdlrobson.


I see purpose of MobileFormatter is to provide content in a well defined format to Minerva.

I think you hit the nail on the head. MobileFormatter and Minerva are coupled. This should be acknowledged. AFAICT the intention here is to both formalize that coupling and loosen it slightly.


The desktop version of Minerva (useformat=desktop&useskin=minerva) doesn't use MobileFormatter at all.

Do we actually support desktop Minerva? I see your point but I'm not sure whether to accept your premise.


Can you expand on Vendoring libraries on a per-extension basis is hard?

Now that you've done work on this project, I see that your intention wasn't to vendor MobileFormatter and make MobileFrontend depend on it. My comment isn't relevant.

Reply to "Missing "Why is it helpful to have them in the same repository..." section"
Niedzielski (talkcontribs)

Is there a workboard or tag for this effort? Would it be helpful to make a spike to perform an initial audit of tasks or would it be easier to start with something concrete like breaking out the Nearby functionality into a separate extension?

Jdlrobson (talkcontribs)

No workboard, just an epic - https://phabricator.wikimedia.org/T71366

Right now the epic is marked as low priority and I'm trying to discourage fleshing out tasks prematurely until we decide to work on them.

I've been doing a spike of sorts in https://gerrit.wikimedia.org/r/#/c/347768/ to work out exactly what needs to be done to create a Minerva skin that depends on the MobileFrontend extension if you are interested in getting involved.

Reply to "Tasking"

Low cost for Minerva as a desktop skin?

1
Phuedx (WMF) (talkcontribs)

Is having few bugs relating to Minerva as a desktop skin really an indicator that it's low cost? It may be indicative of a small user base or our messaging that "desktop mode" isn't really supported.

Reply to "Low cost for Minerva as a desktop skin?"
ABaso (WMF) (talkcontribs)

Nice write up. One thing that struck me was the notion of the Minerva skin being distinct on Wikimedia hosted properties as opposed to third parties. The branding on Wikimedia properties now is sufficiently distinct, so maybe it's a moot point, but might there be an opportunity to have something, such as a distinctive third party color palette (that's still a11y friendly), to distinguish separate installations?

Reply to "Nice write up"
There are no older topics