Page MenuHomePhabricator

Enable collapsible templates (including infoboxes) on mobile
Open, MediumPublic

Assigned To
Authored By
Thnidu
Sep 4 2015, 8:39 PM
Referenced Files
F23285304: expandable-template-mobile.png
Jul 3 2018, 8:58 PM
F8549770: Screen Shot 2017-06-28 at 4.06.29 PM.png
Jun 28 2017, 11:07 PM
F8517080: collapse-table.png
Jun 23 2017, 10:45 PM
F8517084: image.png
Jun 23 2017, 10:45 PM
F8516927: Screen Shot 2017-06-23 at 2.33.49 PM.png
Jun 23 2017, 9:43 PM
F8516928: Screen Shot 2017-06-23 at 2.33.55 PM.png
Jun 23 2017, 9:43 PM
F4596023: Screen Shot 2016-10-12 at 1.47.36 PM.png
Jun 23 2017, 9:29 PM
Tokens
"Piece of Eight" token, awarded by whym.

Description

NOTE: The code that provides collapsible content currently resides in mediawiki.page.ready which also provides functionality for sortable tables which is captured in the sister task T233340

Problem

On the desktop, Same-sex marriage in Kentucky (and other US states) looks fine. Template:Same-sex unions runs down the right-hand side of the page, taking only about one-third of the width available for text (on my laptop at a size comfortable for my old eyes), and only its first section, Marriage, is expanded; the other three, Civil unions and registered partnerships, Unregistered cohabitation, and See also, are initially collapsed, with a "[Show]" button.

On my smartphone,* though, the template comes up fully expanded at almost the very top of the page, with only the title and the lead graphic above it. I have to scroll five full screens to reach the first line of text. Need I say how awkward this is? especially with the risk of tapping a link as I tap-scroll down.


* Samsung Verizon Android Galaxy S-3, model SCH-I535, OS v4.4.2

Infoboxes

On desktop, if an article has multiple infoboxes, we collapse each subsequent infobox after the first:

Screen Shot 2016-10-12 at 1.47.36 PM.png (569×1 px, 147 KB)

We don't do this on mobile and it takes up a lot of space
https://en.m.wikipedia.org/wiki/California

Plan

MinervaNeue should

  • Load mediawiki.page.ready /Users/jrobson/git/core/resources/src/mediawiki/page/ready.js
  • Provide styling (see Design) for collapsing as a skinStyle for the jquery.makeCollapsible module

Design

expandable-template-mobile.png (667×375 px, 114 KB)

  • bg color remains the same #f8f9fa
  • icon is a small version of mw-ui-icon-mf-arrow (same as toggle) but in blue color. (see related T198770)
  • "Show more" button is 14px, blue, normal weight. Note, that the text of the button comes from editors so don't worry about the copy text here. We cannot change it.

Acceptance criteria

  • Update SkinMinerva::getDefaultModules to include jquery.makeCollapsible when requested - see https://gerrit.wikimedia.org/r/431662 POC: Enable collapsible elements on Minerva is a proof of concept.)
  • Add new styles for Minerva, ensuring they do not cause FOUC when loaded and collapsed elements begin collapsed.
  • This is used in various ways by editors (see T199924: Hidden images in vector arwiki display in Minerva) some community outreach/testing as part of deployment would be advisable.
  • Enable the config option inside the PageReady hook

Developer notes

https://gerrit.wikimedia.org/r/431662 POC: Enable collapsible elements on Minerva is a proof of concept.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson renamed this task from Enable mediawiki.page.ready on Minerva (collapsible templates (including infoboxes) and sortable tables) to Enable collapsible templates (including infoboxes) on mobile.Mar 18 2020, 12:07 AM
Jdlrobson updated the task description. (Show Details)

Why don't we use summary tag to make collapsable element?. It's HTML5 built-in feature, and supported by all browsers. And the good thing about it that this tag doesn't need Javascript to work.

Why don't we use summary tag to make collapsable element?. It's HTML5 built-in feature, and supported by all browsers.

When it comes to IE/Edge, I think only Edge from this year (version 79–) supports the summary-tag, and according to the included link, it doesn't work with screen readers. So, it doesn't really seem to be a viable option.

