Page MenuHomePhabricator

Update Minerva to include footer banners
Open, In Progress, MediumPublic1 Estimated Story Points

Assigned To
Authored By
cmadeo
Aug 23 2024, 3:58 PM
Referenced Files
F58268328: Screenshot 2025-01-24 at 11.54.03 AM.png
Fri, Jan 24, 10:27 PM
F58268312: Screenshot 2025-01-24 at 11.50.32 AM.png
Fri, Jan 24, 10:27 PM
F58268153: Screenshot 2025-01-24 at 11.22.45 AM.png
Fri, Jan 24, 7:23 PM
F58268138: Screenshot 2025-01-24 at 11.20.05 AM.png
Fri, Jan 24, 7:23 PM
F58268135: Screenshot 2025-01-24 at 11.19.44 AM.png
Fri, Jan 24, 7:23 PM
F58268112: Screenshot 2025-01-24 at 11.15.52 AM.png
Fri, Jan 24, 7:23 PM
F58259660: Screenshot 2025-01-23 at 8.52.31 AM.png
Thu, Jan 23, 4:54 PM
F58259655: Screenshot 2025-01-23 at 8.51.17 AM.png
Thu, Jan 23, 4:54 PM
Tokens
"Love" token, awarded by stjn."Love" token, awarded by Ladsgroup.

Description

NOTE: T384619 must be completed before taking on this ticket.

Background

@Ladsgroup + @JScherer-WMF were able to update Vector to include new banner footers, a follow-up task from this work would be to ensure that the footer in Minerva is also updated to include footer banners.

User story

As a reader visiting the mobile site, it should be clear from the footer that I am on a Wikimedia site powered by MediaWiki.

Requirements

  • Two icons show in the footer on mobile
  • The icons are different depending on the screen resolution

BDD

  • For QA engineer to fill out

Test Steps

  • For QA engineer to fill out

Design

Current implementation on VectorCurrent state on Minerva
Screenshot 2024-08-23 at 11.02.53 AM.png (782×3 px, 232 KB)
Screenshot 2024-08-23 at 11.03.06 AM.png (1×1 px, 174 KB)

Designs:

The same icons as on Vector, but scaled down slightly to make sense for mobile.

image.png (1×1 px, 183 KB)

Alt:

image.png (1×1 px, 166 KB)

Acceptance criteria

  • SkinComponentFooter::getFooterIconsData is updated to generate a picture element which supports different images at different resolutions
  • Minerva is updated to read from the data-icons field and render t

