Page MenuHomePhabricator

[Usability] restricted value input for items fails silently
Closed, ResolvedPublic

Description

Story: As a user, I want to add a value to a statement

What happens: If I add a value to a statement with a property which values are restricted to items (let's say I want to add to the item Harry Potter that he is Property:MemberOf the Item:Gryffindor) , creation of the value fails silently if that item does not yet exists: The save link remains gray, there is no notification of the kind of error.

Even if I notice the problem, my workflow is interrupted; I can't carry on creating these relations (like I could similarly on Wikipedia, where such would result in red links) but must cancel or create the other, to-be-linked-to item first.

What should happen:

  1. There should be a notification e.g. if the user clicks "save" which informs the user that the input could not be matched to an item and that this item could be created.

  1. Possibly, it would make sense to allow saving anyway and allow to match the input with an item later. So if I edit Harry Potter’s "educated at" value and I want to add "Hogwarts" but the item Hogwarts does not exists yet, I still can save, but the value is grayed out (or similar) and if I edit, I can match it again to the (hopefully) now created item.

Usability Guidelines: User Control and Freedom, Help users recognize, diagnose, and recover from errors

Related: T138365

Event Timeline

Jan_Dittrich renamed this task from Restricted Values fail silently on wrong input to [Usability] restricted value input for items fails silently.Jun 22 2016, 8:14 AM

related: T138499 (silent fail after just adding a reference but not putting anything in)

Having a disabled save button but no explanation why is bad. Fully agree. But enabling it and "tricking" the user into clicking a dysfunctional button, just to show an error message, is worse I feel. Same for saving dysfunctional values nobody else can later use or fix, because nobody else knows what the original user meant. That's what Wikidata is about after all, knowing what was meant.

Introducing a per-user "draft" concept into the Wikibase software is a fascinating idea we should continue to talk about. I suggest to find a better place to discuss this.

Alternative suggestions:

  • Show the selector popup with a "nothing found" message.
  • Do a wider "did you meant?" search when nothing is found, so the selector always shows at least one item to pick from.

Good points.

But enabling it and "tricking" the user into clicking a dysfunctional button, just to show an error message, is worse I feel.

It would at least show the information the user needs to carry on. I suggested this because it matches the behavior when URLs are saved. In general, I would much prefer a validation that shows it right away that there is a problem and how to fix it.

Same for saving dysfunctional values nobody else can later use or fix

Yes… I'm torn. I really like the Wiki concept of having "dysfunctional" links, but, indeed, I have no idea how an equally working thing would look and behave like on wikidata.

Show the selector popup with a "nothing found" message.

Yes – that is a good idea. I suppose, what makes it confusing that I can fill the field with letters that don't resolve to something and that they silently stay there after it is clear that they don't match – for the user it looks like "I entered [useful] information.

I try to mock up that.

Lydia_Pintscher triaged this task as Low priority.
Lydia_Pintscher added a subscriber: Lydia_Pintscher.

I think we solved a fair bit of this issue with the addition of the "no match found" message.

Agree. Though we should keep in mind T138748 to have a solid, and maintainable structure for error message handling.

@Jan_Dittrich, I believe this is mostly solved with the addition of the "No match was found" message as well as T170531: Semantics: Make recognized property and value look different than unrecognized input. Feel free to reopen if you disagree.