Add form validation for correct/incorrect committee ID in RAD form

[JonellaCulmer]

What we're after:
We need to consider and design for the addition of some form validation in the RAD form. Based on the changes here, we should consider making these changes consistent across the spectrum of FEC-related digital forms.

Specifically, the RAD form should include validation for the committee ID input. We need to inform our users whether or not a correct committee name or ID had been input and if not provide feedback so they know to fix it, rather than submit and incorrect form and be forced to start all over again.

Action items:

• Consider which form field elements, including reCaptcha, require validation
• Document other usability concerns

Completion criteria:

• Open implementation ticket with desired form validation changes
• Open followup tickets for other usability concerns

[JonellaCulmer]

Convo about tracking errors: https://fecgov.slack.com/archives/C3X3K6EVA/p1611254477001600

[JonellaCulmer]

Below is a list of each of the validation-related improvements we should include on the RAD analyst form:

• Add inline validation for each required field. When a field is not completed properly, we should provide immediate validation as to whether or not the input is accepted.
• Trigger inline validation only after the field has been triggered by the user and either abandoned or input is insufficient.
  • Abandoned: User clicks on the box, does not type any information and clicks out of the box. Only after this happens should an error message be triggered and the other fields should not be affected until the user interacts with them.
  • Insufficient input: Email address is not valid, example: [email protected]. Or, committee name is not a valid committee name
• Add next steps when the submitted form results in an error
• Provide easy path to submit another question on the error message, similar to how we do for successful submissions.
• Add language that states users will receive a confirmation email for successful submissions.
• Make error states consistent. If a user does everything except check the reCaptcha box, they get an error and the form repopulates. It does not with the other error state: bad committee ID
• Address page refresh issue after receiving error. Hitting refresh on the page, results in the following message appearing at the top of the browser. Hitting continue does not refresh the page and the error is still present. I have to leave the page entirely and come back to it to start the form over again.

Extra:

• We can improve the call to action button language to speak to the actual task and update the button to Submit your question
  cc: @bmathesonFEC @rfultz for your awareness

[JonellaCulmer]

@patphongs @dorothyyeager @rfultz @bmathesonFEC
Please see the below mockups for improved form validation. There's also the matter of the pop-ups that occur if the user attempts to submit the form without completing the missing sections. I'm wondering how much control we have over those pop-ups. How much can we alter them, if any?

The mockups include the form itself, and success and error messages. Would like thoughts on the language for the validation messages as well as the success and error messages.

For the error message, we currently have two different versions: when the reCaptcha has failed and when a bad committee name or ID is included. Would love for folks to try to break the form to see what other error messages occur to make sure we're accounting for all the possibilities.

Form validation

Success message

Error message

[dorothyyeager]

For the contact information prompts, suggest changing "include" to "supply" (since that's the only thing we are asking them for). The rest makes sense to me.

[bmathesonFEC]

This is a huge improvement. Thank you for taking this on! I love it.

My only comment is about "Not passed for human." two notes on that:

1. is that standard language for websites that have recaptchas? I personally like question people in this way, but I think it might be confusing because of this comment:
2. I can't find a way to get to that error message by failing the reCaptcha. I tried failing it as a human but I can't... because I am one! I tried failing it by setting my browser as a bot, but I just get asked to identify traffic lights or cross walks over-and-over-and-over again by reCaptcha. If you (or @rfultz, @patphongs) don't know of a way to advance to that error page by failing the reCaptcha, then I suggest we remove references to being a human.

What do you think?

[JonellaCulmer]

@bmathesonFEC This is what I believe the error looks like when triggered by the reCaptcha:

[bmathesonFEC]

Yeah, that's definitely not informative. Yours is way better. I'm on board with all of your edits. Thanks for taking this on!

[JonellaCulmer]

@bmathesonFEC @patphongs Okay, great. I'm wondering though if we should retain the separate error messages, but make sure they are similar in appearance. Right now the error messages appear in two different places with different language.

Any thoughts on that @patphongs? I can certainly design for both and whoever picks up the implementation can see what the technical limitations might be for each.

[patphongs]

@JonellaCulmer The form error messages are currently using default browser errors, which is the tooltip error that you see. I like the inline validation in red, which makes it more clear about what's needed to submit the form. I have a few comments below:

1. The required fields that you have look correct to me, but there's one more interaction that needs to be documented. When you choose in the Subject field "other" in the drop down, a subject text field will appear below the subject dropdown. The subject text field that appears is not required, we should probably denote this with an (optional) in the label.

2. When do you want the inline validation errors to appear? Will they all appear only after a user attempts to click submit?

3. Since we are going with inline error validation, I would suggest not doing the default tooltip browser errors so that it will not conflict with the inline errors.

[JonellaCulmer]

Thanks @patphongs

The required fields that you have look correct to me, but there's one more interaction that needs to be documented. When you choose in the Subject field "other" in the drop down, a subject text field will appear below the subject dropdown. The subject text field that appears is not required, we should probably denote this with an (optional) in the label.

@patphongs Thank you, I didn't look at Other. It should look just like the "Your position or title" field:

2. When do you want the inline validation errors to appear? Will they all appear only after a user attempts to click submit?

Are we able to prevent the user from submitting with inline validation only?

3. Since we are going with inline error validation, I would suggest not doing the default tooltip browser errors so that it will not conflict with the inline errors.

What kind of conflicts are you imagining? Currently, when a user attempts to hit submit with in an incomplete form, the page scrolls up to that field and displays the tooltip. Are you saying the conflict is in displaying both?

[JonellaCulmer]

@bmathesonFEC Per Pat's first comment, I'd rather we remove that extra field than keep it. Is there a business need for the "Other" subject line when we require users to provide their question as well? We already require so many fields, if we can limit them, I'd like to lean in that direction.

[patphongs]

@JonellaCulmer

Are we able to prevent the user from submitting with inline validation only?

Yes, if there is anything that is invalid on the form, the user will not be able to submit until those errors are resolved.

What kind of conflicts are you imagining? Currently, when a user attempts to hit submit with in an incomplete form, the page scrolls up to that field and displays the tooltip. Are you saying the conflict is in displaying both?

Correct I think it would be a conflict displaying both. We wouldn't want a scenario where the tooltip would overlap on top of the inline validation errors. So choosing one method is best.

[bmathesonFEC]

Go ahead and remove the extra field for Subject after the user picks Other. After doing a few tests, I'm not seeing that the data collected in that field gets carried over into our system. Even if it is getting pulled into an obscure location that I'm not seeing, removing it won't disrupt our work RAD. As the main data user in RAD, I can vouch that it wouldn't add much value if we were getting it.

[JonellaCulmer]

@bmathesonFEC Thank you for looking into that. I'll include a note to remove the subject field in the implementation ticket.

@patphongs Thanks, I'll elaborate further when the error validation should trigger in the implementation ticket and note we should remove the tooltips.

Closing this ticket in favor of implementation ticket #4354