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.

Yeah, google might do it technically smart.

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.

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

"[..]" was a list of all the problems that frustrated people before the stepped process.

Oh, I see, thanks. The list sounded to me like a description of the stepped process, so I was confused.

Choose login method first = frustration (users may not remember what IdP they used) Stepped process = drop in complaints

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.

That is good advice. And I would get behind Brad promoting that as a design pattern.

This feels similar to the VRFY problem in SMTP. Input an email address and find out their auth provider?

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.