@JScherer-WMF do we have design specs beyond the prototype?

@SherryYang-WMF When creating tickets, please add basic information which codebase a ticket is about, by adding codebase project tags. Thanks.

Change #1315973 had a related patch set uploaded (by Marco Fossati; author: Marco Fossati):

[mediawiki/skins/MinervaNeue@master] Minimal Minerva: truncate lead sections

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

Implementations notes, CC @JScherer-WMF :

• a lead section can have a mix of text, templates, images, etc. Hence, truncation based on lines of text isn't directly applicable. I've opted for a pixel-based threshold, and tried to approximately measure the textual content's height
• the prototype's fade container height is 72 px. I suggest to increase it, since it was barely visible in my local tests.

Filed a follow-up ticket T433271: Truncation: "read more" button accessibility check

Change #1315973 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Minimal Minerva: truncate lead sections

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

Change #1319055 had a related patch set uploaded (by Marco Fossati; author: Marco Fossati):

[mediawiki/extensions/ReaderExperiments@master] Minimal Minerva: enable via URL parameter

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

Change #1319055 merged by jenkins-bot:

[mediawiki/extensions/ReaderExperiments@master] Minimal Minerva: enable via URL parameter

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

Increased the fade container to 84px in the spec @mfossati, lemme know if that helps the issue you encountered.

Re: height vs. word vs. char count: the proportion of the lead getting truncated would change based on the font size, too, which can change based on browser, device, and prefs if we use height as the cutoff mechanism.
~300 words and ~550 chars for languages like Japanese and Korean where spaces don't determine word boundaries ended up working alright in the prototype. I'm ok with either approach, whichever you think is cleaner to implement and QA. I suspect we'll end up truncating more if we go with height and the same article will get truncated in a different spot depending on the device it's being viewed on. I doubt casual readers would notice the inconsistencies, though.

Re: how many articles are going to be impacted, I did a quick analysis with a Claude script based on word/char counts.
tl;dr: roughly 50% of leads will get truncated on the top 200 most viewed articles on top-20 wikis, ~3% on a random sample of 200 articles.

• Here's the code
• Here's the findings:

Open question: how will our instrumentation take into consideration whether or not a reader sees a truncated lead or not?

Even though we're truncating a lot of leads, the pagination button is still pretty far down the page, so even on articles where people could see "read more" they probably won't in a lot of cases.

In T432187#12172775, @Etonkovidova wrote:

There is no fading

Yeah it's barely visible, tracked in T433583: [Truncation] Increase fade container height.

and the whole text of the leading section is not displayed.

Not sure what you mean here.

Also, banners, such currently the especially long one, would be counted toward the display limit (https://en.wikipedia.org/wiki/Elizabeth_II)?

No, unless a banner lives within the lead section's HTML.

(2) "Read more" font-size looks smaller than in the design. Design specs call for "large", on beta the font-size is default - 16px.

Filed T433674: [Truncation] Increase expand button's font size.

@JScherer-WMF I've filed two follow-up tasks, will let you sign this off after a decision on this point:

3. "Quick facts" on apps - from the task description :"infoboxes collapsed as a Quick Facts section, similar to apps" - the apps collapse the infoboxes not at the end of the leading section, but right in where an infobox is placed in mobile view

In T432187#12173818, @mfossati wrote:

In T432187#12172775, @Etonkovidova wrote:

and the whole text of the leading section is not displayed.

Not sure what you mean here.

Yes, it wasn't clear, and, probably, it's not relevant to mention when there is no infobox collapsing. What I meant - now on beta with no infobox collapsing, "Read more" hides the whole leading section, displaying only part of an infobox.

Also, banners, such currently the especially long one, would be counted toward the display limit (https://en.wikipedia.org/wiki/Elizabeth_II)?

No, unless a banner lives within the lead section's HTML.

Right, banners shouldn't be a problem then.

In T432187#12173840, @mfossati wrote:

@JScherer-WMF I've filed two follow-up tasks, will let you sign this off after a decision on this point:

3. "Quick facts" on apps - from the task description :"infoboxes collapsed as a Quick Facts section, similar to apps" - the apps collapse the infoboxes not at the end of the leading section, but right in where an infobox is placed in mobile view

Sorry for the confusion. We don't want the same positioning as the apps. The infobox should be collapsed as an H2 below the entire lead section.

Can't sign this off because it looks like it's not possible to QA the 30 lines logic without having already built the infobox collapse behaviour. @Etonkovidova Did you try articles with long leads and no infobox? That might make it easier to QA. Are we goign to QA that elsewhere? If so, I'll sign off. If not, then I'll leave this open until we can QA it.

In T432187#12187120, @JScherer-WMF wrote:

@Etonkovidova Did you try articles with long leads and no infobox? (...) Are we goign to QA that elsewhere? If so, I'll sign off

I think we'll do another round of QA as part of T432752: [Truncation] Collapse infoboxes into a Quick Facts section's lifecycle.