Page MenuHomePhabricator

MoveLeadParagraphTransformInfobox should be rewritten to be more similar to mobile apps
Open, MediumPublic3 Estimated Story Points

Description

The approach in MobileFrontend looks for a paragraph and an infobox (where infobox now includes block images since T258201), and switches them around. This approach requires us to list the likely types of block elements that could come before a paragraph, and our current filter of class=infobox|thumb is not exhaustive. Many images are wrapped in various containers (T261993) and there are other types of block elements we would want to move down.

The approach in mobile apps[1][2] just moves the lead paragraph (and all siblings up to the next paragraph) to the top of the page, regardless of what is above it. It then only has to detect templates at the top of the page which should stay at the top, currently this is just class=hatnote. For MF we should probably also include class=mbox and others we are aware of (mboxes are just hidden in mobile apps, hence not included in their code).

  1. https://github.com/wikimedia/mobileapps/blob/e858d09962aa9c0e9a0b04bdbed36c18f973aeb5/lib/mobile/MobileHTML.js
  2. https://github.com/wikimedia/mobileapps/blob/43c2b2f66641ebf58a0cc1ebf885e361f0ea68f0/pagelib/src/transform/LeadIntroductionTransform.js

QA

For as many pages in the list of candidate pages below:

  1. Visit the page on enwiki and on this patchdemo
  2. Check that the lead paragraph remains at the top of the page or that it has moved to the top of the page
  3. On https://it.m.wikipedia.org/wiki/Organo_a_pompa there are two hat notes, one with the hatnote class and the other an ambox. Both templates are using TemplateStyles which could be related. Make sure the hatnotes are hoisted.

List of candidate pages

QA Results - Beta

ACStatusDetails
1T262093#6896451

Event Timeline

Change 625346 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/MobileFrontend@master] Rewite MoveLeadParagraphTransform based on mobile apps approach

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

This patch should fix the long tail of floated items that are not identifiable as infoboxes or images, for example https://en.wikipedia.org/wiki/Edinburgh_and_Dalkeith_Railway

Jdlrobson added a project: Readers-Web-Backlog.

