Page MenuHomePhabricator

Display constraint clarifications in violation messages
Closed, ResolvedPublic8 Estimated Story Points

Authored By
Lucas_Werkmeister_WMDE
Mar 22 2019, 9:12 PM
Referenced Files
F36886577: image.png
Mar 1 2023, 10:54 AM
F36524823: Screenshot 2023-01-27 at 11.45.50.png
Jan 27 2023, 10:46 AM
F36524817: Screenshot 2023-01-27 at 11.42.13.png
Jan 27 2023, 10:43 AM
F36524797: Screenshot 2023-01-27 at 11.27.53.png
Jan 27 2023, 10:34 AM
F36511668: image.png
Jan 26 2023, 12:31 PM
F36458469: Screenshot 2023-01-24 at 13.41.34.png
Jan 24 2023, 1:23 PM
F36457026: Screenshot 2023-01-24 at 12.24.10.png
Jan 24 2023, 1:23 PM
F36464752: Screenshot 2023-01-24 at 14.12.44.png
Jan 24 2023, 1:23 PM
Tokens
"Like" token, awarded by Naseweis520."Like" token, awarded by Moebeus."Grey Medal" token, awarded by Esc3300.

Description

As an editor, I want additional clarification on how I can create a more accurate value for my problematic data in order to create cleaner data.

As a data modeller, I want other editors to understand why their edits are violating constraints, and how they can fix it in order to standardise our data.

Problem:
When a constraint violation is triggered not enough information is provided to the editor for them to understand the issue. By providing clarification for editors to understand the constraint violations, editors will be able to standardise data modelling more easily.

@ArthurPSmith created the constraint clarification property as a way to make Property constraints more understandable for other editors who try to add data that violate these constraints.

By adding the constraint clarification in the constraint violation message, users will be able to understand how to create more accurate values for their problematic data.

This needs to be supported by the Wikibase Quality Constraints Extension.

Example:
Current state:

image.png (629×1 px, 156 KB)

Example constraint clarification:

image.png (562×1 px, 55 KB)

Example from sandbox:

Screenshots/mockups:

Screenshot 2023-01-27 at 11.27.53.png (674×1 px, 78 KB)

Screenshot 2023-01-27 at 11.45.50.png (1×2 px, 534 KB)

Mock-up and specs of the new constraint violation message.

The constraint clarification is added as a new paragraph below the constraint definition in the violation message.

BDD
GIVEN an editor adds a value that triggers a constraint violation
AND there is a constraint defined for the property
AND that has a constraint clarification
WHEN the constrain violation is triggered
AND the editor clicks the flag
THEN they are able to see a message from the constraint clarification that explains why that value violates the constraints of the Property

Acceptance criteria:

  • Constraint clarification is shown when a constraint violation flag is clicked

Open questions:
If a constraint clarification exists, but not in the language of the user how will this be shown?

We decided that we would use the same language fallback as the syntax clarification.

Original ticket:
@ArthurPSmith just created the constraint clarification property; see the property proposal for discussion on how it can be used to improve violation messages. Assuming the community adopts it, we should include these clarifications in constraint violation messages.

Event Timeline

I'd like to see this made a bit higher priority? It seems it would be fairly trivial to implement with a good impact. One that I have seen often repeated over and over by the Lexicographical community is this particular constraint and the explanation given over and over when folks hit the constraint but are left wondering what it really means. Here's an example where I've given "usage example" a constraint clarification text of that explanation we repeat so often to folks in Telegram chat.
https://www.wikidata.org/wiki/Property:P5831

Arian_Bozorg updated the task description. (Show Details)

The UI change to enable the suggested solution is pretty straightforward in general. Nevertheless, I'm compelled to share some thoughts for consideration.

I'm not sure whether we have to follow the current structure, in which case, constraint clarifications would be added in a separate paragraph in the existing popover, possibly like so:

Screenshot 2023-01-24 at 14.12.44.png (646×1 px, 131 KB)

This default structure that I assume we should follow might generate confusion: How quick can I understand that these two pieces of information are related? Are these two different constraints?. (Please note that, as displayed in the screenshot above, the default divider that usually separates elements on a list of constraints, and the extra margin between paragraphs, were removed to try to make information look a bit more related).
If we could avoid displaying the new property link(s), that would visually be an improvement. Nevertheless, doubling the amount of information provided by the popover might not be an ideal solution. (Specially in the case of values with multiple constraints).

The optimal approach would consist on improving (i.e. simplifying) existing content/constraint definitions to make them clearer from scratch, which I'm aware we don't have any control over. Alternatively, constraint tooltips already present a 'Help' link that takes users to a page that contains further explanations, and even a list of possible actions that they can take to improve the value provided:

Screenshot 2023-01-24 at 12.24.10.png (384×1 px, 92 KB)

We could make this information more clearly available for users, by providing said resource as a clearer affordance to them. For example (the copy definitely could use some more thought):

Screenshot 2023-01-24 at 13.41.34.png (502×1 px, 78 KB)

I was thinking of adding the clarification message as a separate paragraph below the main constraint message, but under the same heading:

image.png (349×575 px, 34 KB)

(Maybe something like “clarification:” could be added inline, not sure. Probably depends on whether the majority of clarifications are phrased as sentence fragments or complete sentences, or whether we can expect constraint maintainers to rephrase the existing clarifications in one style that works better.)

The “possible actions” on the help link are very generic and just a guess based on the constraint type in general, I don’t think we should highlight those or include them in the individual constraint violations.