@ASammour it's a really good idea but since infoboxes are defined in templates such an idea would have to happen inside a template. The summary tag can be used in older browsers and will render fine in IE11 - it just won't be collapsible which IMO is acceptable.

However it looks like the parser doesn't support summary and details elements. We'd need to add that first by requesting it at MediaWiki-Parser

https://caniuse.com/#search=summary

However it looks like the parser doesn't support summary and details elements. We'd need to add that first by requesting it at MediaWiki-Parser

T31118: Add HTML 5 semantic elements 'details' and 'summary' to Sanitizer whitelist

I fixed this in Bawl (for the whole page) and the same code is part of EditNoticesOnMobile (T312299) for edit notices. Just search the source for "T111565". It's really nothing spectacular.

It works and I haven't heard any complaints yet.

Aklapper removed subscribers: pmiazga, Tfinc, Nirzar.

Removing task assignee due to inactivity as this open task has been assigned for more than two years. See the email sent to the task assignee on August 22nd, 2022.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome!
If this task has been resolved in the meantime, or should not be worked on ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

Change 859605 had a related patch set uploaded (by Jdlrobson; author: Bartosz Dziewoński):

[mediawiki/skins/MinervaNeue@master] Allow collapsible content in Minerva

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

Change 859605 abandoned by Bartosz Dziewoński:

[mediawiki/skins/MinervaNeue@master] Allow collapsible content in Minerva

Reason:

I will submit a specific patch for T323639 (collapsible mobile talk page banners), since everyone else wants a more complex solution for T111565 (collapsible content on mobile in general).

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

Hi! What's the status of this task now? Some time ago ResourceLoader modules became targetted at desktop,mobile by default and it appears that running the following line in the browser console on a mobile version works as intended:

mw.loader.using('jquery.makeCollapsible').then(() => $('.mw-collapsible').makeCollapsible());

Tested at: https://m.mediawiki.org/wiki/Manual:Collapsible_elements/Demo/Advanced

Hi! What's the status of this task now? Some time ago ResourceLoader modules became targetted at desktop,mobile by default and it appears that running the following line in the browser console on a mobile version works as intended:

mw.loader.using('jquery.makeCollapsible').then(() => $('.mw-collapsible').makeCollapsible());

Tested at: https://m.mediawiki.org/wiki/Manual:Collapsible_elements/Demo/Advanced

That's about the same solution I deployed in Factotum (formerly known as Bawl) which can apply this universally and EditNoticesOnMobile which applies it only within edit notices. See my earlier comment here: T111565#8076831.

I can't find the relevant comment, but this is deemed to be an insufficient UX on touchscreens by the WMF devs.

I can't find the relevant comment, but this is deemed to be an insufficient UX on touchscreens by the WMF devs.

You're probably looking for the patch commentary in https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/859605/ . It's the only place I've seen an objection along this line in recent times.

TBH I'm in the party of "the perfect is currently being the enemy of the good" regarding allowing things to be collapsed. I get the concern regarding button size, but OTOH I don't see it as major enough to block the enhancement that collapsing things brings.

I can't find the relevant comment, but this is deemed to be an insufficient UX on touchscreens by the WMF devs.

You're probably looking for the patch commentary in https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/859605/ . It's the only place I've seen an objection along this line in recent times.

TBH I'm in the party of "the perfect is currently being the enemy of the good" regarding allowing things to be collapsed. I get the concern regarding button size, but OTOH I don't see it as major enough to block the enhancement that collapsing things brings.

Thanks, that's what I was referring to. To quote from the comments: "But the issue is the fat finger problem – the [show] links are not that big, so pressing them may be challenging."

I don't use touch devices extensively to browse the web (I need a physical keyboard) so it's harder for me to judge, but if someone's fingers are so fat they can't click an "Expand" link, they can't click any link really, right? So they have bigger problems.

Outside of that, some CSS could help to make the links wider, especially if the words "Show"/"Expand"/"Collapse"/"Hide" are very short in any particular language. Say (just paste in your browser console to test),

mw.util.addCSS('.skin-minerva button.mw-collapsible-toggle{min-width:8em}')

As there are people opposed to making this change in MediaWiki core, I would suggest doing it in your wiki's MediaWiki:Common.js or a gadget, as long as your community finds that agreeable.

As there are people opposed to making this change in MediaWiki core, I would suggest doing it in your wiki's MediaWiki:Common.js or a gadget, as long as your community finds that agreeable.

