Page MenuHomePhabricator

Form Validation and Error Messages for Enable Registration form
Open, In Progress, Needs TriagePublic

Description

Overview
Error messages inform users that there is an error and how to correct it. For an error message to be effective people have to see and understand it, find the fields in error easily, and shouldn't have to memorize the error.
Based on the above principles, the form should use inline validation where possible, that is validate the information in the field as soon as the user leaves the field for another(before submitting the form) and the error message should be displayed below the field. This is illustrated in the image below

Add Registration Form (1).png (1×1 px, 178 KB)

Fields that can be validated without submitting the form:

  • Date, time, and timezone
  • Location - meeting link, address
  • Social media chat group link

Next Steps:

Event Timeline

gonyeahialam changed the task status from Open to In Progress.Apr 6 2022, 10:00 AM
gonyeahialam created this task.

@Daimona @cmelo Any comments on this?

There are actually three layers of validation:

  1. By the browser: this is e.g. for ensuring that required fields are filled, or that if a field expects a URL, you entered a valid URL. How this errors are presented to the user depends on the browser. For instance, chrome reports these errors as soon as you try to submit the form, preventing the submission.
  2. Field-level validation: this happens automatically in MW, and it uses some basic validation info about the field that we provide when building the form. For instance, it checks that the event page exists and is in the event namespace, it checks that the date and time were provided (this cannot be done on the client side because the field actually uses multiple input elements), etc. These errors are reported under each field, like the image in the task description shows, after the form is submitted.
  3. Additional validation: this happens within our extension's code, and performs some deeper checks. For instance, it ensures that the end date is after the start date, or that the address was provided if the event is physical. These errors are also reported using MessageWidgets when the form is submitted, but they are grouped above the form, and are not per-field.

Moving some things from layer 3 to 2 should be possible, although we should avoid code duplication. Moving from 2 to 1 is not always possible.

Hi @gonyeahialam, thanks for the information provided.

So for the fields that could be validated without submitting the form, since we do not have it with the components we can use, we can check (and probably create a phab thicket asking the right team to implement this), and if it is not possible or not ready yet when we finish V0, we could try to do it on our side.

@cmelo @Daimona Have you moved the error messages from the top to below the respective fields in error? cc @ifried

@cmelo @Daimona Have you moved the error messages from the top to below the respective fields in error? cc @ifried

No, that is T305690, but it seems that we decided it would be done for V1

@cmelo @Daimona Have you moved the error messages from the top to below the respective fields in error? cc @ifried

No, that is T305690, but it seems that we decided it would be done for V1

Yes, it is for V1. I just confirmed it in this doc.