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.
- me@example.c
- me@example.co
- me@example.co.
- me@example.co.u
- me@example.co.uk
And you'd have to account for all those tricky race conditions happening there
But then you run the risk of your password of being submitted to the wrong portal no?
> And also the hundred other sites that don't need federated flows but think they need to copy this feature as well
Very true. It seems to be becoming increasingly prevalent :(
Pisses me off too
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.
> 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
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.
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.
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.
(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.)
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.
I hope this helps.
This can't be a large majority. I only ever hear complaints.
Whats wrong with the suggested way (Harvest example) of having both on the same screen and letting the user choose