Good idea. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#RfC:_Enabling_collapsible_templates_on_the_mobile_site

It's worth noting that mobile MediaWiki already supports collapsible class, which is almost the same as mw-collapsible in appearance.

It's worth noting that mobile MediaWiki already supports collapsible class, which is almost the same as mw-collapsible in appearance.

That doesn't work for me. I don't think it's a MediaWiki feature, but it's a fairly common on-wiki customization (older than mw-collapsible).

It's worth noting that mobile MediaWiki already supports collapsible class, which is almost the same as mw-collapsible in appearance.

That doesn't work for me. I don't think it's a MediaWiki feature, but it's a fairly common on-wiki customization (older than mw-collapsible).

Ah, appears that you're right. I must have missed the on-wiki code that supports it.

It's worth noting that mobile MediaWiki already supports collapsible class, which is almost the same as mw-collapsible in appearance.

That doesn't work for me. I don't think it's a MediaWiki feature, but it's a fairly common on-wiki customization (older than mw-collapsible).

Ah, appears that you're right. I must have missed the on-wiki code that supports it.

On English Wikipedia it's part of https://en.wikipedia.org/wiki/MediaWiki:Common.js but Common.js doesn't load on mobile.

Curiously, plwiki (which appears to be your home wiki?) has https://pl.wikipedia.org/wiki/MediaWiki:Mobile.js to enable collapsible elements on mobile. While shorter, it's less efficient than the gadget proposed on enwiki and won't work when the page content is refreshed e.g. after editing a page.

[edit]
Oh, you created that page! I'd actually suggest you install https://en.wikipedia.org/wiki/Wikipedia:MakeMobileCollapsible#Installation_on_other_projects as it's more efficient than loading the module unconditionally on every page load.

It's worth noting that mobile MediaWiki already supports collapsible class, which is almost the same as mw-collapsible in appearance.

That doesn't work for me. I don't think it's a MediaWiki feature, but it's a fairly common on-wiki customization (older than mw-collapsible).

Ah, appears that you're right. I must have missed the on-wiki code that supports it.

On English Wikipedia it's part of https://en.wikipedia.org/wiki/MediaWiki:Common.js but Common.js doesn't load on mobile.

Curiously, plwiki (which appears to be your home wiki?) has https://pl.wikipedia.org/wiki/MediaWiki:Mobile.js to enable collapsible elements on mobile. While shorter, it's less efficient than the gadget proposed on enwiki and won't work when the page content is refreshed e.g. after editing a page.

[edit]
Oh, you created that page! I'd actually suggest you install https://en.wikipedia.org/wiki/Wikipedia:MakeMobileCollapsible#Installation_on_other_projects as it's more efficient than loading the module unconditionally on every page load.

The table.collapsible is supported in the same gadget as NavFrame on pl.wiki :). I've made the code a bit more modern and also added a11y (WCAG) recently.

It's a drop-in replacement for old NavFrame. So you can copy it to en.wiki (or any other wiki). A translation of labels is required:

var collapseCaption = "ukryj";
var expandCaption = "pokaż";

https://pl.wikipedia.org/wiki/MediaWiki:Gadget-NavFrame.js

The definition:

NavFrame [ResourceLoader | hidden | targets=desktop,mobile | default] | NavFrame.js | NavFrame.css

(Given how few uses of NavFrame pl.wp has [around 600 ], I'd be happy to make it so you don't need that default loading anymore ;).)

@Izno Actually NavFrame is used on all year pages for collapsing navigation in a nice and more accessible way (both for sighted users and for users using screen readers and for mobile UX). But if you think you can do it with the default then we can discuss that. We can discuss that on WP:BAR:TE or on the template's page. In general default collapsing is visibly slower to load though.

As there are people opposed to making this change in MediaWiki core, I would suggest doing it in your wiki's MediaWiki:Common.js or a gadget, as long as your community finds that agreeable.

