Yeah, the latter point I thought about as well. So, I would summarise our “common” ideas:

• Add a class or type attribute to the indicator tag and predefine some values (global and preferably localisable ones).
• Add indicators to the page-heading in Minerva, floating to the right; ideally in the tagline, so as to avoid affecting the page title.
• Show only a limited number and/or category of indicators (not more than one per page seems advisable for small screens); provide an optional dropdown at the same position which can contain other indicators.
• Indicators not using a supported type/class value will not be displayed at all.

Since the dropdown is a more complex change (I guess), for the beginning the mobile indicator area might only support one type (the quality badges), and then gradually support others, when a solution for the dropdown is found.

In T75299#6952177, @XanonymusX wrote:

• Indicators not using a supported type/class value will not be displayed at all.

I think that, while the one displayed initially (the assessment one) should be opt-in, the ones appearing in the dropdown should be opt-out—if there’s a dropdown anyway, real estate doesn’t seem to be a huge concern within that. Most indicators will probably work just fine within the dropdown, and even the ones that don’t, won’t break the page to the extent that would warrant making them opt-in (worst case: they overflow, forcing the user to scroll horizontally—but only if they open the dropdown).

Otherwise I agree with the points you listed above.

Another example for indicators: just saw that Dutch Wikipedia (nlwiki) puts the player for spoken articles in the indicator area (eg here), quite a stretch. At least it is also added to the end of the article (similar to dewiki, where the indicator icon only links to the footer with the player).

Russian Wikipedia examples:

1. Geographical coordinates are moved to indicators that are shown first, before any icons, example: https://ru.wikipedia.org/wiki/Санкт-Петербург
2. Some pages with Template:Box can define page shortcuts (WP:5P etc.) in indicators, example: https://ru.wikipedia.org/wiki/Википедия:Технические_запросы

Coordinates can be hidden on mobile if needed since they are present in text, too.

@Jdlrobson I see this is now in "triaged but future". Does that mean you've given up and thrown this onto the backlog?

In T75299#7070267, @Sdkb wrote:

@Jdlrobson I see this is now in "triaged but future". Does that mean you've given up and thrown this onto the backlog?

I'm not sure where this interpretation is coming from but our use of Phabricator is documented in https://www.mediawiki.org/wiki/Reading/Web/Phabricator#Backlog_columns and this is not how you should interpret it.

Change #1061962 had a related patch set uploaded (by Abaris; author: Abaris):

[mediawiki/skins/MinervaNeue@master] Add support for indicators in Minerva skin

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

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/4d04841618/w

Test wiki created on Patch demo by Doğu using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/1a934183c9/w

Test wiki on Patch demo by Doğu using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org/wikis/1a934183c9/w/

Test wiki created on Patch demo by Doğu using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/043c48daba/w

In T75299#6930942, @XanonymusX hat geschrieben:

I would go along with giving good/featured a special treatment (as I said, I would then just directly take that information from WD and ideally display the small badges to the right of the short description), which should be prioritised, and offering a dropdown for anything else users might have added to the indicator area (unless specifically marked as nomobile).

EDIT: Experimented with the quality indicators. My idea would be to add the badges (either the WD gold/silver ones or the local ones) to the tagline, floating on the right. See screenshots (based on this featured article on dewiki):

I’m just going to refer to my previous suggestions again. The proposed design now seems a bit uneven. But at this point I am happy about any way that makes indicators visible on mobile.

In T75299#10058958, @Jdlrobson wrote:

Justin could you weigh in on the proposed design here?

JFYI: the URL displays as this (at least in Firefox), which is probably not the intended design:

In T75299#10059021, @XanonymusX wrote:

In T75299#6930942, @XanonymusX hat geschrieben:

I would go along with giving good/featured a special treatment (as I said, I would then just directly take that information from WD and ideally display the small badges to the right of the short description), which should be prioritised, and offering a dropdown for anything else users might have added to the indicator area (unless specifically marked as nomobile).

EDIT: Experimented with the quality indicators. My idea would be to add the badges (either the WD gold/silver ones or the local ones) to the tagline, floating on the right. See screenshots (based on this featured article on dewiki):