The patch potentially makes sense (I'm not sure why the logic in apps and web is different) but I don't think the team can commit the necessary attention and focus to this right now unless it's blocking something from the editing side. It certainly will not aid desktop refresh.

Leaving with Olga for prioritization.

This comment was removed by Chrisahn.

I wrote a script that compares the transform in the master branch with the one in @Esanders patch. The script loads the content of the article on my development wiki using the MwApiContentProvider content provider with the specified transform applied and then takes a screenshot. When screenshots of both versions of the article have been taken, the script then computes a diff as well.

Title@revidmaster625346Difference
Tone letter@975330311
Al Messila (Doha)@966542034
Proceedings of the Royal Irish Academy@958366725
Al Jihad fil Islam@973512057

I also configured the script to do the same for the top 10 most viewed articles in August (see https://pageviews.toolforge.org/topviews/?project=en.wikipedia.org&platform=all-access&date=last-month&excludes=) and saw no discernible difference in output.

I'd welcome recommendations for settings for my development wiki to tweak and/or articles to test with the script.

Jdlrobson set the point value for this task to 5.Mar 2 2021, 6:12 PM

Estimated at medium risk.

Jdlrobson changed the point value for this task from 5 to 3.Mar 2 2021, 6:15 PM

(medium is 3 apparently)

ovasileva triaged this task as Medium priority.Mar 3 2021, 4:26 PM

Change 625346 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Rewite MoveLeadParagraphTransform based on mobile apps approach

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

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: macOS Big Sur
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

✅ AC1: For the pages below verify that the lead paragraph is at the top of the page

Hooded SkunkAlbert EinsteinRonald ReaganAleš_Kněžínek
Daimona added a subscriber: Daimona.

Please see T277302 for a regression introduced by this change. I really wish that more wikis were used for testing changes like this one, and not just enwiki.

I will write a notice for T/N later if nobody beats me to it.

Change 672406 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/MobileFrontend@master] Reinstate "Rewite MoveLeadParagraphTransform based on mobile apps approach"

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

First of all, I've created the reverts on gerrit, so whenever this is ready to go it's just a CR+2 button to push.

As for Tech News (CC @Johan ?):

In two (?) weeks, there will be a change to how articles are displayed on mobile sites. The first paragraph of the article will be moved above the infobox templates. Some templates, like [[:en:Template:Hatnote|]] and derivatives of [[:en:Template:Ambox]] on the English Wikipedia, should stay at the top of the page. To make this work, ensure that the equivalent templates on your wiki are using the CSS class <code>hatnote</code> or <code>ambox</code>. A [https://w.wiki/35ur guide] is available. See [[:phab:T262093|]] for more.

It's probably unnecessary wordy, so it might need some trimming.

This has been reverted because of the new information provided in T277302.

I think we have a few options here

  • Run a tech news post and reapply the change again in X days.
  • Adjust the algorithm for the new edge cases and try again.
  • Turn off the lead paragraph move feature on the impacted wikis (using the existing MFShowFirstParagraphBeforeInfobox config flag) . This could result in infoboxes at the top of the page but could be enabled later once the required mark up changes are there leaving it up to editors to opt into this
  • Adjust the existing code to make classes like hatnote and infobox configurable, to allow editors to customize these special classes to their own understood language. e.g. instead of .hatnote the MobileFrontend code could be configured to look for .nota-disambigua

Discussed this yesterday during standup. Tentative next steps:

  • Begin discussions with the community about the change - inform everyone via Tech News as well as reach out to a set of wikis directly to discuss preparation
  • Create a list of wikis where this would break and exclude them from the changes
  • Make a list of wikis that absolutely must be fixed

Once the above is in progress, we can set a date on when we would like to try this out again

Something like this for Tech News? Or do you need the editors or wikis to take any other action beyond making sure they use the right CSS class?

Articles on mobile will look different. The first paragraph will come before the infobox templates. Some templates will stay on top of the page. Two examples are [[<tvar|hatnote>:wikidata:Q5625128</>|Template:Hatnote]] or [[<tvar|ambox>:wikidata:Q5617634 | Template:Ambox ]]. They will need to use the CSS class <code>hatnote</code> or <code>ambox</code> on your wiki for this to work. You can [[<tvar|guide>:mw:Recommendations for mobile friendly articles on Wikimedia wikis#Use standardized class names in HTML markup for components in templates across projects</>|see a guide]] or [[<tvar|mobilephab>phab:T262093</> | read more]].

This assumes that the class names will remain like this, with all the styling issues that have been pointed out already. As already explained, I would have to use hatnote both for disambiguation notes and for message boxes on dewiki due to incompatibilities of the ambox class, which would not be in line with the logic of the linked recommendations.

So, before communicating anything about this, either the guide should be updated or the class names should be made customisable.

Do one thing, and do it well.

  • Please use a class mw-page-position-top.
  • That does say: This block shall be arranged before introduction section.
  • Nothing more.

Those local ambox and hatnote and infobox are decoration classes. They define how this particular wiki is decorating things. That is not a statement on the exact position where to arrange it in a page.

  • Structural global semantics are one thing.
  • Local decoration is something different.

The ambox and hatnote are providing a particular decoration. They were never limited to certain structural declaration and effect on order of elements. Those are definitely the wrong class names to introduce a new capability. Nobody knows which templates in 1000 WMF wikis are equipped with such classes and which expectation and usage are supposed there.

Something like this for Tech News? Or do you need the editors or wikis to take any other action beyond making sure they use the right CSS class?

Articles on mobile will look different. The first paragraph will come before the infobox templates. Some templates will stay on top of the page. Two examples are [[<tvar|hatnote>:wikidata:Q5625128</>|Template:Hatnote]] or [[<tvar|ambox>:wikidata:Q5617634 | Template:Ambox ]]. They will need to use the CSS class <code>hatnote</code> or <code>ambox</code> on your wiki for this to work. You can [[<tvar|guide>:mw:Recommendations for mobile friendly articles on Wikimedia wikis#Use standardized class names in HTML markup for components in templates across projects</>|see a guide]] or [[<tvar|mobilephab>phab:T262093</> | read more]].

@Johan I'm not sure if the team wants to proceed this way. I wrote a proposal for T/N assuming that the change would be reimplemented in the same way, but this might not be the case if I'm correctly reading the messages above.

Yes, I didn't include it in the issue going out on Monday, awaiting more clarity in this task.

Jdlrobson removed a project: Patch-For-Review.
Jdlrobson added subscribers: olga, Edtadros.

@olga how do we want to proceed with this one?

Change 672406 restored by Esanders:

[mediawiki/extensions/MobileFrontend@master] Reinstate "Rewite MoveLeadParagraphTransform based on mobile apps approach"

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