Page MenuHomePhabricator

Enable support for the none (novalue) and unknown (somevalue) "special value" types in SDC UI
Closed, ResolvedPublic

Description

On Wikidata, users can toggle between 3 snak types:

  1. value: This is a custom value, where the user will select a Wikidata item, type in a string, etc.
  2. somevalue: This represents that a value exists for the property without saying anything about that value
  3. novalue: This represents that there is no value for this property

We want to enable users to do something similar on Commons. For now, we have decided to only enable addition of somevalue and novalue snaks in the WBMI UI for properties with the Wikibase entity datatype. This is because the most likely use case of somevalue is to represent a missing WIkidata item, e.g. a creator of an image. Users will add somevalue for the creator property, then add qualifiers to represent known information.

We will, however, display existing somevalue/novalue snaks for other datatypes, e.g. if someone adds a somevalue snak for a string property via the API. This is unlikely, but will allow us to see if there are additional use cases, and therefore additional input types, to cover.

Wikidata uses three "dots" next to input elements, regardless of type – toggling between them lets the user select normal values (strings, entities, etc), unknown value (aka "somevalue"), or no value.

Acceptance criteria:

  • somevalue/novalue snaks display in the UI for all datatypes
  • somevalue/novalue snaks are deletable via edit mode for all datatypes
  • Users can add somevalue/novalue snaks for Wikibase entity properties
  • Users can add qualifiers to somevalue/novalue snaks

Top level somevalue example:

Qualifier level somevalue example:

Current design thoughts, process, and options can be found here: https://docs.google.com/presentation/d/1WV19D2DsXYXw3A4xmg7oPxPEwQjqeM17fa1YoRjxL18/edit?usp=sharing

Event Timeline

egardner created this task.Nov 25 2019, 9:54 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 25 2019, 9:54 PM
Multichill renamed this task from Enable support for the none and unknown "special value" types in SDC UI to Enable support for the none (novalue) and unknown (somevalue) "special value" types in SDC UI.Nov 25 2019, 10:24 PM

Thanks for creating this one @egardner . This is already used quite a lot to model authorship of a file. Would be nice for the interface to actually show something soon.

Cparle added a subscriber: Cparle.Nov 26 2019, 5:16 PM

@Multichill is it important that we allow users to add "no value" values when they're editing, or do you think it'd be sufficient to simply display "no value" values that have been added some other way?

@Multichill is it important that we allow users to add "no value" values when they're editing, or do you think it'd be sufficient to simply display "no value" values that have been added some other way?

I don't think we have a use case for novalue yet. I haven't seen it in the wild. Somevalue on the other hand should be both visible and editable.

From a technical perspective, it's probably easiest to add support for both special values at once (though this will depend somewhat on the proposed UI).

I did some design exploration on how we could support no value/unknown values, but it radically changes how statements editing will work on Commons. We discussed it as a team and have decided that for now, we will:

  1. display no value/unknown values if added
  2. make these values deletable in edit mode

Support can be more robust in the future when the community data model is more fleshed out.

--> see added mocks to the description

Side note: the Wikidata Image Positions tool currently supports adding somevalue/novalue “depicts” statements (on Wikidata and Commons) on the technical level, but following advice from @Harmonia_Amanda I’ve hidden the corresponding UI elements (except for certain selected users), as we figured the overall ecosystem isn’t ready for somevalue statements on Commons yet. (novalue will probably stay permanently hidden, I can’t think of any use of it in “depicts” statements.) Once somevalue/novalue are properly displayed and made deletable in the main Structured Data on Commons UI, I’ll probably unhide the somevalue button.

I did some design exploration on how we could support no value/unknown values, but it radically changes how statements editing will work on Commons. We discussed it as a team and have decided that for now, we will:

  1. display no value/unknown values if added
  2. make these values deletable in edit mode

Support can be more robust in the future when the community data model is more fleshed out.

--> see added mocks to the description

