Page MenuHomePhabricator

Enable support for the none (novalue) and unknown (somevalue) "special value" types in SDC UI
Open, Needs TriagePublic

Description

We should eventually allow users to input "some value" and "no value" everywhere they can input other values in the structured data UI, regardless of the datatype that is otherwise expected for a given value.

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. If we choose to handle this differently, the solution still needs to work across all input elements.

Acceptance criteria:

  • no value/somevalue displays in the UI
  • no value/somevalue is deletable via edit mode

Top level somevalue example:

Qualifier level somevalue example:

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

PDrouin-WMF updated the task description. (Show Details)Dec 5 2019, 10:19 PM

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.