Comment 3 for bug 1764365

In 2014, I wrote error design guidelines for Ubuntu app developers. The relevant part of those guidelines was that when an error occurs, it should be described “as close as possible to the place where it occurred, and as soon as possible after it occurred, without being distracting”. <https://goo.gl/gEzmut> The password shortness message achieves the goal of being as close as possible to the place where the error occurred. Unfortunately, it misses the other two.

First, it doesn’t wait until after the error has occurred. I’m sure you realize that whether “the password so far is too short” isn’t the issue; the issue is whether the whole password is too short. So when can you tell what the whole password is? If someone enters example@@example.net as their e-mail address, you can highlight that as soon as the second “@” is typed, because nobody will have done that intentionally. If someone enters insufficient characters in the password field, then unfocuses the field, you can highlight it at that point, because there’s very little chance they did that intentionally. But if someone enters one character in the password field, and *doesn’t* unfocus the field — well, every single person who isn’t using a password manager is going to do that, regardless of how long their password will be! So most of the time that the message ever appears, it is incorrect.

Second, it’s distracting. As soon as you type the first character, the remainder of the field slides down to make room for the incorrect message. The combination of (a) the animation, (b) the incorrectness, and (c) the usual masking of password characters, increases the risk that you’ll forget what you were starting to type.

Both these issues would get even worse if, at some point, U1 adopts the standard Vanilla styling for form fields. As soon as you typed the first character of your chosen password, the field border would change to red, with a stop icon appearing at the end. <https://docs.vanillaframework.io/en/base/forms#validation-classes> That behavior is fine when an error occurs. But in this situation, it would be even more unpleasant and distracting — because an error has not occurred.