Open bojanz opened 4 years ago
Thank you for your time to make this issue.
It took me some time to answer because I wanted to take a moment and write an article with some considerations that others might find helpful eventually.
https://estevanmaito.me/blog/killing-the-confirm-password-field-is-not-enough
It'll take me some time to add this to the project, as I still need to update it to match the React version, but for those who want to apply the best practice right away, just swap the "Confirm password" field with a check box saying "Show password".
Logic for it should be as easy as changing the input type
from password
to text
Like this:
@estevanmaito I've just read your article, here are my 5¢:
If you use email addresses as primary key, the password can be omitted entirely:
NULL
password (impossible to sign in) and send an email which both confirms the email address and asks the new user to set the password for future sign ins.How did people listen to an article of bulls**t suggesting that password confirmation field is all useless? And that a "show password" button can be a substitute for it?
People may register an account on a public place, and they may not be able to reveal the password at any second, but only to rely on their muscle memory to ensure they typed the password correctly. When revealing password is not an option, users have to rely on the confirm password field to catch mistakes. Both "confirm password" field and "show password" button have their uses, why not have both feature and not drop any of them?
The behavior can work like this: By default the password is masked, and that user has to retype to password to confirm it, but if the user clicks the "show password", the confirm password field goes away and the user verifies their password by eye. Win-win for both use cases. https://ux.stackexchange.com/a/518
How did people listen to an article of bulls**t suggesting that password confirmation field is all useless? And that a "show password" button can be a substitute for it?
@Explorer09 Because it's not. The article talks about conversion, you talk about security in public places.
The behavior can work like this: By default the password is masked, and that user has to retype to password to confirm it, but if the user clicks the "show password", the confirm password field goes away and the user verifies their password by eye. Win-win for both use cases.
That's indeed a good compromise to accommodate both concerns. But it's more work to implement.
(If it's too much work, I personally prefer the disclosure feature over the confirmation feature. Why? If I mistype, there's always the "forgot password" workflow to restart. And since I don't use passwords without a password manager, I really don't need confirmation fields. Disclosure, however, comes in handy if I have to type a password on the mobile phone (where I don't use the password manager due to safety concerns). I can always turn the phone such that nobody can spy as I quickly check what I typed. But the alternative, having to type a fully random 20 all kind of characters password twice is a major pain... and any typo forces you to repeat the whole. Now that certainly is poison for conversion at best, encourages weak passwords at worst.)
@svoop Just to clarify, I'm not against the "show password" feature for many websites, but I am against people talking about "convertion rate" or UX while compromising users' security in this regard.
When a feature just works to protect the users' security, it's really tempting to remove it in the name of "convenience" or anything. Some people want this extra safety just to prevent locking themselves out of their accounts. And don't tell me about they can reset the password with an email -- they may not even know they have mis-typed the password until next time they login.
Perhaps the only alternative to the "confirm password" field is to force users to log out and re-log in to complete the whole sign up process. Without this, the user may not be aware of the error or it might be very late when they know it.
create-account.html has a "Confirm password" field. This solves the problem of a user registering with a mistyped password, but requires the user to retype the password twice in case of an error. For a number of years the web dev community has been advocating for the removal of the confirm field, replaced with a link/icon that shows the password. This increases conversion and lowers user frustration. It is now the default pattern on mobile, and common on many sites. Large sites like Twitter and Facebook also no longer include a confirm field.
So, my feature request is to implement a show link or icon inside the password field, and remove the confirm field. This article shows both options: https://uxmovement.com/forms/why-the-confirm-password-field-must-die/
Which look (link/icon) do you think matches Windmill's design more?