Improve errors reporting in edit modal

[MisRob]

Summary

Currently, we use a generic message displayed on the top of the edit modal to communicate errors. That can be confusing especially when a problematic field is out of view. A user needs to scroll down to find out what is wrong.

Example - a missing license:

Let's improve it.

Real-life consequences

Confusing UX. It can be a problem especially for historical data that don't have a license even when it's required due to looser validation of the old Studio.

[MisRob]

As discussed with @jessicaaceret and @rtibbles, a first iteration could be to add a list of links to problematic fields underneath the generic error message. Although it goes against some of our design principles, it would allow us to release it as soon as possible to help people experiencing problems with historical data. This solution doesn't require new translation strings. For this first version. no new designs would be needed.

[radinamatic]

There aren't perfect solutions in case of multiple problematic fields that fail validation. In case there is only one failing, we should bring the user immediately to the position of the field in question and focus should be inside/around the field.

If there are more than one, suggestion by @MisRob is a good starting point: a bulleted list of labels of the failed fields as links under the error message, each link bringing the user's focus inside the field in question.

[FidalMathew]

Can I work on this issue?

[vkWeb]

@FidalMathew Done!

[FidalMathew]

@vkWeb do we have to include all the types of errors possible?

The mastery involved methods are related to "goals". I'll map the errors to "goals" if required. Please let me know what your thoughts are.

Also, one doubt, Does the error list only change on every "finish" submission or dynamically?

[vkWeb]

@FidalMathew Hi, good questions!

do we have to include all the types of errors possible?

Yes.

The mastery involved methods are related to "goals". I'll map the errors to "goals" if required. Please let me know what your thoughts are.

I don't understand fully what you are talking about. Create a PR with your best judgement and we will iterate on there.

Also, one doubt, Does the error list only change on every "finish" submission or dynamically?

On submission.

---

cc @MisRob if in case I might have answered wrongly.

[MisRob]

@FidalMathew Thank you, this is looking like a good progress.

Sounds good to me, @vkWeb, thank you.

One thought is that I think we can display errors gradually in a meaningful way, for example if M of mastery model is not provided, in the first validation run we would only display the message saying that M is required rather than displaying all three error messages (required, whole number, greater than zero). Then, after M is provided, we can follow-up with more granular error messages if needed. The reason behind this being that there are many errors that can happen on the modal, and I think this will prevent from overwhelming people. @jtamiace @radinamatic Sounds good?

Also, I assume that the screenshot is work in progress so no problem, but ultimately translated error messages need to be displayed rather than constants.

[MisRob]

Actually @FidalMathew I think as first step you can only focus on validation of missing data that is required and follow the design in @radinamatic's comment #2924 (comment).

We can talk about some other improvements of error messages (e.g. M greater than zero) later on. We will need to consider placement of such errors and strings at first though from design perspective. So I think it will be simpler to focus on the part that's specified at this point which is that related to "required".

[AlexVelezLl]

This was fixed in #4404