| RolandUnger | |
| Nov 12 2014, 8:40 AM |
| F57269981: Screenshot 2024-08-12 at 10.52.31 PM.png | |
| Aug 12 2024, 8:53 PM |
| F57269938: image.png | |
| Aug 12 2024, 8:30 PM |
| F34174966: Screenshot Guccini gold badge 2021-03-20.jpg | |
| Mar 20 2021, 1:04 PM |
| F34174967: Screenshot Guccini exzellent 2021-03-20.jpg | |
| Mar 20 2021, 1:04 PM |
| F34155667: image.png | |
| Mar 12 2021, 2:24 PM |
| F32198069: Non-advanced tools.png | |
| Aug 28 2020, 1:12 AM |
| F32197840: toolbar.png | |
| Aug 27 2020, 5:54 PM |
| F32197831: short_title.jpg | |
| Aug 27 2020, 5:43 PM |
Indicator elements <indicator> are not shown in mobile view. They are not part of the html source code.
In desktop for instance, protected pages are shown like so:
In Minerva we are free to display the protection logo how and where we choose.
This also impacts the featured article of the day (via the Main page)
On desktop a star is shown, but not on mobile
These indicators are defined in templates like so:
https://en.wikipedia.org/wiki/Template:Pp-vandalism
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| [WIP] Add support for indicators in Minerva skin | mediawiki/skins/MinervaNeue | master | +24 -1 |
But mobile web of enwiki does have a tagline, it is just empty. And I stand corrected, the same holds true for Minerva on desktop generally, so the tagline should indeed be the preferred position for the indicators. My proposal:
IMO, step 1 could be implemented quickly, while step 2 might require some more work (but it is also less essential, as pointed out by others above).
I don’t think relying on Wikidata is a great idea. The local templates and the Wikidata information should say the same, but nothing enforces it, inevitably leading to differences every now and then. So if Vector uses the local templates and Minerva uses Wikidata, they will have the same result only in 99% of the articles. I think adding some metadata to the indicator (e.g. <indicator name="topicon-Vorlage_Exzellent" category="assessment">) is a better solution—it requires some work to add it to templates around wikis, but then it guarantees 100% correct output, and it can even handle if wikis choose a different assessment system, which isn’t (yet) properly mapped in Wikidata (like Wikisources’ {{TextQuality}} template).
If there was a workable proposal for generally showing indicators in Minerva, sure; but since 2014 there hasn’t been any, as far as I can see. My WD-based proposal is relatively easy to configure, as the same is done for generating the short description on most projects, so I have more hope that it could be done quickly. And people seem to agree that those quality badges are the most important/relevant types of indicators, so giving them a special treatment seems to be in line with what has been discussed about the general problem. Oh, and just like with the short description, a way to locally overwrite it (with a categorised indicator as proposed?) could be implemented as well. The rare discrepancy between WD and local indicator (which at least on dewiki is tracked and quickly fixed) is still an improvement over not having any indicators shown.
As far as I see, the main issue causing this not to be fixed for more than six years now is UI design, not the underlying technology. UI design should be independent of what the underlying technology is; if your proposal about using the tagline works for badges from Wikidata, it will work for badges from indicators as well. If it doesn’t work out for indicators, it won’t work out for WD badges either.
My proposal about the indicator attribute is also an approach to treat assessment badges specially; although a bit less specially, but more extendably—for example, if it’s decided that protection padlocks should not appear on mobile, not even among other, less important indicators, it’s easy to add a category="protection" that’s completely hidden by Minerva.
The huge difference between assessment indicators and short descriptions is that short descriptions don’t exist at all on desktop, so there’s no other source which could create discrepancy. (They have their own issue, namely being invisible to power users, who mostly edit on desktop, and thus being prone to vandalism, but that’s another story.)
By the way, there’s no tracking on huwiki (and probably on many other wikis either), and as a result Wikidata has only 1445 huwiki badges, whereas on-wiki there are 1036+425=1461 quality (featured+good) articles. This means that at least one in a hundred articles is missing its badge on Wikidata, so my above wild guess about 99% correctness is surprisingly correct. 🙂
Well, high time to track these discrepancies then! ;)
Yes, I would like to hear from the Design department (is there such a thing? I’m clueless, sorry) about the tagline proposal. Why I thought an extra treatment for these particular indicators would be good: we can be sure that they are icons. As already mentioned, almost anything could be added to the indicator area, which could gravely affect design on a smaller screen. And let’s not forget: the Interwiki links on mobile also need to show the badges (that’s why the information is added to WD in the first place), which they currently don’t, so there needs to be a WD connection anyway.
If the design question can be settled, the opt-in approach with an extra class would be a good one though, I guess. However, in the presence of several indicators, mobile needs to put them into a dropdown, and that seems like quite an effort to me, design-wise.
DeltaBot is ought to fix the discrepancies, but it seems not to work. 🙁
We agree that special treatment is probably needed, the only question is how to implement that; I say let (and require) the communities decide and configure this special treatment. This attribute-based configuration can work even if the approach for non-assessment indicators is not yet decided upon; simply everything that doesn’t have this attribute is completely omitted.
One more argument that just came into my mind: if there’s no attribute that designates assessment indicators, then when we come to the point where all indicators are displayed (likely in a dropdown), then assessment indicators from Wikidata will appear outside of the dropdown, while on-wiki indicators with the same meaning will appear in the dropdown, so we’ll have two (potentially differently-looking) icons describing the same thing. Thus we’ll then be forced anyway to mark assessment indicators somehow, but for sure some communities will be late to add this markup, leading the double icons to appear regardless. It’s much easier to just not introduce this double system in the first place.
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.
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:
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?
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
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 created on Patch demo by Doğu using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/043c48daba/w
Justin could you weigh in on the proposed design here?:
https://patchdemo.wmcloud.org/wikis/043c48daba/w/index.php?title=Indicator&mobileaction=toggle_view_mobile
https://www.mediawiki.org/wiki/Help:Page_status_indicators has more context on indicators if you need it and happy to chat in our next 1-on-1 about this in more detail if you have any questions?
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.
JFYI: the URL displays as this (at least in Firefox), which is probably not the intended design:
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 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?
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.
Change #1061962 abandoned by Abaris:
[mediawiki/skins/MinervaNeue@master] [WIP] Add support for indicators in Minerva skin
@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 also want to see analysis of the indicators themselves to answer the questions:
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.
