181–190 of 520 posts
The worst offender I have seen in the wild is treasurydirect.gov. The password must be click in on an online keyboard, and they do not allow password managers to enter the passwords. Screenshot here: https://en.m.wikipedia.org/wiki/TreasuryDirect
Earlier quoted context omitted.
Bingo. This is why we went with a stepped process. Did you log in with Google, Twitter, Enterprise SSO, or Email? Do you even have an account, maybe you need to create one? It frustrated everyone. Since we've implemented the stepped process (and made other changes) complaints have all but disappeared, and the number of failed sign in attempts has been significantly reduced, successful logins has increased slightly, a…
Your comment confuses me, can you clarify? > This is why we went with a stepped process. [..] It frustrated everyone. But then: > Since we've implemented the stepped process (and made other changes) complaints have all but disappeared
Earlier quoted context omitted.
Bingo. This is why we went with a stepped process. Did you log in with Google, Twitter, Enterprise SSO, or Email? Do you even have an account, maybe you need to create one? It frustrated everyone. Since we've implemented the stepped process (and made other changes) complaints have all but disappeared, and the number of failed sign in attempts has been significantly reduced, successful logins has increased slightly, a…
Your comment confuses me, can you clarify? > This is why we went with a stepped process. [..] It frustrated everyone. But then: > Since we've implemented the stepped process (and made other changes) complaints have all but disappeared
Earlier quoted context omitted.
Or god forbid you try and use a non-English password... Unicode exists for a reason.
All character related issues disappear when you hash the password. There is no problem here. Hashing the password should be the very first step taken on the backend when receiving login data, so any special characters should be neatly isolated to a part of the code that can handle UTF-8.
While that may be doable, it would require aggressive testing to actually work... for a feature that's a. not necessary and b. of interest to a tiny minority of users.
And users have to get text into the form. You're allowing users to shoot themselves in the foot if they use accents and then using a keyboard without those accents or one where entering the accents is very tedious.
(1) Multi-step sign in flows – as noted in other comments here – are incredibly useful for any product which supports multiple authentication methods. The email is used to point the user in the right direction, versus putting the cognitive load on them to know their own authentication type, or making them enter their password multiple times.
(2) Magic links are incredibly useful in a few places: an example would be something you use infrequently (and thus won't remember your password and/or have a cookie clear between sessions), something where you're typically authed via SSO (same deal – you won't remember your password, etc.), or where you need to sign in via mobile. Mobile sign in, in particular, is really frustrating with special characters. Most users remember that they hit shift+5, they don't remember that that translates to "%". However, they almost ALWAYS have an email client with an active session. Magic link emails are a great way to help that user get into the product with minimal pain.
Generally, I'd assume that most companies have put a lot of thought into this (Google, Slack, etc.), and they don't deviate for "fun", they support these patterns because there's an established user need.
Source: experience as a PM on sign in flows across a number of products.
There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.
1Password handles this just fine. You just have to hit the button twice.
Provide the normal, separate username and password fields, and if both are filled out proceed normally.
If, however, the username is blank but the password is not, check to see if the value in the password field contains internal white space.
If it does, split it on the first run of internal white space, taking the resulting two strings as the username and password.
This allows entering both the username and password with a single paste operation. This would be convenient for people who are managing their passwords via some mechanism that cannot automatically fill out fields in their browser.
Earlier quoted context omitted.
What's the benefit of doing it that way?
Your web browser doesn't have any connection to your password manager. Who knows what your web browser is doing, why would you give it any access to your credentials?