Inline field validation

Inline field validation

• display field-based errors when…

  • leaving the field (onBlur)?

  • trying to submit an invalid form​

• generally concentrate on clear labeling!

Inline field validation

• skip browser validation (<form novalidate>) ✅
• be forgiving with inputs instead of enforcing technical limitations

Wordings

Wordings

• more natural, less technical language!
  • "problems" instead of "errors"​
• concise and plain language
  • pleasantries like "please" get annoying fast and imply a choice
  • users want to focus on getting the correct message across instead of being treated nicely
• generally think about a conversation between humans instead of interactions with a machine

Wordings

Andrea Drugay on A Word to the Wise: Writing Product Copy to Transform Your User Experience

https://vimeo.com/297829604​

When do we disable the submit button?

Never disable the submit button

• It's not always clear why something is disabled:
  • What's wrong? Why is the button not clickable?
  • Is it about pristine/dirty fields? Which fields are relevant?
  • Do I have to wait for something?

• bad for screen readers (focusability)
• one exception: saving/loading state!

final-form provides all the metadata

Keep it simple

Keep it simple

• labels (and hints) above input fields work best

• do not use input placeholders
  • they make it harder to find empty inputs
  • they disappear while typing anyway
• use semantic HTML for best compatibility and a11y (ARIA should be last resort instead of default)

Some more interesting ideas

HTML Page Title Validations

• using html page title for validations (quasi notification):

✅ We already do this for in-app notifications.

Checklist Affirmation Pattern

MailChimp example:

One thing per page

• https://designnotes.blog.gov.uk/2015/07/03/one-thing-per-page

• advantages:
  • focus
  • simplicity
  • momentum
  • …