I was thinking of adding the clarification message as a separate paragraph below the main constraint message, but under the same heading:

image.png (349×575 px, 34 KB)

(Maybe something like “clarification:” could be added inline, not sure. Probably depends on whether the majority of clarifications are phrased as sentence fragments or complete sentences, or whether we can expect constraint maintainers to rephrase the existing clarifications in one style that works better.)

This is actually the first option that came to mind for me too, but then I assumed that we were compelled to link to the property from where the information is proceeding. If we all agree that making that too explicit is not necessary, then we could follow this route (and hopefully apply sentence capitalization to the additional information).

Regarding adding 'Clarification' inline, I'd say it's not needed 🤔

This is actually the first option that came to mind for me too, but then I assumed that we were compelled to link to the property from where the information is proceeding.

The constraint type in the heading (“none-of constraint” in the screenshot) already links to the constraint definition (example). (I guess that’s not exactly obvious… you might expect it to link to the “none-of constraint” item. But the constraint definition is more useful ^^)

This is actually the first option that came to mind for me too, but then I assumed that we were compelled to link to the property from where the information is proceeding.

The constraint type in the heading (“none-of constraint” in the screenshot) already links to the constraint definition (example). (I guess that’s not exactly obvious… you might expect it to link to the “none-of constraint” item. But the constraint definition is more useful ^^)

Indeed, all information and properties are accessible from that constraint definition section. If that's enough, and we don't need to be more explicit regarding the origin of that extra bit of information in the popover, then I think this might be good to go:

Screenshot 2023-01-27 at 11.27.53.png (674×1 px, 78 KB)

I hope that applying the right capitalization and punctuation is a no-sweat.

Sarai-WMDE updated the task description. (Show Details)
Sarai-WMDE subscribed.

I hope that applying the right capitalization and punctuation is a no-sweat.

I don’t think we should do this by default (though it’s technically possible); assuming editors agree, we should just recommend that constraint clarifications are written as complete sentences. They’re currently written in an inconsistent mixture of punctuation and capitalization (query), so it’s not like there’s an established standard we’d be breaking away from.

If you or @Lydia_Pintscher agree, I’d post a suggestion in that direction on-wiki (probably the “constraint clarification” talk page, pinging the constraints wikiproject).

Arian_Bozorg subscribed.

Thank you so much Sarai and Lucas I think this option showing the clarification under the violation works best:

Screenshot 2023-01-27 at 11.27.53.png (674×1 px, 78 KB)

Some may have multiple constraint violations and I think this option will be a clear way of grouping them all together.

Regarding capitalisation and punctuation; as the clarification comes from the community, I think it is best to keep them as is. Both to encourage better / cleaner information from them and also not to accidentally undo correct information.

I would prefer wikitext over normal text, so that it would be "Use {{unknown value}} instead of anonymous when the author is unknown." in the example. New users might not know what "unknown value" happens to be and the wikitext template gives the user the link to the page that explains it in more detail.

Change 886380 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseQualityConstraints@master] Remove unused @throws from DelegatingConstraintChecker

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

Change 886381 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseQualityConstraints@master] Clean up ConstraintParameterParser doc comments

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

Change 886382 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseQualityConstraints@master] Add strict types to files about to be touched

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

Change 886383 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseQualityConstraints@master] Don’t create new check result in downgradeResultStatus()

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

Change 886384 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseQualityConstraints@master] Use LanguageFallbackChainFactory for multilingual texts

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

These are just preparation patches, I’m not done with the tests for the main part yet. Leaving the task in Doing, though if anyone from the team wants to start reviewing that’s also okay.

Change 886380 merged by jenkins-bot:

[mediawiki/extensions/WikibaseQualityConstraints@master] Remove unused @throws from DelegatingConstraintChecker

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

Change 886381 merged by jenkins-bot:

[mediawiki/extensions/WikibaseQualityConstraints@master] Clean up ConstraintParameterParser doc comments

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

Change 886909 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseQualityConstraints@master] Show constraint clarifications below violation message

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

Change 886916 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseQualityConstraints@master] README: Fix more maintenance calls

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

Change 886909 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseQualityConstraints@master] Show constraint clarifications below violation message

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

This is the change actually implementing the feature :)

Note to reviewers: you’ll want to run something like

mediawiki/core $ php maintenance/run.php WikibaseQuality.ConstraintReport.Maintenance.ImportConstraintEntities

which will import the new relevant entities (the “constraint clarification” property, and possibly other entities) from Wikidata to your local wiki, and print a config snippet that you should add near the end of your LocalSettings.php.

Change 886382 merged by jenkins-bot:

[mediawiki/extensions/WikibaseQualityConstraints@master] Add strict types to files about to be touched

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

Change 886383 merged by jenkins-bot:

[mediawiki/extensions/WikibaseQualityConstraints@master] Don’t create new check result in downgradeResultStatus()

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

karapayneWMDE set the point value for this task to 8.Feb 21 2023, 9:28 AM

Change 886384 merged by jenkins-bot:

[mediawiki/extensions/WikibaseQualityConstraints@master] Use LanguageFallbackChainFactory for multilingual texts

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

Change 886916 merged by jenkins-bot:

[mediawiki/extensions/WikibaseQualityConstraints@master] README: Fix more maintenance calls

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

Change 886909 merged by jenkins-bot:

[mediawiki/extensions/WikibaseQualityConstraints@master] Show constraint clarifications below violation message

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

Thanks so much Lucas,

Looks good to me :)