Designing form validation the right way

Transcript

1. DESIGNING FORM VALIDATION THE RIGHT WAY
2. @damian
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
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
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?