What exactly is the opposition here? Who is opposed to making this change (I can't see anything about this in the ticket).

My understanding of this ticket is nobody is prioritizing this work, the work is challenging and that's the only problem here.
(see mocks

collapse-table.png (1×750 px, 179 KB)
)

Why are we encouraging the creation of a gadget which would just be technical debt for that project and instead not encouraging someone to attempt to satisfy the good ideas in this ticket?

What exactly is the opposition here? Who is opposed to making this change (I can't see anything about this in the ticket).

T111565#9135498 points to the relevant gerrit patch review of which you were a part. I would be as happy as anyone to have it loaded 'natively', but until someone prioritizes doing so, a gadget it is. (Speaking of which, we're planning to roll that out to all mobile users Soon after the briefest of brief trials with registered users. Better hang on to your hats.)

What exactly is the opposition here? Who is opposed to making this change (I can't see anything about this in the ticket).

T111565#9135498 points to the relevant gerrit patch review of which you were a part. I would be as happy as anyone to have it loaded 'natively', but until someone prioritizes doing so, a gadget it is. (Speaking of which, we're planning to roll that out to all mobile users Soon after the briefest of brief trials with registered users. Better hang on to your hats.)

Right but the patch didn't pose opposition - it just recognized that the fat finger concern is a problem and is hard to solve.

(Speaking of which, we're planning to roll that out to all mobile users Soon after the briefest of brief trials with registered users. Better hang on to your hats.)

It doesn't look like the gadget addresses the fat finger concern so I'm not sure why we intentionally want to roll out a bad experience to end users? If you want to go down the path, why not just introduce a feature flag to the relevant line of code on https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/859605/2/includes/Hooks.php configurable and make this a config change ? Why ship a gadget that could break further down the line when someone fixes this properly?

As there are people opposed to making this change in MediaWiki core, I would suggest doing it in your wiki's MediaWiki:Common.js or a gadget, as long as your community finds that agreeable.

What exactly is the opposition here? Who is opposed to making this change (I can't see anything about this in the ticket).

My understanding of this ticket is nobody is prioritizing this work, the work is challenging and that's the only problem here.

In gadget/userscript form I made ColMask which is yet another take. Code is a bit messy though and it's JS on top of jquery.makeCollapsible. It does address the fat finger problem though, the whole collapsed object can be clicked to expand it and it uses buttons.

What exactly is the opposition here? Who is opposed to making this change (I can't see anything about this in the ticket).

T111565#9135498 points to the relevant gerrit patch review of which you were a part. I would be as happy as anyone to have it loaded 'natively', but until someone prioritizes doing so, a gadget it is. (Speaking of which, we're planning to roll that out to all mobile users Soon after the briefest of brief trials with registered users. Better hang on to your hats.)

Right but the patch didn't pose opposition - it just recognized that the fat finger concern is a problem and is hard to solve.

(Speaking of which, we're planning to roll that out to all mobile users Soon after the briefest of brief trials with registered users. Better hang on to your hats.)

It doesn't look like the gadget addresses the fat finger concern so I'm not sure why we intentionally want to roll out a bad experience to end users?

It partially does. It enforces a link width of 6em, so links with short labels are never super tiny.

If you want to go down the path, why not just introduce a feature flag to the relevant line of code on https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/859605/2/includes/Hooks.php configurable and make this a config change ? Why ship a gadget that could break further down the line when someone fixes this properly?

Because

Reason 1: No environment

Because I don't have the environment set up nor the knowledge to create/file a patch you can process. It's been suggested to me before by matmarex as they cited a problem is often to find reviewers, so if someone else filed a patch for something they could review it. I'm sure I could figure all that out, but I generally focus on whatever interests me most and which I suspect will bring me the least frustration. I'm not paid, so frustration is a hard pass.

I guess if someone would be willing to pay $100 and link a guide they know is up-to-date and won't result in dependency hell (or answer questions for an outdated guide personally) I'd do it. But I wouldn't expect anyone to pay that, and I dislike frustration, so that's why.

Reason 2: Rusty

Last time I wrote more than one line of PHP was probably more than 10 years ago. Made my own weblog software, it had one user besides myself! :-D But I learn quickly so I could probably figure this out. Any actual programming isn't as frustrating for me.

Reason 3: Unlikely to break

Nothing is likely to break, the gadget just loads jquery.makeCollapsible.

I support @AlexisJazz in this. This is not their problem, not the communities problem. This is exactly what gadgets are for. A lot of the functionality that is now in core started out as a gadget and was used like that until Core developers got around to adopting the code. As it seems that there are few people willing to adopt code like this, this seems like the proper way forward.