For our Wikidata Quality project we need to place icons on item pages that indicate whether a statement is valid or not.
Description
Details
Status | Subtype | Assigned | Task | |
---|---|---|---|---|
· · · | ||||
Resolved | Lydia_Pintscher | T97018 [Story] Integrate violations into Wikidata UI | ||
Resolved | Lucas_Werkmeister_WMDE | T95403 [Task] Investigation: Find a good place where to put icons for violation indication | ||
Resolved | Lucas_Werkmeister_WMDE | T180120 Snakview value is overflowing edit toolbar | ||
· · · |
Event Timeline
I think it would be better to place it after the statement since this can potentially become a longer list of icons. In this case it becomes harder to scan.
Icons need to be placed next to:
- main snak
- qualifier
- reference
Sitelinks potentially should also have one to indicate something about the sitelink like "this probably doesn't belong to this item". Same for labels, aliases and descriptions. But let's start with the above first.
Change 207449 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Add empty span for indicators to the snakview
https://gerrit.wikimedia.org/r/207449
For reference: Core's BaseTemplates does have a <div class="mw-indicators"> that's empty by default. This is the place where indicators for the whole page should go.
Change 207449 merged by jenkins-bot:
Add empty span for indicators to the snakview
https://gerrit.wikimedia.org/r/207449
We had to revert my first, ultra-simple approach in https://gerrit.wikimedia.org/r/#/c/209711/, sorry.
Most notable issues:
- T98596: Reference values disappear when adding an other snak
- The span is removed as soon as you start editing, and does not reappear if you cancel editing. That's because the snakview empties the value div. The indicator span is a child of that and therefor is deleted.
New proposal: Split what's currently <div class="wikibase-snakview-value $2">$3</div> into a block element (mostly for UI styling) and an inline element (for the actual value rendered by the responsible ValueView) and make it something like that:
<div class="wikibase-snakview-value-container $2"> <span class="wikibase-snakview-value">$3</span> <span class="wb-indicator"></span> </div>
Problems:
- wikibase-snakview-value-container is already in use.
- Having two containers is odd. Ideally it should be like <container><typeselector /><value /><indicator /></container>, but I'm not sure if this is enough for what's needed to style it properly.
- Quite a lot of code (CSS, JavaScript, browser tests, possibly external gadgets and scripts) rely on the existing <div class="wikibase-snakview-value"> and it's dual meaning.
@Lydia_Pintscher I don’t understand why this task was closed as “Resolved” – I’m not aware of any solution.
I think Thiemo’s proposed layout in this comment makes sense (apart from the name problems), and we will need something like that to address several problems in the constraints gadget. It would also be useful to gadget or user script authors.
Regarding the problems:
- The wikibase-snakview-value-container name is already in use – so find another name, we all know naming things is easy ;) but more seriously – surely we can find something. Perhaps wikibase-snakview-value-line?
- Having two containers is odd – hm, in my opinion it kinda makes sense. We have a container for the value with indicator, then another container for just the value, and inside that is the actual value, which is sometimes not even an element (e. g. strings and dates don’t have any surrounding elements, they’re just plain text nodes).
- Breaking existing code – yeah :( I think we should try to at least get some feedback on the new layout from external gadget/script authors before we deploy it. Perhaps there’s an opportunity for that at WikidataCon?
I’ll also copy+paste the (in my opinion) desired behavior of the indicators from T169866:
- When the user starts editing the statement, the indicators should be hidden, but not removed from the DOM. [We can even do the hiding with CSS: .wb-edit .wb-indicators { display: none; }. But they also need to be attached in the DOM somewhere where they won’t be removed.]
- When the user cancels editing the statement, the indicators should be made visible again. This ought to preserve event handlers.
- When the users saves the statement, the indicators should be cleared. User scripts, gadgets etc. can re-add them by subscribing to the hooks from T167870: Add JS hooks for changes to statements.
Ok, sorry. My understanding was that it was solved for the gadget. If not then let's keep it open.
Well, the gadget does append the icons somewhere, it’s just not a good place :) (but I seem to dimly recall that I agreed to closing this issue in some verbal discussion, so perhaps it’s my fault too)
Change 384524 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] WIP: Add wb-indicator span to snaks
https://gerrit.wikimedia.org/r/384524
Change 384525 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Add constraints indicators to wb-indicators
https://gerrit.wikimedia.org/r/384525
Does "place" here mean where to specify the icon on some wikidata item when defining the constraints OR is it about where to store the files?
Or is it where to place it in the UI, what the user sees? In that case: Please ask UX.
It looks like the original intention of this task was about where the constraint violation icon should be placed on the page, visually, but by now it’s just a question of where exactly we put it in the DOM – with the proposed change (the “indicators”) area, there’s no visual change from the status quo, except perhaps a small amount of whitespace reshuffling.
How I understood this task:
- Find a place in the DOM where gadgets and such can add their icons.
- Apply super-basic CSS styling that behaves "as expected" in the most relevant use case (which is, in my opinion, that the icons appear directly behind the rendered value, after a little extra padding).
I mentioned mw-indicators above, which I would use as a model: nothing but a <div>, where gadgets just add their inline elements (which are expected to be inline elements).
Change 384524 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Add wikibase-snakview-indicators span to snaks
https://gerrit.wikimedia.org/r/384524
Change 384525 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Add constraints indicators to wb-indicators
https://gerrit.wikimedia.org/r/384525
This has been deployed to Wikidata! And I noticed a minor bug – after editing (even if you just cancel the edit), the snak looks like this:
It’s the same problem that the gadget already used to work around, and I should’ve remembered it – the .valueview.valueview-instaticmode div, which we also need to make display: inline.
Reopening this task so I can attach the fix to it.
Change 392877 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] Make .valueview inline as well
https://gerrit.wikimedia.org/r/392877
Change 392877 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Make .valueview inline as well
https://gerrit.wikimedia.org/r/392877