So that means that a normal user can't use it? As a community we decide on how we want to model our data. One of the crucial elements is using "somevalue" when no Wikidata item is available. You're not supporting this? To say that I'm unhappy about this is an understatement. Please explain your reasoning on how you came to this decision.

Given the endless, and seemingly ongoing, difficulties the decision to fork the wikibase UI is leading to, and seems to be continuing to produce -- most types of statement still not available, somevalue not available, deprecation not available, references not available -- at what point does it make more sense to withdraw the forked UI as a costly experiment that hasn't worked, and is causing more trouble than it is worth?

(Or at least mothball it until there are time and resources to develop full functionality properly).

Users as capable as Jarekt are already just asking for as standard Wikibase skin (thread), so they can get on and get some work done --but non-one is deigning to give them a substantive reply, even three weeks on.

The UI fork has already held us back for far too long. We should not let it continue to cause difficulties and hold us back any further. If the forked UI really cannot be made to work properly, then it's time to go back to the default Wikibase UI, which at least works with full functionality. And won't require every last tweak to be re-implemented for a separate codebase, going forward.

here's an attempt to clarify:

  • This is a step in a process. The first step will be improving the situation we have now, where these values aren't visible or editable at all in the UI when they're added via API/automated means. We'll be addressing that shortly. The next step will be supporting somevalue fully. It will be there. There's work, both technically and with community, that needs to be done first. We'll get there, and probably relatively soon, but we're not there right now.
  • WMF projects use OOUI and org-wide design principles. Wikibase does not. We're doing our best to reconcile all that but, again, it is a process. We appreciate and consider feedback as part of that process. But using the default Wikibase UI is currently not an option for this team. If that changes, we will let you know.
Jheald added a subscriber: Jarekt.Dec 9 2019, 9:46 AM

WMF projects use OOUI and org-wide design principles. Wikibase does not.

Does that actually matter?
Is it actually worth anything, weighed against the points that:

  1. The forked UI doesn't work
  2. That it doesn't work is holding up the entire project
  3. Re-implementation is having the effect that every feature of Wikibase UI functionality has to be done over again de novo for Commons; and then, going forward for ever after that, every new feature, gadget, extension or addition for Wikibase will also then have to be done over again for Commons. How did this ever become a project priority, when there is still so much else to get right?

BTW, I note that @Jarekt has now filed T240093 "On Commons create optional "skin" for displaying structured data which mimics Wikidata look" -- though full display and editability of full functionality for all users is required, not just for those opting-in to a particular UI, or those editing via automated scripts: not least because a run of automated edits often then require a further manual edits for particular corrections or fine tuning; or for example, one of the points of the "somevalue / stated as... <text>" idiom is to be visible to regular users, so they can (i) see the value, and (ii) be prompted to create or identify a relevant Q-item, to replace the somevalue with an actual item, plugging the value into the structured data network -- this needs people to be able to see it, and edit it.

