Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Jdlrobson | T78430 [Epic] Getting Wikidata to render nicely on mobile web | |||
Open | None | T158181 Aim for workflow equivalence for MediaWiki on desktop and mobile web | |||
Open | None | T95878 [Story] Make Wikidata editable on mobile web | |||
Open | None | T95649 Create and document a stable framework for extending the Wikibase UI | |||
Stalled | None | T40968 Keyboard-navigability of the repo UI | |||
Open | None | T54136 [Epic] Redesign Item UI for Wikidata repo | |||
Open | None | T87316 [Story] Redesign statement section | |||
Open | None | T87327 [Story] Group statements within statement group by ranks | |||
Invalid | None | T59666 [Task] Ensure normalized ordering of claims and snaks in the API | |||
Invalid | None | T74297 [RFC] Have API return and accept lists instead of maps to maintain order |
Event Timeline
Question: should it be grouped by normal, preferred or deprecated? or should it be grouped by the concept of "best" statements?
I'd say we would have three or two paragraphs. So, if we have statements of all ranks on a property, it would look like this:
Statements
preferred
Stale statements
normal
Wrong statements
deprecated
If we only have preferred and deprecated, it's:
Statements
preferred
Wrong statements
deprecated
And if we only have normal and deprecated, it's also:
Statements
normal
Wrong statements
deprecated
And finally, with preferred and normal statements, it looks like this:
Statements
preferred
Stale statements
normal
We need all 3 sections for drag and drop at least when editing. We probably don't want to show the sections that are not in use when not editing to reduce page clutter.
Let's please not use wrong/stale.
We use the concept of best statements everywhere except for editing. I can live with not using it for editing an entity, but I think we have to use it for displaying an entity. What people see in their client wikis should match what they see on the repo. In client wikis, best statements are used, no matter if they are normal or preferred. On the repo, there should be a section showing the statements that are used in clients, and the name of the section should not be different on different entities. Otherwise, it will confuse people, and for no good reason.
As for the captions, I don't really care about them. ›Wrong‹ should probably be ›Deprecated‹, since we already use that. ›Stale‹ could be ›Other‹ or ›More‹ or something like that.
related and possibly overlapping, I propose T115054 as a simple, short term solution to base sorting on ranks. (no grouping, just put preferred things at the top within a statement group and deprecated thing at the bottom)