Page MenuHomePhabricator

Semantics: Make recognized property and value look different than unrecognized input
Closed, ResolvedPublic

Description

Story: As an editor, I want to see if my input has been recognized

Example: A person is typing in the property to make this a "geocoordinate" property. However, the person makes a tippo and the system fails to communicate that there is a problem.

Severity: Hard to say, since we tried to help people along in the test to not have them stuck for too long, but I assume it is

Not recognized:


Recognized:

--> No difference

There is a not recognized warning

But as soon people tab or click out, it disappeares, which is relevant, since users who see that the interface does not behave as expected often click other elements in hope to resolve the problem, here particularly "save" (which is not activated due to the "malformed" input.

Proposed solution: Make recognized properties/values appear different than plain text input, e.g.

This has the nice effect, that we can establish semantics that, once learned can be used in other places, too.

Details

Related Gerrit Patches:
mediawiki/extensions/Wikibase : masterAvoid !important in entityselector where not necessary
mediawiki/extensions/Wikibase : masterIndicate recognized/unrecognized input in entityselector.

Event Timeline

Restricted Application added a project: Design. · View Herald TranscriptJul 13 2017, 9:36 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

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.

Restricted Application added a subscriber: PokestarFan. · View Herald TranscriptJul 24 2017, 3:30 PM
thiemowmde added a subscriber: Jonas.

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.
Jakob_WMDE moved this task from Proposed to Doing on the Wikidata-Former-Sprint-Board board.

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!

Jan_Dittrich added a comment.EditedAug 22 2017, 12:54 PM

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.

abian added a subscriber: abian.EditedAug 28 2017, 8:52 PM

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

thiemowmde triaged this task as Low priority.Aug 31 2017, 3:11 PM
thiemowmde removed a project: Patch-For-Review.

Can we consider this "done" for now, or should we still add the "x" and checkmark symbols?

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

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

Jan_Dittrich added a comment.EditedSep 4 2017, 5:11 PM

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.

Lydia_Pintscher closed this task as Resolved.Sep 18 2017, 3:13 PM