To echo what @Ramsey-WMF said, the read-only/delete-able label for somevalue is a short-term solution. We understand that this feature is important and plan to support it eventually, just as we are working to enable support for the various other types of statements (https://phabricator.wikimedia.org/T233036). We plan to roll out support for new types as they are ready but this is something that will begin happening soon.

AnneT claimed this task.Feb 7 2020, 2:55 PM

Change 572121 had a related patch set uploaded (by Anne Tomasevich; owner: Anne Tomasevich):
[mediawiki/extensions/WikibaseMediaInfo@master] Display existing somevalue and novalue top-level statements

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

Change 572124 had a related patch set uploaded (by Anne Tomasevich; owner: Anne Tomasevich):
[mediawiki/extensions/WikibaseMediaInfo@master] WIP - still to do: - Get qualifiers working - Implement for input types other than string - Get design feedback and update UI as necessary - Add tests

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

AnneT added a comment.Feb 20 2020, 7:46 PM

Here's a gif of the new somevalue/novalue functionality and design. Somevalue and novalue snaks can be added via the WBMI UI for Wikidata entity properties. Somevalue/novalue snaks added via the API will be displayed for all property types, although we don't expect to see any for non-entity datatypes. Even though the somevalue language no longer makes sense for non-entity properties, I think it's better to show these snaks rather than hiding them. It'll allow us to see if users end up wanting somevalue/novalue for other datatypes.

The gif shows the following:

  • An existing somevalue snak for a string property that's visible and deletable but not editable
  • A somevalue snak being added for an entity property
  • A novalue qualifier being added
  • A qualifer being added to a somevalue statement

@Ramsey-WMF I think this is ready for design review, then I can make changes based on feedback.

Here's a gif of the new somevalue/novalue functionality and design.

Anne, that looks good. Can't wait to see it rolled out.

Maybe not show it in the case of depicts because it might confuse users? I can't imagine a use case where I want to say depicts -> somevalue/novalue.

@mwilliams Here's a gif of the addition/removal of the add button depending on the snak type:

AnneT updated the task description. (Show Details)Feb 25 2020, 7:46 PM
AnneT updated the task description. (Show Details)
mwilliams updated the task description. (Show Details)Feb 25 2020, 10:29 PM
AnneT added a comment.Feb 27 2020, 8:46 PM

Thanks to all who have commented on this task and given feedback! Below is a gif of the latest design iteration, which aims to minimize confusion for users who don't want or need to use the snak type switcher by reducing the visual weight of the dropdown and removing the label text in favor of an icon. Please let us know if you have feedback so we can move forward on a final design.

Change 572121 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Display existing somevalue and novalue top-level statements

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

AnneT added a comment.Mar 10 2020, 8:23 PM

@Jarekt / @Multichill, any feedback on the design depicted in the gif I posted in my last comment before we move forward with it?

AnneT added a comment.Mar 11 2020, 3:52 PM

Update: we've opted to add somevalue/novalue items as soon as they're selected from the dropdown to mimic the behavior of entities selected from the autocomplete widget, gif below:

Change 572124 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Add somevalue/novalue options for entity datatype

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

Ramsey-WMF reassigned this task from AnneT to Etonkovidova.Apr 8 2020, 8:30 PM
Ramsey-WMF added a subscriber: AnneT.

Ready for testing on Beta Commons 👍🏼

this one is best tested on production now.

Etonkovidova added a comment.EditedApr 21 2020, 11:57 PM

Tested in wmf.28 - seems to behave according to the specs - the screenshots below are for illustration only; no problems were found

  • the drop-drop down three-dot menu

  • added snaks - "Some value" and "No value"

@Ramsey-WMF - I didn't go into the logic (e.g. as per @Multichill's comment that depicts should not have such options). However, I noticed that on wikidata PropertySomeValueSnak is called unknown and there is a precise usage description on https://www.mediawiki.org/wiki/Wikibase/DataModel#Snak.

Etonkovidova updated the task description. (Show Details)
AnneT added a comment.Apr 27 2020, 2:03 PM

Hey @Etonkovidova – the use case for somevalue that we're supporting on Commons is a bit different than on Wikidata. After discussing with Multichill, we decided to support the use of somevalue to represent a missing Wikidata item rather than the broader Wikidata definition (i.e. some value exists for this property, but we aren't saying anything about that value). For this reason, we're only supporting somevalue/novalue snaks for the Wikidata item property type and have used different language for somevalue in the UI.

Hey @Etonkovidova – the use case for somevalue that we're supporting on Commons is a bit different than on Wikidata. After discussing with Multichill, we decided to support the use of somevalue to represent a missing Wikidata item rather than the broader Wikidata definition (i.e. some value exists for this property, but we aren't saying anything about that value). For this reason, we're only supporting somevalue/novalue snaks for the Wikidata item property type and have used different language for somevalue in the UI.

Thanks for the explanation!

Etonkovidova closed this task as Resolved.Apr 29 2020, 4:15 PM

All acceptance criteria have been checked.