Page MenuHomePhabricator

[Solution] Value checking and saving: Error messages, no silent fails
Open, NormalPublic

Description

Story: If a user adds invalid input in good faith we should inform the user immediately that the input can't be used and offer a solution the resolve the problem so that the user can finish what he/she wanted to do.

The proposed solutions are meant to resolve the following usability issues: T138365, T138312. Also, it may alleviate T138499.

Proposal:

  • Indicate that input is invalid on the input field via inline validation. If possible do the validation on input. If that takes too much resources, defer by n seconds or do it when the cursor leaves the input field.
  • Offer a way to call up information about the nature of the problem and how to resolve it
  • If a save button is used for several input fields (thus it may not be clear, what causes it not to save or to be inactive), the save button itself should also offer the above possibilities.
  1. Mockups
    • The input field gets a thin red outline. In the input field, an error indicator appears. Also, the save button indicates that saving will not work.
    • Same if a field of a qualifier or reference is not valid.
    • If the user hovers or clicks the indicator, the error message is shown
    • If the user clicks the indicator on the save button an error message is shown, too (we do not need to show them at the same time as shown here for demonstration purposes)
    • If the user folds a group of entry fields (thus hiding them) there needs to be an indicator that shows that there is a problem in this group of fields.
    • In the future we may or may not stop to hide the message behind an indicator icon. That would look like in the image below. We should not make it too hard to switch to such an solution.

Event Timeline

Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJun 27 2016, 9:46 AM
Jan_Dittrich updated the task description. (Show Details)Jun 27 2016, 9:49 AM
Jan_Dittrich updated the task description. (Show Details)
Jan_Dittrich updated the task description. (Show Details)
Jan_Dittrich updated the task description. (Show Details)
Jan_Dittrich renamed this task from Value checking and saving: Error messages, no silent fails to [Big] Value checking and saving: Error messages, no silent fails.Jul 4 2016, 8:48 AM
Jan_Dittrich renamed this task from [Big] Value checking and saving: Error messages, no silent fails to [Solution] Value checking and saving: Error messages, no silent fails.
Jan_Dittrich moved this task from Reported Wikidata to General topics/Epics on the WMDE-Design board.
Jan_Dittrich added subscribers: daniel, Addshore.EditedJul 5 2016, 1:26 PM

Talked about it with the team.

A concern is that the validation happens currently server-side (don't trust the client etc. ) and would be bad if we would need to replicate the code client side.

We could just do it on save, but @thiemowmde noted on T138312 that this is not a nice way either (aside of line-validation performing much better in tests)

So one decent way would be to send the data to the server, e.g. after 300ms and have the validation result send back to the client.
It may be too costly for some values but it would be already great if we could provide an easy way to resolve most of the errors via inline-validation.

If there are specific questions regarding the nature of the errors (e.g. a particular value is too costly to check but maybe it happens very rarely anyway) we could log it (would need consultation with @Addshore to prevent huuuuuuge logs)

@daniel, @adrianheine – did I get this right?

Tobi_WMDE_SW added a subscriber: Tobi_WMDE_SW.

Added it to Wikidata-Sprint-2016-07-19 so we don't forget it next storytime.

Jan_Dittrich moved this task from Review to General topics/Epics on the WMDE-Design board.

Error handling of the VisualEditor on Wikipedia:


this one also fails silently

Jan_Dittrich added a comment.EditedJul 12 2016, 2:48 PM

Short summary of the planning in regards to this on 12.7.16:

Quick Fixes: T140085 (autosuggest shows "nothing found"), T54843 (expand error message on default)

Interface-wise:

  • Concerns about a checkmark indicating that the value is real-world truthy and not just technically correct.
  • We need at least 3 states: Unresolved, OK, error. And maybe a 3.5th one that is like "unresolved because we can't reach the server"
  • Some Errors will not relate to a specific input field. @daniel : Which are those?

Architecture:

  • We could generalize the preview API for the send-and-recieve part.

Thats what preview currently looks like in the UI:

This comment was removed by Jan_Dittrich.

@Jan_Dittrich Errors that do not correspond to a single input field:

  1. Uniqueness constraints on the combination of language, label and description: the error applies to the three fields together (one line in the term-box). Currently, you can edit terms for multiple languages at once, so there may even be multiple conflicts for clicking save once. Finding out which error belongs to which line is tricky. Also note that the constraint check is pretty expensive (see T74430). We don't really want to do this before saving.
  2. Uniqueness constraints on sitelinks (on the combination of site ID and page title): the error applies to the two fields together (one line in the sitelink bar). Currently, you can edit links for multiple sites at once, so there may even be multiple conflicts for clicking save once. Finding out which error belongs to which line is tricky. Also note that the constraint check is pretty expensive (though not nearly as expensive as the check for terms). We don't really want to do this before saving.
  3. When editing a Statement, it's possible to add an URL as the main value, 3 qualifiers, and as part of 2 references. That's 6 URLs that may fail to validate once the user hits save. If we do real-time validation, this isn't a problem though. In that case, the correct control should always be known.

I'd like to repeat my suggestion from the Story Time session:

Tell the save button why it is disabled. There are already code paths that update the save button's state to enabled or disabled. It should be simple enough to indicate the reason via the same code paths. Even if it's still unclear how this information will be shown, and if we also want to show it elsewhere, I believe this is worthwhile doing.

As to the architecture: we should generalize real-time validation for the widgets for all data types. The delayed-update-while-typing part is already there for some data types (the ones that have previews), we should have that for all widgets. We should also improve our server side API to allow for a full parse/validate/format cycle in a single request.

I would personally also suggest to generalize our preview mechanism, but there was no agreement on this point. If we had a preview area for all data types, we could use this as the generic place to display validation failures.

@daniel :

  • on "Errors that do not correspond to a single input field": that seems manageable. We would need to find an alternative location for the error and maybe convey that it will not be checked live. This is best determined in a user test anyway.
  • on the suggestion: Yes that makes sense to me. I can't estimate how this all will play together (so infos for the save button will take a different path than the info for the fields?).
  • also on the suggestion: It would make sense to display failures in such a place. Semantically it would make sense if the preview and the error message data are easy to tell apart technically on the client side (come in different JSON-properties or so)

so infos for the save button will take a different path than the info for the fields?

As far as I understand, they have to, because the save button lives on an entirely different level of the code as the input field. They also have different cardinality (a single save button can save the content of dozens of input fields).

Semantically it would make sense if the preview and the error message data are easy to tell apart technically on the client side (come in different JSON-properties or so)

That's already the case, of course :)

Lydia_Pintscher removed Lydia_Pintscher as the assignee of this task.Aug 18 2016, 9:39 AM
Lydia_Pintscher added a subscriber: Lydia_Pintscher.
thiemowmde triaged this task as Normal priority.Aug 31 2016, 7:33 AM
Volker_E moved this task from Incoming to WMDE on the Design board.Jan 5 2017, 5:45 PM

@WMDE-leszek, @Aleksey_WMDE: This issues was one that seemed to be difficult to implement.