Back in the old times, on the sites I log in regularly, my browser filled in both username and password. I clicked “Log in” once, and I was set to go.
But no more. Now it’s all first a username, then a password. From what I saw, Apple started this many years ago, but now this bother really spread. And it’s not like I can just double-click on the same screen area, oh no. Animations make sure that I have to wait several hundred milliseconds before the password field is there, and depending on the site, I even have to select from my browser, which login I want to use, twice!
Why, oh why?
All my screens are really big enough to display 2 text fields. What are arguments for this behavior? I don’t see any.
Similarly, platforms that default to a massive CREATE AN ACCOUNT box centered on the screen and make you play Where’s Fucking Waldo trying to find the size 8 “Log In” hyperlink.
Because new signups are more valuable than existing users.
That, plus the majority of users seeing the login screen are probably new. At least, unless it’s one of those annoying sites that makes you log in every single time.
Federation. Your email address could either be local creds, or federated with google, Microsoft, Facebook, Apple, etc.
When you submit your email address, it determines how you will be authenticating when you submit it.
That could be done after the user enters both the email/username and password
Edit: sorry, I think I misunderstood what you said, but if someone is using something like “sign in with google”, we’ve had separate buttons for that for ages.
I think it might solve the problem that people often don’t remember if they created their account using SSO or with an email/password combo. So the site looks up your email to see what login method you use in order to redirect you to the proper prompt.
Yes, with a limited set of federations you can have the user make that choice beforehand. But sometimes the options are changing all the time and/or you don’t want to announce all the services you’re federating with, or it wouldn’t make sense anyway.
Nowadays it is possible to set up many services in such a way that you authenticate in a different way from a password, for example with an app on a smartphone. Such services can’t ask you for your password until you have told them what account you want to log into because it might turn out you have to give them something other than a password.
It started as defense against credential stuffing and a speed bump against brute force attacks. Not only is it additional loads for a bot to do, but passive captcha can be put between the steps. Now I think its becoming fashionable.
Brute force attacks through web interface cannot be a real thing. Performance is much too bad to get anywhere even in great scenarios, plus its be simple to defend against.
But even if, web automation tools don’t need to be bothered by separating input fields. In the end one request is sent anyway.
This is a ux thing.
There’s two reasons I can think of. One is direct resistance by services to password auto-fill during the aughts (it was new and scary) and separating the account field and pass field defeated auto-fill detection at the time. Amazon separated account and password around then and it’s been that way since.
The other is your secret picture, a preventative measure against phishing attacks used by banks and other commercial interests, When you create an account, you’re asked to select a stock image and a phrase that the site shows you when asking for your password. That way you know it’s really the bank’s site and not a phishing site.
Right now I think I have only one web account that uses such a protection.
It still gets filled in by all browsers I have. From usability point of view it’s less chance someone press enter after putting in their login name thus leaving the password field empty and getting refused. This will often lead to a disruption friction of their workflow (don’t know the proper English word)
The JS to detect an empty password field and only enabling Enter
onchangeis way simpler than the code for two separate pages. I actually implemented the former once.Sure - but quite often it’s about doing what’s easy for the users/customers rather than programmers
How is that easier for users? You mentioned one point but I counterargued that the problem can be mitigated in other ways.
I’m not saying it IS a better solution, just that it might be. Did you do any usability testing on the two solutions and want to share some insight?
And I do think that if your decision on UX comes down to what’s easy to code you are wrong.
