When a user has entered something that doesn't match a property, there should also be some indicator of the fact that it won't be accepted as input. Gmail does a red underline as if the word was misspelled for example.

Accepted:

Not accepted:

These images come from a blog post about design and accessibility.

They were intended to illustrate the purpose of using more than one kind of signal to show the error state in a form.

Mostly posting here for reference.

I like the "pill" suggestion. It does have a lot of advantages. But at the same time I think it still has to many issues:

• It does not solve the problem that unrecognized input still looks like everything is ok. This can only be solved by making such an error-state more obvious.
• Please do not use red underlines as this style is already used by the browsers spell checker.
• I suggest to stick to the orange shading we already use to highlight errors. (The easiest way to see it is to add a "URL" property and try to save some random text thats not a URL.)
• Make sure the error styling is only applied if the field looses focus. It should not turn red the moment the user starts typing the first few characters.
• I suggest to simply change the input field into a static link if it is valid, and make it identical to all existing property labels. The only issue with this suggestion is that the user loses the ability to change his mind and edit the property after it was recognized. I think this is acceptable. I strongly suggest to play around with this idea. It's so trivial both for the devs and for the user. There is just no fancy widget. The user can click "cancel" and start over if he changes his mind. There is even a major advantage: I can hover and click the link and discover the property page before the new statement is saved. This is currently not possible.

But the pill does look like the input field could handle multiple values. This would be interesting for values(!),but confusing for properties.

look like the input field could handle multiple values.

@Sjoerddebruin : Yes, that is a good point. We should reconsider and find an alternative to a pill while still showing that the input was recognized by the system.

@Jan_Dittrich any update on what this should look like? I think last week we decided to highlight the input field according to its status as a first step without any pill behavior.

@Jakob_WMDE No particular input yet

I think last week we decided to highlight the input field according to its status as a first step without any pill behavior.

Yes. There was the open question of highlighting the whole item in orange (like we do at another error occasion – is there any screenshot of it?) or just highlighting the input field. I would opt for the latter.

Change 370628 had a related patch set uploaded (by Jakob; owner: Jakob):
[mediawiki/extensions/Wikibase@master] [WIP] Indicate recognized/unrecognized input in entityselector.

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

@Jakob_WMDE can you add a screenshot of what the current patch would look like?

@James_Budday the current patch is more of a proof of concept (not meant to be merged this way) and simply highlights the input field in bright red or green.
Let me know if you have a suggestion for what this could look like!

So I created a plausible error state:

Red border and cross icon: #b32424
Red background: #fee7e6

…the "recognized" state is more difficult. I would ideally go with something that is pill-like, but not too much, since you can have multiple pills, usually.
Also, I would like to display a check mark, but we already use it as icon for save. But this would be the best thing I can come up with:

Green Border and checkmark icon: #14866d

Would that work for properties and values? I assume it should be considered that properties and value display might look differently in the future.

Those mockups look good to me.

Some users can expect the x to be clickable with the purpose of clearing the field (or even closing/ignoring something), as that's usually the behaviour of the regular x in WIMP. I think that a more stylized x, another symbol or a different idea could avoid this confusion.

Placing two checkmarks next to each other, one clickable (save) and the other non-clickable, both with different meanings, doesn't seem a good idea either. However, in my opinion, this is less confusing than the x.

I agree with @abian in that a more stylized x could be beneficial although I also see how the current x does not suggest clickability just from its appearance. I also agree that the two check marks next to each other are not a very elegant solution.

We could also consider not using the symbols at all. This would make it less accessible for colorblind people though, although a color change should still be recognizable. In this case it might be worth considering removing any marking from the accepted term and just leave it as is to make the difference stand out more since there are only two states to consider, correct? @Jan_Dittrich @Lydia_Pintscher

The latest patch has the icon-less version for now.

Change 370628 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Indicate recognized/unrecognized input in entityselector.

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

Change 375008 had a related patch set uploaded (by Thiemo Mättig (WMDE); owner: Thiemo Mättig (WMDE)):
[mediawiki/extensions/Wikibase@master] Avoid !important in entityselector where not necessary

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

Change 375008 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Avoid !important in entityselector where not necessary

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

In this case it might be worth considering removing any marking from the accepted term and just leave it as is to make the difference stand out more since there are only two states to consider, correct?

Yes, would be OK with me. We should add a title= attribute though that allows to get a popup with "value recognized"/"Value not recognized. Choose one from the suggestions" (and same for other input types, but with the type instead of "Value" and possibly without the "Choose…" if the type does not have suggestions)

@Jakob_WMDE: Is the title="… possible to add to the field?

@Jan_Dittrich It is possible to add the title attribute. Ideally this would be a message that works for items and properties, since the selector widget is generic and only gets the entity type passed as a parameter for the API request. It's not impossible to have specific messages for the two types though, just a little ugly code-wise.

I'll move this to done for now. If we want to add the title attribute we can open another ticket for that.