It's a huge bummer to read articles that enumerate problems, but provide no solutions.
The solution would be to have clear guidance with labels/hints and present clear feedback when the user presses submit. We know that when a user presses submit, they are ready for the feedback. As opposed to the host of problems faced with inline validation.
I'd contend that when a user presses submit they're ready to move on, not to be taken back up the page to make changes.
Yes, they wish to move on, but they may have made a mistake. We know that they want to move on when they submit (as opposed to type/blur).
In which case, makes sense to show them their mistake then, without interrupting them.
This is inherently why I can't be bothered reading most things posted to Medium - it's a platform to have a whinge on, but not much more.
I'd say you've identified some important problems to consider, but many of these are symptomatic of lazy implementation, rather than problems with the concept of inline validation.
Some can be overcome with more intelligent validation methods. For example, I wholeheartedly agree that throwing errors on the user's first keystroke is a mistake, but using a label with informative messaging rather than throwing errors could helpful here and in the Facebook example (#2), there is no reason to validate an empty field on blur, that's not an error yet.
I also really love the concept of 'one thing per page' but the example you linked still uses inline validation.
Is there an example of inline validation that doesn't suffer from (some of) the problems mentioned in the article?
but the example you linked still uses inline validation.
What uses inline validation? I don't follow.
I think I'm a little confused as to whether you mean real-time error validation (showing errors as they occur) or inline (showing errors where they occurred). The Kidly form example you give on your linked article uses inline validation in that it has the errors with the form elements. (https://www.smashingmagazine.com/2017/05/better-form-design-one-thing-per-page/)
I unfortunately don't have any great examples, but I don't think removing timely feedback for the user is the answer.
Yes was talking about real time “live” feedback.
In field messaging is definitely a good thing for several reasons.
counterpoint: it also can be good.
Whilst the logic of your argument is perfect, there is no stats to back it up.
To be fair, there were no stats backing up your original argument.
I was joking.
You could be more robust in your validation logic. For example, if real time validation on value change is prone to errors too early, but blur is too late, then you could set the validation to be based on value change, but on a timeout. That way, after a user has been inactive in the form, the validation could fire. Follow that up with a just in time onblur callback for the form itself to fire validation when the form has exited.
"One Thing per Page" doesn't solve these problems, it merely spreads the theoretical effects of validation across multiple pages. Perhaps it will lead to better conversions because like information is being requested but your arguments against focus and blur validation are still a problem here. Validating on "next step" is the same as validating on "submit form" with the exception of having to deal with fewer errors per page but errors none the less. You're still throwing the user back to reassess what is wrong with the form they filled out.
The point about One Thing Per Page was it shortens forms, meaning users get feedback after filling out each field.
Although i agree with some points, it's hard to argue that something it's problematic because "i said so" and no data to back you up (except from point 11). :/
By data, do you mean quantitive data? Or is qualitative data enough? I've seen people experience the problems I've demonstrated in the article. I didn't make them up. I don't have an agenda to demote a perfectly valid design pattern such as inline validation. :)