I’m just going to refer to my previous suggestions again. The proposed design now seems a bit uneven. But at this point I am happy about any way that makes indicators visible on mobile.

Actually, it's my design as well, but I didn't know that the tabs wouldn't display during the initial installation, so I'll add another patch.

With the tabs it looks like:

Maybe this is an excuse to make the page tabs on by default for every wiki :-)

Also JFYI some indicators can be long, for example https://ru.wikipedia.org/wiki/Санкт-Петербург has coordinates in there.

In T75299#10059828, @stjn wrote:

Maybe this is an excuse to make the page tabs on by default for every wiki :-)

Also JFYI some indicators can be long, for example https://ru.wikipedia.org/wiki/Санкт-Петербург has coordinates in there.

In my opinion, indicators with long text should be handled differently; they should only contain an icon.

Ah, next to the tabs would indeed be nice, that was also proposed back in T75299#6416792. And we had some more thoughts about longer indicators in T75299#6952177, eventually a drop-down menu would be needed.

Good to see someone with more technical know-how are tackling the problem of the icons not appearing on mobile (at least that was my issue request). But how has this issue been known for a DECADE and still not solved?

In T75299#10071738, @DILLA2 wrote:

But how has this issue been known for a DECADE and still not solved?

It's pretty common. There's only so many software engineers, and this ticket may not be as urgent to some folks as to others.

At the moment it appears to be awaiting sign off from a designer.

In T75299#10071772, @Novem_Linguae wrote:

In T75299#10071738, @DILLA2 wrote:

But how has this issue been known for a DECADE and still not solved?

It's pretty common. There's only so many software engineers, and this ticket may not be as urgent to some folks as to others.

At the moment it appears to be awaiting sign off from a designer.

Thank you for explaining it to me! :)

Change #1061962 abandoned by Abaris:

[mediawiki/skins/MinervaNeue@master] [WIP] Add support for indicators in Minerva skin

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

@MMiller_WMF and I discussed this at WikiConference North America. There is continued interest in having it be addressed the next time developers have room for a smaller task, as GA/FA icons are important indicators to readers that an article has been vetted and should be available to them on mobile!

Per the web team's quarterly grooming, these tasks are being removed from the team's backlog.

@Jdlrobson-WMF @Jdlrobson there was yet again active interest in this task literally within the past week. Please do not remove it from the backlog without a meaningful explanation.

The web team processes and how we use the backlog is documented on https://www.mediawiki.org/wiki/Reading/Web/Phabricator

