Required field validation

[silviatc]

Required field validation needs UT.

Possible solutions:

• Marked required fields + marked optional fields + grey disabled submit button that turns coral once required fields are filled out
• unmarked required fields + marked optional fields + coral submit button + if clicked without required fields, browser validation lists them http://www.crimsondesigns.com/blog/wp-content/uploads/2012/10/validation-cartoon-bubbles.jpg
• (recommended) unmarked required fields + marked optional fields + grey disabled submit button that turns coral once required fields are filled out. If grey disabled button is clicked, inline errors show up under required fields

Research: http://uxmovement.com/forms/always-mark-optional-form-fields-not-required-ones/ http://www.lukew.com/ff/entry.asp?725 http://ux.stackexchange.com/questions/73728/should-form-continue-button-be-disabled-if-validation-is-incomplete https://css-tricks.com/form-validation-ux-html-css/

[silviatc]

From design meeting:

• two types of validation: inline and after form is submitted (eg. forgotten field) -- inline validation REQUIRED for password fields
• look at error color. Coral is already used for CTA
• add suggested corrections ("did you mean gmail?")
• consider form length

[silviatc]

Notes for design break-out session:

Required/Optional Fields

• Optional fields: use (optional) in label
• Required fields: no further styling required

Literally including the phrase “optional” after a label is much clearer than any visual symbol you could use (eg. an asterisk) to mean the same thing. Also, when you mark a form’s required fields, it jeopardizes voluntary over-disclosure and makes users skip optional fields. (source 1) (source 2)

Form Validation (source 1) (source 2)

• Client side (real-time) error validation: occurs while the user is completing a form (examples: using the wrong characters in a numerical field, leaving a required field blank, etc.). The error validation occurs either when the user has stopped typing within the input field, or when the user has clicked or tabbed away from the field or control.
  • When to use:
  • the user has input information that does not meet the requirements of the field or form
  • If your form is simple, short, and fits in a single window (like a sign up form) use only inline callouts (see real-time validation.)
  • for emails, we want to suggests a right domain when your users misspell it in an email address (eg. after entering tom@gail.com, it would tom@gmail.com). For implementation help, look at the documentation.
  • for the most part: trigger the error as soon as we are sure that there is an error (usually on focus change/onblur)
• Server-side error validation: occurs after a form has been submitted. If an error is detected, the form refreshes and depending on conditions, is either displayed inline, or as a page-level message that cannot be dismissed plus inline callouts.
  • When to use:
  • a required field has been left blank (trigger: onsubmit)
  • if a problem occurs after the user has submitted a form.
  • if your form is complex. If the error is associated with fields within the page, in-line error messaging is provided at the field or control level and also cannot be dismissed. In this case, the page-level error message displays a generic message about the error state, but relies on the in-line error messaging to communicate the specifics of the error.
• Asynchronous Errors: detected some time after the related interaction (examples: an email bounced back due to a delivery error, some aspect of the transaction failed permanently, etc.). This type of error is displayed globally as the user may be in a different section of the application when the error is detected.
  • When to use:
  • there is a delay between the user action and the error (example: email not sent because of delivery error)
  • the error is at a global level (example: credit card information is incorrect)
• For all forms:
  • Disabling the button prevents our chance to tell the user what is wrong. The user keeps clicking the button and is totally in the dark why nothing happens. Keep the button enabled. Let the user click the button. Then show the message why it can’t proceed.
  • All the validations must be coded twice. Once for the client side Javascript Validation and the other for server side validations. The validations need to be repeated on the server side because it is possible to bypass the client side validation.

Action items: pick a client side and server side form validation library (see here)

[hardboiled]

@silviatc FYI, mailcheck JS seems a little bloated from looking at the code. If we end up wanting to implement a JS checking solution, we might just want to see what domains we support and lump it in with any existing regex checking we do against email addresses. I would be happy to help with the implementation as needed.

[silviatc]

@hardboiled wonderful! We're meeting today about validation so for now, I'll edit my comment with your fix and update as needed. We're meeting at 5 at Center Stage if you'd like to join... always helpful to get a developer in the room.

[silviatc]

From design breakout session with @GeorgeTaveras1231 @rutu9 @jameree @leetaniau: The goal was to create a system for alerts and notifications, and use that to build out documentation for form validation.

---

Alerts and Feedback

Style	Example	Trigger
Inline		Real time Server side (related to field)
Toast		Server side (not related to field)
Block		Server side
Modal
Tooltip
Overlay

---

Form validation

• Use inline, real-time feedback wherever possible
• Use toast feedback with back-end issues
• After submit, use inline feedback if not already triggered
• Always enable the submit button. Disabling the button prevents our chance to tell the user what is wrong. The user keeps clicking the button and is totally in the dark why nothing happens.
• All the validations must be coded twice. Once for the client side Javascript Validation and the other for server side validations. The validations need to be repeated on the server side because it is possible to bypass the client side validation.

  ---

  Required/Optional Fields

• Optional fields: use (optional) in label
• Required fields: no further styling required

Literally including the phrase “optional” after a label is much clearer than any visual symbol you could use (eg. an asterisk) to mean the same thing. Also, when you mark a form’s required fields, it jeopardizes voluntary over-disclosure and makes users skip optional fields. (source 1) (source 2)