That is quite useful however with some federated auth flows, where you just need the email to see where to send them for the actual auth (e.g. Office365 and SAML login), otherwise you'd needlessly be entering your password.
I also much prefer it to the previous way e.g. Office365 worked, where once you'd tabbed away from the email box, they'd detect you needed to be redirected and send you off, whilst most people had begun typing their passwords.
Dropbox does an AJAX request when you enter your username, and it's fast enough that when you get to the password field it's already greyed out if you use SSO.
This should be the answer. As soon as the user enters a valid email (regex test) send a request to server to figure out what path they need to go down in the “federated flow”. What we shouldn’t do is diminish the experience for some because the flow for some others is different.
Yeah, federated flows were my guess too. However, the password fields could have been present and hidden in the same page supporting both password managers and avoiding a page transition. And also the hundred other sites that don't need federated flows but think they need to copy this feature as well. Together it's annoying to hit password managers twice for every login.
Pretty sure that is why... you enter your username and it checks to see what authentication flow to use, if it's a password flow then you get a password screen.
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, and overall login attempts dropped.
It's not perfect, but all indicators are it's better than a screen full of options - it allows us to guide users to the correct action.
Sure, it can still be annoying, but less so than what it was.
The way google does auth is also two screened, email -> next -> password
But! the "screen" is fake. the password field exists and is visible to the password manager (but not the end user) right off the bat, so it doesn't disrupt them.
But the user experience is extra poor, because they do not honor the Accept-Language header, but insist to use the local language of your public IP address. When travelling that can often be a language you don't understand. And when travelling you often get an extra security step, because they haven't seen you in that country before. Extra painful in a language you don't understand.
Disclaimer: I use Cookie Autodelete and Firefox containers. So they get a bit less info about me than about the average user. But ignoring Accept-Language makes no sense to me. Pretty unlikely the user does not understand the language of the browser but the local language of the IP address.
It's extremely common that Accept-Language headers are wrong because people don't know how to configure their OS or browser with the right language preferences, e.g. they add their language preference second or not at all.
Sounds weird to me. 99% of the users probably don't configure anything. (So do I, because I don't see the need. My preferred language is the language of my operating system. Otherwise I would change it in the operating system.) By default the browser should send Accept-Language the same as the localization in use. It doesn't sound likely that people would use the browser in a language they don't understand.
Google is the developer of the most popular web browser. If this is really a common problem, they can make UI changes to their browser to make that more accessible. It is not so hard to imagine a way to do it for even the most casual users, e.g. maybe using something similar to the Google Translate headers I notice when I use Chrome.
Besides, I have difficulty believing that this is a common problem. I have never seen a user whose OS was configured to a wrong language. Even if they have zero computer knowledge, they just ask someone else to fix it as the first thing. Computers/smartphones are already scary for technophobes; they wouldn't even touch them when they are in a language they don't understand.
This is especially irritating for VPN users as it is not just a problem when traveling, but all the time. I essentially gave up on hoping to get Google pages in a language that I understand. However, they made the situation worse in the past year: even if I use my country's localized Google domain, Google ignores that and gives me results according to my IP: websites from a different country about a possibly irrelevant subject, in a language I don't understand.
OMG yes. We went with "choose the login option" and it sucked. Everyone created multiple accounts (we didn't support combined identity at the time) and it just..sucked.
Not that I disagree, but we have possibly the world's most boring login system with nothing but email/password and even then people manage to create multiple accounts. And then john.smith@example.com will email us, asking why the facilities they set up last month aren't working any more, completely failing to mention that they set them up using their john.smith.666@example.com account.
Maybe I'm not following things right, but instead of doing it this way, why not have the screen with email and password (and whatever else - forgot password, submit button, etc) - but have the screen do the check on the email - and if the flow is different, change the screen (remove fields, change labels, etc), or redirect to a new screen?
That way, those that use password managers could still continue so (as it would check and see that yes, password flow - or whatever), but for others, it would do something else.
Imagine a real world equivalent: a store that loudly states "Membership card needed for purchase", but in actual fact have massive exceptions if you do try and purchase without a membership. This wouldn't be a smart business decision (how many non-members do you know who fill their prescriptions at Costco).
The password field in this scenario doesn't have to be visible. As long as it's attached to the DOM the password manager can still fill it. Then you make the password field visible if the email address doesn't match a known SSO integration.
You can do this without it being two separate views. Send a request on lose focus of the username field to check if the account is from a federated service.
What reasons are there to avoid doing this asynchronously?
(Please note that I’m opposed to requiring user agent javascript to access something claiming to be a website, but let’s assume we’re talking about something behaving like a single-page application post-authentication anyway.)
I'll give my perspective as a web dev, it can be tricky to time the requests and decide when to query the API asynchronously.
Consider a user starts typing an email address, when do you send out the first async request to find out what authentication flow is required?
On each onChange event, first time the email is valid, would have issues that your email is foo@bar.com, but foo@bar.co is already valid, so you're probably going to debounce the call by a few hundred ms.
What if the user makes typos, or if they are typing in the email very slowly, and so on.
You might say it doesn't matter, just don't show any UI feedback until its valid, or keep refreshing the current status, but the problem is your control flow is decided by the email that's typed in. You want to redirect certain users to an SSO page, others to type in their passwords, and so on. susan13@domain.com might need a different authentication flow than susan13@domain.co, which are both valid addresses.
Another choice is the onBlur event, but this becomes clunky. Think about when it's triggered and how you would incorporate this into a nice UX, I don't think it's possible.
The inversion of control, giving the user time to fill the form in, and press an explicit "Ready, I've typed my correct email in, what's next?" button, makes the flow easy to code.
This is so true it hurts. It honestly sounds like a pretty great idea, so I can see why product would be behind it. "We won't have a login experience like other providers, it would be a total $BRAND_EXPERIENCE_HERE" Then you start getting into the weeds and it's really just not possible to do well.
Dropbox manages to provide both fields, but instantly switch the password to be a “sign in with blah blah” when you’ve typed your email and it recognizes it as using a different provider.
I also much prefer it to the previous way e.g. Office365 worked, where once you'd tabbed away from the email box, they'd detect you needed to be redirected and send you off, whilst most people had begun typing their passwords.