This has been untagged per our quarterly grooming process as I noted in my comment above (see section #Freezer

Unfortunately as it stands, we have no plans to work on this in this year and the backlog reflects the team's current workload, priorities, focus and capacity. It doesn't mean another team or volunteer could not pickup this task. It has not been declined.

I hope this clarifies things and I realize it might not be what you want to hear but I want to be transparent and honest here.

When a volunteer submitted a patch last August, you commented on it saying that input from Web team's designer is required before it can proceed (https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/1061962/comments/5e2ca389_fe067aab). Does this latest status change for this task in the Web team mean that their input is no longer required before volunteers can try to resolve this?

(I just noticed that the Web team designer, @JScherer-WMF is still assigned to this task, and I'm not sure how I should understand that.)

First of all @matmarex @Sdkb and others, thanks for reaching out on this and letting us know that there is continued interest in this feature. At this time, we don't have the capacity to work on it (@ovasileva can answer any questions around our current and future priorities). Since the ticket seemed inactive, our grooming process moved it into our freezer.

However, I think there's real potential for these indicators as long as we do an appropriate amount of design exploration before proceeding with any changes.

I would be grateful if a contributor could take on the design side of this ticket, and I'd be happy to help guide that effort and provide feedback.

This feature is currently being held up by a lack of thorough design exploration and rationale. What needs might these indicators fulfil for casual, organic readers? What problems are we trying to solve with them?

For example, a FA/GA badge with enough context could be an interesting and valuable trust signal for a reader, similar to how warning templates are often used as distrust signals when articles are low quality. On the other hand, I assume that a "protected" badge would be of little interest to anyone who isn't logged in and actively considering contributing to the wiki.

Another tension in the current proposal is the form of the indicators themselves. As mentioned in the VP discussions about this, there may be a low awareness of FA/GA for casual readers, and an unlabelled icon might not "onboard" casual readers into explaining what FA/GA are and why they're useful.

The proposed location on the article pages is also very prominent, and so I want to ensure any new features going into that space have had an appropriate amount of design exploration.

• I would want to see a comparative audit of how markers like these are used in other content-heavy interfaces with casual reading audiences.
• What can we learn about how those experiences help readers understand what those indicators signify?
• Are all the indicators interactive, and if so, where do they link to and what do they do?
• Are there normative UI patterns that our readers are exposed to outside of our interfaces that they would expect to see?

I would also want to see analysis of the indicators themselves to answer the questions:

• Which indicators could be useful for casual reading audiences?
• What other audiences might benefit from the indicators and why?
• Where could the indicators link to?

Those items would give us the capacity to think through a design in a fulsome way.
Ideally I would want to see (at a minimum) some unmoderated usability testing with 5+ casual readers. Does the design intervention meet their expectations? Why/why not?

As I mentioned, I would be grateful if a contributor could take on these design tasks, and I'd be happy to assist.

@JScherer-WMF, the design exploration you're advocating sounds reasonable. It also doesn't sound at all like the sort of thing volunteers would normally handle — perhaps someone has the needed UX experience, but I've never heard of volunteers putting together a full report or doing more than anecdotal usability testing.

Just wanted to leave a comment here to register my support for this feature request -- in particular, I support adding the good article (GA) and featured article (FA) icons to mobile interfaces. I have no view on whether we need to add the protection icons to the mobile interfaces.

I suppose the closest thing to this I can think of on other websites might be that blue checkmark that used to signify "verified" social media accounts, e.g. on Twitter before it changed to X and allowed anyone to pay for a checkmark. In this case, this would be Wikipedia's version of a checkmark indicating that the article has passed a review for its quality. It's been a few years since Twitter changed to X, but if I recall correctly, simply clicking on the blue checkmark would have presented some kind of toast or taken you to a page that explains its meaning (identifying accounts that have passed an internal Twitter review for notability and authenticity). Similarly, clicking on the GA or FA icon on the desktop site takes you to either https://en.wikipedia.org/wiki/Wikipedia:Good_articles or https://en.wikipedia.org/wiki/Wikipedia:Featured_articles, which explain the meaning of those icons.

Also, in addition to surveying the impact of these icons on casual readers, I would be interested in surveying their impact on experienced editors too. I suspect that these icons provide significant motivation for experienced editors to improve Wikipedia's articles, and if editors start to realize that the icons are not actually visible for most people who use Wikipedia (as more of our readership consume Wikipedia through mobile interfaces), I wonder if this may have a detrimental effect on that motivation.

With all due respect, how are we stuck on this issue for 12 years with mobile still not showing indicators whatsoever? Why not add the indicators first and worry about how you can make them more understandable to casual users later? Why is that a mobile-exclusive concern? A simple indicator that, when clicked, directs users to the relevant project page, should work fine, at least as a first implementation. Mobile viewers aren't inherently all casual users. As an editor, it's really frustrating when the interface hides certain things from me and provides no way to show them for no good reason.

I am also quite frustrated, honestly, there were a lot of good proposals made throughout the past couple of years (see above), but nothing seems to happen. For me, I have added the GA/FA indicators in Minerva everywhere through a user script, so I at least get that information, but the rest is still missing (and also more complex to realise through a user script).

It's the same as with not having Talk tab on most wikis even though that’s the basic feature of all MediaWiki websites: the development team is thinking of mobile website as a cut-down, dumbed-down, readers-only version of the desktop interface, so anything too inconvenient was cut a long time ago and now there’s resistance to getting it back there. Which is ironic considering that the WMF seems to want to improve the mobile editing experience in the following year.

@stjn: It seems that you believe that you know the thinking of a development team which, as far as I know, you are not part of. Please avoid doing so. Thanks.

In T75299#11887448, @Aklapper wrote:

@stjn: It seems that you believe that you know the thinking of a development team which, as far as I know, you are not part of. Please avoid doing so. Thanks.

Are you saying that the development team doesn’t do what they thinks, and doesn’t think about what they does?