Open eakl opened 3 months ago
Hello, I'm sorry for the late response. I see what you mean, but my main design principles are:
Make sure that: (1) the user can figure out what to do, and (2) the user can tell what is going on. -- Don Norman, "The Design of Everyday Things"
Rule 2 is why they are kept, to avoid problems after a "sequence break", for example if you step away from the computer and come back, you are put back into context.
Not all users are adept at computers, they need hand-holding until things really work (that is, all the errors are actually fixed). The mental model for live feedback cannot be cheated, then users stop trusting it.
I found out this closed issue and I really think it should be shipped out-of-the-box (punish on submit or blur, reward on change). Let me explain.
@ciscoheat, this article you reference as the validation method that brings the highest user satisfaction is from 8 years ago, and while the idea is IMO still the best one (reward early, punish late), its implementation is not the best.
The problem with the
validationMethod: 'auto'
implementation is that it validates late but doesn't reward early enough.IMO, error messages are annoying. I don't want to get them as soon as I start typing in an empty field because I want the validator to assume I'm smart enough to understand the requirement (punish late).
If I made a typo or misunderstood the requirement, I want to get a clear error message that points to my mistake.
But as soon as I understood my mistake and know how I'm going to correct it, I don't want to see that error message. The validator should assume that I know what I'm doing now and I'm going to type it right (reward early).
Currently,
validationMethod: 'auto'
is holding my hand until I reach validation in an erroneous field and it's annoying because in my mind the error has already been corrected.This is used at Google and Apple: Google: https://workspace.google.com/business/signup/welcome Apple: https://appstoreconnect.apple.com/login