( https://en.m.wikipedia.org/wiki/Main_Page?useskin=json )

Enable the icons using the following code:

$wgFooterIcons['copyright']['copyright'] = [
	'url' => 'https://wikimediafoundation.org/',
	'src' => 'https://en.wikipedia.org/static/images/footer/wikimedia-button.svg',
        'src-mobile' => 'https://en.wikipedia.org/static/images/mobile/wikimedia.png',
	'width' => 84,
	'height' => 29,
	'alt' => 'Wikimedia Foundation',
];

Communication criteria - does this need an announcement or discussion?

  • Add communication criteria

Rollback plan

  • What is the rollback plan in production for this task if something goes wrong?

This task was created by Version 1.2.0 of the Web team task template using phabulous

Event Timeline

To be clear:
Is the ask here to add those 2 image icons in the bottom right of Vector to Minerva?

Justin: could you add some mocks of the desired Minerva treatment here?

To be clear:
Is the ask here to add those 2 image icons in the bottom right of Vector to Minerva?

I requested this change. In my head it can be any change in the footer that incorporates wikimedia and (to lesser extent mediawiki) branding. It can be similar to desktop. Use the image or anything else that designers deem fit. So not necessarily the images.

Jdlrobson triaged this task as Medium priority.Dec 11 2024, 6:24 PM
SToyofuku-WMF changed the task status from Open to In Progress.Dec 11 2024, 7:09 PM
SToyofuku-WMF subscribed.

pending estimate

Jdlrobson changed the task status from In Progress to Open.Mon, Jan 13, 6:40 PM
Jdlrobson-WMF changed the task status from Open to In Progress.EditedTue, Jan 21, 6:12 PM
Jdlrobson-WMF subscribed.

Tagging as potential candidate for next sprint since community has asked for it. Justin to add mocks.

@Ladsgroup given the icon is different for different resolutions, I think this will require an architectural change. We either need to:

  • Update the existing icons so the text portion and icon are separate and we can easily hide the text portion with CSS
  • Use a picture tag to display different images based on resolution. e.g.
<picture>
  <source media="(max-width: 720px)" srcset="/w/resources/assets/compact.svg" />
  <img src="/w/resources/assets/poweredby_mediawiki.svg" alt="Powered by MediaWiki" width="88" height="31" loading="lazy">
</picture>

I'm leaning towards the latter. Thoughts?

One note about the mocks:

Regarding which way, in the long term, I would like to split the text out of the image so it can be translated but also then you need to make the font works and style it properly and all that jazz. So it's a much more long term. but how to display it differently for now, I'm honestly that good in front-end to say which direction is better, as long as it's lazy loaded, it shouldn't cause any performance degradation.

I'll aim to put a proof of concept together Friday.

One note about the mocks:

Regarding which way, in the long term, I would like to split the text out of the image so it can be translated but also then you need to make the font works and style it properly and all that jazz. So it's a much more long term. but how to display it differently for now, I'm honestly that good in front-end to say which direction is better, as long as it's lazy loaded, it shouldn't cause any performance degradation.

thanks for the catch on petal sizes! I'll update mocks accordingly.

Small MW flower icon
WMF Logo

Worth noting: The design uses neutral-normal button variants from Codex to implement this. that's where the styling on the container around the buttons comes from.

@Ladsgroup given the icon is different for different resolutions, I think this will require an architectural change.

Can you clarify what’s the benefit for doing a more over-engineered solution? Is it just because the buttons would look too big on mobile or something? I feel like footer is one place where you can get away with it. Like, on a related topic, I never got why footer links differ between mobile website and desktop one. If a link is important enough for desktop version, it should be important enough on mobile as well.

Also, to bring up a more important point: currently those banner images are put last on desktop but second to last on mobile. I feel like the order on desktop is right and mobile should match it if this change is implemented.

Like, on a related topic, I never got why footer links differ between mobile website and desktop one. If a link is important enough for desktop version, it should be important enough on mobile as well.

This also prevents people from adding their own links to the footer, which some scripts do (including my own https://www.mediawiki.org/wiki/Translator_Buddy which I have to fix now since mw.util.addPortletLink does not add anything on Minerva). (Update: ah, no, that is instead because Minerva CSS hides most of the links via CSS and any user-generated links get hidden, too.)

Jdlrobson-WMF set the point value for this task to 1.

Change #1113825 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/MinervaNeue@master] POC: Add icons to Minerva footer

https://gerrit.wikimedia.org/r/1113825

Change #1113827 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] [POC]: Skins support responsive footer icons

https://gerrit.wikimedia.org/r/1113827

iPhone with and without compact buttons:

Screenshot 2025-01-23 at 8.50.25 AM.png (1×796 px, 137 KB)

Screenshot 2025-01-23 at 8.51.17 AM.png (1×784 px, 132 KB)

(If not using compact icons we'd need to push these buttons onto new lines like so:

Screenshot 2025-01-23 at 8.52.31 AM.png (1×772 px, 125 KB)

I can confirm in all variants the images would be lazy loaded.

There may be third parties who have more than two buttons here but I think that should be out of scope given MediaWiki:Minerva.css exists for exactly this purpose.

Sad to see that instead of something that would work for everyone at no cost, problematic Wikimedia-specific hacks are introduced for no explained reason. Also, mockup still places buttons in the incorrect place, they should not be before more specific site links.

Sad to see that instead of something that would work for everyone at no cost, problematic Wikimedia-specific hacks are introduced for no explained reason. Also, mockup still places buttons in the incorrect place, they should not be before more specific site links.

Thanks for your feedback! Let me look at your points above in a bit more detail and think about whether or not another revision is warranted here.

Thanks @stjn for sharing your concerns. I'm curious if you could share an instance of a site using Minerva where site specific links are currently being utilized and shown, so that @JScherer-WMF and other folks working on this project can find an optimal solution.

Taking a look at WikiIndex as an example (desktop vs mobile/Minerva) I'm noticing that site specific blue links aren't showing up on mobile (same with algorithmist.com + antwiki.org to do some quick browsing on https://www.mediawiki.org/wiki/Sites_using_MediaWiki/en)

This is to say: I'm curious if there are some other changes that need to be made to Minerva to ensure that site specific blue links are respected / shown. I'll admit my ignorance in understanding if the sites shared above overrode any defaults by utilizing custom CSS.


Also to clarify, would your ideal solution to this problem be to have the buttons placed below site specific links? I'll also defer to @Jdlrobson on what is and is not in scope for this particular project.

problematic Wikimedia-specific hacks are introduced for no explained reason.

To be clear, nothing proposed here is Wikimedia-specific. Are we talking about the same things? My interpretation of this task is making the mobile site more consistent with the desktop site (by including the icons which are currently not disabled as in https://c66647917e.catalyst.wmcloud.org/wiki/Main_Page). I think really the question is around visual design and where those buttons go.

As https://c66647917e.catalyst.wmcloud.org/wiki/Main_Page demonstrates the icons cannot be alongside the existing site logo using the existing buttons (on an iPhone we'd have a horizontal scrollbar). The buttons either need to be compacted (which is what T384619 proposes) or moved on to a new line. Currently we only support the latter.

The work proposed in T384619: Update skins to support different logos at different resolutions gives more power to site admins to control this in whichever way they prefer. Personally, I think placing these alongside the existing logo is much cleaner than creating another row below the existing links which I think is what @stjn is proposing:

Screenshot 2025-01-24 at 11.15.52 AM.png (1×748 px, 136 KB)

As someone who often rapidly scrolls to the bottom to switch modes to check something, I'd be concerned that sandwiching links between images might make that link harder to click. I don't want to be accidentally visiting an external site.

Also, mockup still places buttons in the incorrect place, they should not be before more specific site links.

I don't think there is an "incorrect place". There are not any rules here around where they go, we just need to justify the best placement and I defer to the designers on what they think that is :-).

  • On Monobook the icons bookcase the links before and after
    Screenshot 2025-01-24 at 11.19.44 AM.png (150×3 px, 86 KB)
  • On Timeless they are off to the side before the links
    Screenshot 2025-01-24 at 11.20.05 AM.png (220×3 px, 125 KB)
  • On Modern on the left and after
    Screenshot 2025-01-24 at 11.22.45 AM.png (356×1 px, 65 KB)
  • On CologneBlue they don't appear at all

Yes, I am making a judgment based on what Vector currently does which is the latest skin out of ones developed by the WMF (i. e. by more qualified developers). Timeless might’ve put these in HTML because it uses float: right for positioning, not because there was much thought about HTML structure. Monobook is ancient.

As someone who often rapidly scrolls to the bottom to switch modes to check something, I'd be concerned that sandwiching links between images might make that link harder to click. I don't want to be accidentally visiting an external site.

I feel like this is solved by having clearer separation (margins etc.) between those image links and non-image links, not by putting less important links above more important ones in DOM tree. Given that one of the solutions is to develop a whole new config to make them smaller, it seems like it is recognised that they are less important to the footer. Despite that, from accessibility standpoint, they would be higher than links to terms of use and the like. Moreover, it is just simpler than developing what seems like a very specific solution that would only be used in Minerva. Those image links are already compact, whether they need compact versions is debatable.

Moreover, it is just simpler than developing what seems like a very specific solution that would only be used in Minerva.

Small misunderstanding here. T384619 would not be only used in Minerva. It would apply to all skins consistently at lower resolutions. Check out the patches carefully if you want to understand what is being proposed. The patch is also relatively simple. I suspect if we went ahead with that we'd be able to DRY up a lot of the code, as we already have images using srcset in places outside the footer.

Currently:

Screenshot 2025-01-24 at 11.50.32 AM.png (658×726 px, 128 KB)

After:
Screenshot 2025-01-24 at 11.54.03 AM.png (640×734 px, 128 KB)

Slightly related, slightly unrelated. I'd really want to change the footer link to wikimedia.org before adding the footers to mobile but it requires some changes being applied. Including this really straightforward patch: https://gerrit.wikimedia.org/r/1113078 Can someone help review that please?

Slightly related, slightly unrelated. I'd really want to change the footer link to wikimedia.org before adding the footers to mobile but it requires some changes being applied. Including this really straightforward patch: https://gerrit.wikimedia.org/r/1113078 Can someone help review that please?

Deployed now. Feel free to switch the links.

Let me know if I can help to move this forward since wikimedia.org is in a good enough shape to replace the footer link and I want to bundle that change with this change.