Designing form validation the right way

Designing form validation the right way

94c767fbe5e2ce7ba74e9833c8e03d45?s=128

Damian Nicholson

January 19, 2018
Tweet

Transcript

  1. DESIGNING FORM VALIDATION THE RIGHT WAY

  2. @damian

  3. None
  4. None
  5. Lot's of data entry

  6. Add an event • Speakers • Sessions • Sponsors •

    About • Tickets • Tax and invoice data
  7. Add an invoice • Customers • Products and services •

    Bank accounts • ...
  8. More questions we ask = more chance our users do

    something wrong
  9. What can we do to facilitate our users journey?

  10. Real time inline validations

  11. Concise snippets of feedback given to the user before, during

    and after filling out their web forms
  12. None
  13. No as widespread as I'd have anticipated

  14. Major E-Commerce sites containing inline validation in checkout 40% 60%

    https://baymard.com/blog/inline-form-validation
  15. "Inline Validation in Web Forms" https://alistapart.com/article/inline-validation-in-web-forms 3 groups of participants

    1.No inline validation - control version 2.Poorly implemented inline validation 3.Well implemented inline validation
  16. "Inline Validation in Web Forms" • Accurate • Faster •

    Confident • Satisfied https://alistapart.com/article/inline-validation-in-web-forms
  17. How many of you have been shown an error message

    either before or while updating a field and been left confused?
  18. EXAMPLE

  19. Customer complaint story

  20. It's "meant" to give immediate user support and guidance

  21. None
  22. https://baymard.com/blog/inline-form-validation 12% 40% 48% Major E-Commerce sites containing inline validation

    in checkout
  23. Recap • Inline validations are necessary to enhancing our users

    journey and making them more confident and happy • <50% of major online E-Commerce players either aren't doing it or are doing it incorrectly • Losing money • Alienating users
  24. Why is that?

  25. Implementation issue

  26. Every product I’ve worked on with inline validation has been

    prone to regression and flaws
  27. Prior art • jQuery validation • AngularJS built in validation

    • HTML5 validation • redux-form* • ...
  28. 4 key challenges that need to be overcome...

  29. #1 Handling user driven state changes effectively

  30. #1 Managing state • Low level or poor APIs e.g.

    HTML5 validate API • Generally a one-to-one mapping between fields and validations • Different fields respond to different event life-cycles for capturing their values across different types of validations e.g. onChange, onBlur, onKeypress • Poor support for adding validations dynamically if (country = 'UK') { // do post code validation } • Poor support for asynchronous field validation and how to reconcile these with synchronous validations
  31. #2 Poor styling support and inflexible error output

  32. #2 Poor styling support / inflexible • HTML5 field validation

    messages aren't able to be styled consistently and are wrong • All in one solutions require you to use their form fields which can be a huge burden and means your bound by their styling output as to how your fields look
  33. #3 Impossible to align backend data constraints and error messages

    with the on the client
  34. #3 Constraint alignment • Only possible for very basic field

    validations and messages • JavaScript based stack alleviates that to a degree • Most other solutions basically copy and codify constraints and error messages so are prone to misalignment over time • Impossible to cover all use cases regardless of stack e.g. username uniqueness, date overlaps
  35. #4 Accept server side validations exist always

  36. #4 Constraint reconciliation • How to reconcile errors generated from

    the server and any subsequent errors on the client? • What takes precedence when?
  37. 4 key challenges 1. Handling user driven state changes effectively

    2. Poor styling support and no control over markup 3. Impossible to align backend data constraints and error messages with the on the client 4. Accept server side validations exist always and how to reconcile them
  38. 4 key challenges 1. Handling user driven state changes effectively

    2. Poor styling support and no control over markup 3. Impossible to align backend data constraints and error messages with the on the client 4. Accept server side validations exist always and how to reconcile them
  39. + few design choices = ConferizeForm* +

  40. React • Rendered HTML is colocated with events it makes

    attaching these easier • Makes handling UI state and as an extension of that dynamic form state a breeze • Smoothes over browser quirks for event lifecycles e.g. onChange • Heavily favours composition • Controlled forms have a consistent easy to use API
  41. https://codesandbox.io/s/14l2mjrr3l

  42. ConferizeForm* we've extended that concept further

  43. https://codesandbox.io/s/jnyv95r26w We just inject methods and data Your form Ultimate

    flexibility in terms of styling
  44. Dan Abramov

  45. Key point is that ConferizeForm* holds all the form state

    which is passed down to your component as props
  46. Example state

  47. Composable validations • Pass an array of validation functions or

    just one function here, so you can compose them using ES6 imports • The validation functions are run in the order they're passed in • Validations bail out as soon as the first one returns any errors https://codesandbox.io/s/jnyv95r26w
  48. Form level validation context • Allows you as the developer

    to work at the form level context for handling validations as you get the entire form state to work with and inspect • You also get access to the eventPhase as these validations are run both onChange and onBlur https://codesandbox.io/s/jnyv95r26w
  49. Dynamic validations https://codesandbox.io/s/jnyv95r26w

  50. Asynchronous validations • Notice that all validation functions are Promises

    https://codesandbox.io/s/jnyv95r26w
  51. Reconcile server and client side validations • Store the server

    side validation message and value which prompted the message • Accessible through initialErrors in validation function - developers can do what they like with it - choose to use it or ignore it
  52. Back to challenges...

  53. 4 key challenges 1. Handling user driven state changes effectively

    2. Poor styling support and no control over markup 3. Impossible to align backend data constraints and error messages with the on the client 4. Accept server side validations exist always and how to reconcile them
  54. 4 key challenges 1. Handling user driven state changes effectively

    2. Poor styling support and no control over markup 3. Impossible to align backend data constraints and error messages with the on the client 4. Accept server side validations exist always and how to reconcile them
  55. 4 key challenges 1. Handling user driven state changes effectively

    2. Poor styling support and no control over markup 3. Impossible to align backend data constraints and error messages with the on the client 4. Accept server side validations exist always and how to reconcile them
  56. 4 key challenges 1. Handling user driven state changes effectively

    2. Poor styling support and no control over markup 3. Impossible to align backend data constraints and error messages with the on the client 4. Accept server side validations exist always and how to reconcile them
  57. Inline validation is absolutely necessary but difficult to do right

  58. General do's and don'ts when building forms

  59. User feedback generally ought to happen after they've left the

    field
  60. Use feedback while a user is filling out a field

    only in certain scenarios but use an appropriate delay e.g. username uniqueness, password confirmation
  61. Don't ever disable or hide the submit button

  62. Give users positive reinforcement where possible

  63. Ensure any positive feedback given doesn't fade away and keep

    it consistent
  64. Don't make 'nice to have' fields required

  65. If your unsure where to add inline validations, focus more

    on fields which require some user thought to fill out
  66. Don't enforce restrictive formats on users - let the system

    do it for them
  67. Questions?