As an AWS consultant, I work with a lot of client companies and I’m often watching a screen share while they are navigating through the console. I haven’t seen one yet that actually logs in to AWS directly and not use some type of SSO solution.
I personally definitely agree with "Don't make customers hunt for the Sign In button on your website", since I find that so annoying. I've come to expect this annoying behavior especially from Y Combinator companies, ever since I read Paul Graham opining that companies should actually emphasize the trial/test-drive button, and deemphasize the sign-in button. He said that's what Viaweb did, and they thought it made better business sense. I just now tried a bit finding the essay where he states this, but I gave up. Maybe someone here will offer it.
This is becoming more and more common with major sites, and it’s really bloody annoying. Some are putting “Sign In” behind some tiny dropdown in the nav, not just grayed out or small but invisible unless you hunt for it.
They know exactly why they’re doing though, and I think OP is preaching to the converted. Those doing this don’t need a tutorial explaining how not to do it, they need to lose money (users) until they stop doing these dark patterns.
They probably have metrics suggesting that having both sign up and sign in buttons on the page leads to lower sign up rates than having only a sign up button, or something along those lines.
Rather than find a more in depth/better designed solution, it's easier just to remove the "sign in" button and any "confusion" that might cause for users who would otherwise complete the sign up workflow. If their A/B testing indicates that removing the button improves sign up rates, that's exactly what they'll do.
It's super-annoying and short-sighted - not to mention lazy - but this kind of micro/over-optimisation of behaviour on the web has been de rigeur for at least a decade now.
A better approach would be to try to understand why "confusion" around sign up/sign in is happening - i.e., what's the real reason having both buttons/links on a page decreases sign up rate? Root cause the issue and you can fix the real problem in a way that probably doesn't annoy your customers. That's effort though and most customers probably don't care enough to complain about the annoyance of hunting around for a sign in button or link.
The trend of the not having a log in button and only a sign up button, requiring multiple clicks just to login. I get that less friction for a new user is better being the thinking but I truly hate having to go through multiple pages just to sign in.
What happened to having sign in/sign up being on the same page? Seems the simple and easy, as well as lowest friction way of splitting the difference between new and existing users.
I'm sure UX research shows that the login button is seldom used on a particular site, therefore not that important.
Why seldom used? Because you stay logged in for a long time.
Is UX bull on this issue? Maybe, but if you are logged in for a long time, and then you come to log in when you've been logged out, it might be that you accept the lousy experience on this issue because you actually want to use the site... all that said I wouldn't care if the UX research suggested it was a good move. I wouldn't do it (on anything I owned, I would just argue against it if asked to implement it)
UX research also shows that one of the most important things is consistency. Internal consistency as well as consistency with other websites the user is familiar with.
99% of sites don't have so many features and sections that they'd need to omit some of them from the landing page. But for some reason they think replacing UI elements with screen-filling fancy animations and a lot of empty space inbetween is somehow a good thing. I never saw any upside in this.
I have a short attention span and am easily distracted, and modern UI trends are catastrophic from my perspective. I don't care about a fancy "hero area", just give me a menu bar that stays in the same place and gets me anywhere I need.
Ahhh. I miss the days of the username and password being on the same page! I refuse to believe that the average internet user gets confused by a two field form that they need to break it into two (usually slow) steps. Re-architected in (usually flaky) javascript. That takes up (always more) of my time!
(sorry for the !!!'s. but this one really gets my goat)
Can’t you detect it client side? Send the contents of the username field to the backend, if it’s SSO change the password field to “login with ssoprovider.com”
It's even worse user experience since things change as you type (you have to wait for network round trip so it's not instant), plus password managers are still confused.
This one is a significant failure of our entire industry. We've somehow accepted that degrading user experience because of an implementation detail is good instead of working together to hide that implementation detail by implementing the necessary browser functionality.
We already have technologies such as Kerberos that are supported in every browser and seem like they would solve this problem.
In any case, as a website operator you can mitigate this. Have separate pages for SSO/non-SSO, dynamically hide the password field if the username is associated with an SSO provider, or just ignore the password field and have a subtitle along the lines of "leave password empty for SSO accounts".
It's not obvious to me that it's an improvement to have an extra textbox that goes away moments after you type in your email address (possibly after you've tabbed into it to start typing) or an extra textbox that just stays there unused.
A handful of websites I visit periodically have username and password fields readily available....but they are registration forms not login forms, and if you put in your existing credentials, it’ll just tell you that you already have an account and should log in instead. You couldn’t just, you know, log me in with the information I just provided instead of telling me to provide it again on a different page? Drives me up the wall!
I'm familiar with a few sites which used to be this way with the login form directly on the homepage, and removed those fields during the internet's transition period from HTTP to HTTPS for all pages. Browsers started flagging pages which included password fields as insecure, even if the form containing them submitted via HTTPS (which was arguably a fair assessment). The solution for many sites at the time was simply to move all login to a distinct page which was served over HTTPS, and leave all other pages as HTTP. Back in that day the opinion of many site operators was that HTTPS was going to tank advertising revenue, so they avoided it whenever possible until the browser vendors forced their hands.
In many cases the homepage login forms took years to come back, after we got to a point where virtually every site was all-HTTPS on all pages. In some cases they never did.
I love this pattern - I think it was Slashdot I first saw it on - but it still suffers from the same problem. What do you label the button - "sign up / login"? It's still easy to miss that it's also for login when scanning.
More clicks to log in than sign up is annoying, but what really bothers me is when they don't make it clear that the page brings you to both. Like if the button only says "Sign up" I'm going to look around for a bit for a "Log in" button first. If they're going to combine them, the least they could do is make it say "Sign up/Log in"
What's the problem? They have both "Sign in" and "Sign up" next to each other. Same color, opacity and the only difference being that there's a border around "Sign up".
I remember the same, but funnily enough, it seems to be fixed now, with both "Sign in" and "Sign up" buttons available on the top right. I don't remember how it was before, but I always started to create a new account instead of logging in.
This is what happens when everything is metrics based. Your paying customers pay the price. This happened with Loggly when solar winds bought them. We no longer use Loggly.
This is so common nowadays that for many sites I have the direct login page bookmarked. It indirectly implies that once you sign-up, the company stops caring about you. At-least for me.
It implies that because it’s literally true. Not a complete loss of care, but it makes sense to hide the sign in button because users who are already signed up are already invested, and less likely to abandon the service. The front pages main job is to grow the company by attracting new users, and a sign in button for users who aren’t going anywhere anyways gets in the way of that.
Inconveniencing either current or prospective customers never ‘makes sense’. It’s not like you have a fixed amount of inconvenience you have to distribute.
You have a fixed amount of screen real estate on the landing page. Distributing it to your most important users for that page (prospective users) does make sense to me.
Is the solution presented in the blog to utilize a cookie to determine if someone is a prospective user versus already a user not an acceptable compromise?
It seems rather straightforward to me, from their example, to de-emphasize the "Sign Up" button and prioritize the "Sign In" button for someone who already has an account.
While that may be the case (I'd also argue that the front page should be a welcoming place for existing users), showing me that you value your existing users is a great marketing move.
It's otherwise very hard to convey that you care about existing customers so this seems like a no-brainer.
Even the solution in the article seems to suggest using cookies.
I don’t understand the problem, if people want to try or sign-up for your service they’ll locate the signup button. That’s a one time problem. A hidden login button just annoys existing customers.
My feeling is that this is down to testing without privacy in mind. Your site might be fine, but others aren’t so a minority of users will clear cookies at the end of each browser session. That’s not a senario most will test for or experience.
There are some websites that are both super aggressive about timing out your session and also make you play hide and seek for the login button. Of the sites I use frequently UPS used to be about the worst offender but the most recent version of their site does have a usable login link.
Vanguard is another one that drives me up the wall. Going to Vanguard.com doesn't have a sign in area to autofill with a password manager; you have to go to the personal investors page. And sessions are hard limited to 15 minutes so you have to jump through these hoops every time. I have the correct page bookmarked but even on that page the log in boxes don't appear until half way down.
I also noticed this trend, but I don't understand the reasons, the site also doesn't explain it. Wouldn't it be beneficial to capture (and potentially track) existing users earlier? What's good in annoying them? Why are dominant sign in/register buttons mutually exclusive? What became of the trend of the reverse - large sign-in with a later option to register?
My cynical guess is that when companies A/B test this, they find that a clear sign-in button reduces the number of new sign ups (because if the sign-in button is hard to find, some existing users will create a new account). A/B testing is great but it's very easy to optimize for something that's easy to measure rather than what you fundamentally care about.
Plex’s responsive design hides it at the bottom of their hamburger menu in super low contrast gray-on-darker-gray text when your window is less than maybe 900px. It’s literally like they’re trying to hide it.
I keep my windows in a grid and I end up just making my window wider because it’s easier than using their god forsaken hamburger menu.
This is one of several reasons why I would never consider paying for Plex Pass again. The other reasons include spending a LOT of resources on rolling out features I imagine few users are likely to be interested in, such as DVR.
I wouldn’t go that far. I subscribe to Plex Pass happily mostly to support financially a service I adore and use daily. Features I don’t use don’t hurt me and they give you the option to disable things you don’t use.
The login button is just hard to find on the homepage.
And this can be easily solvable by swapping the Sign up for Sign In after the first time you logged in a browser cookiejar. Obviously the devil is in the details, but it shouldn't be that complex having a visible Sign Up for potential new users and a visible Sign In for existing users...
This could make it even more annoying imo. Sometimes the sign up button is the first thing you see, and then other times its the sign in button. You'd end up clicking on one or the other out of habit and realizing it was the wrong thing afterwards.
If I'm signing in, there's a good chance there is no cookie saying I have ever signed in.
Please don't! The worst thing is to swap meaning of a button at exactly same placement. If you are forced to do it then at least change background color and add some icon etc.
But nothing can beat MS Teams "Close" document preview button, which once clicked, uncovers chat "Call" button. Add some laggy nature of Teams and you call the entire channel/chat just by trying to close an opened document with too many clicks.
But that would not change "immediately". Basically if you never logged in (in that browser) you see the "Sign up" more prominently and once you registered, you are already logged in (so you don't see anything at all) but if you do log out, then you would see the "Log In" clearly (and the "Sign up" will be somewhere also but not in the best spot).
For https://sqwok.im, I explicitly placed the login/signup prominently at top right for all users on mobile and desktop because I want it to be clearly visible always. I could see some value in detecting whether the user has already created an account and highlighting the "login" portion like the author has.
There’s a business service site I have to log into once a month who’ve hidden the login behind a drop down and it’s really annoying!
Your site is really slow. I honestly thought it was broken when I first went, no login link to be seen at all.
This is why you should avoid making a SPA unless you know what you're doing, if you're going to use one at least put a spinner or something so it's clear the site's doing something.
> This is why you should avoid making a SPA unless you know what you're doing
The site doesn't have much traffic right now and is running entirely on serverless lambda, it's likely you arrived while it was idle and had to wait for it to wake up...
> at least put a spinner or something so it's clear the site's doing something
def should improve the loading state for when it hasn't woken up yet.
No login link, just a series of grey lines, even after I enable javascript. Ah, I see you require that I accept cookies just to to view your front-page ...
Heh, there was a time when Microsoft’s Polish translators (who I’m mildly convinced are robots in disguise) decided “Sign in” should be translated as „Zarejestruj”. Which is what everyone else called the “new account” button. They managed to fix it since then to a much more reasonable and much less confusing „Zaloguj się”.
I think Windows translators are real humans, because quality is much better than whatever Bing Translator spits out (seriously, who thought it was good idea to automatically redirect to Bing-translated MSDN pages), but translated completely without any context. For example, task manager now have RAM "Form factor" translated as "Współczynnik postaci"...
Translators for the Dutch version of Windows 10 are definitely robots. For example, in the save webpage dialog of Edge, they translated “Webpage, complete” to “Webpagina, voltooid”. Voltooid means completed, as in a completed task. The correct translation would have been “Webpagina (volledig)”.
Similar errors are often found throughout programs new with Windows 10 and sentence structures are directly copied from English. I have never found a single error in Windows XP/7.
English is my native language and I still call it "login" and "register", the words which were originally used and which I do not see any reason to change.
GitHub is awful for this. If you're not signed in, the whole page is taken up with a giant signup UI, then in the top right there is another signup button. Next to the signup button, there is a sign-in button, but it has no border and is so deemphasized that if you don't know it's there it blends into the other useless links in the top bar.
This pisses the hell out of me becuase, due to my privacy settings, I end up on their homepage a lot. Evidence just for records: https://imgur.com/a/HfF9vUJ
I was wondering if I was going blind for a while, staring seconds at websites trying to find where to login. Now I do what 'the computer illiterate' have apparently done for years; never go to the sites themselves, just put 'DigitalOcean login' etc in the addressbar (duckduckgo(or google)) and there you are.
And if you don't have an adblocker installed, the first 5 results will be adds which will get you to the home page, not the login page. At least in this case you make them pay for it.
When you receive an invitation to a server, you're presented with a textbox that reads "What should everyone call you?" and you're unknowingly creating a new account. Then you're asked your birth date and then for your email. You type your email and it's already used, obviously.
By this point you don't want to go through the whole process of deleting your browser history to log into your existing account, so you go along with the new account thing and use another email address.
Before you know it, you have 5 different accounts and don't remember which ones you use for which servers.
Yes, there is a "use existing account" link, but it's not prominent, the "What should everyone call you?" textbox with the big "Continue" button are the only psychologically viable option unless you've already gone through the whole process of involuntarily creating many accounts.
I had to create a Slack account to interact with a vendor support team. Run into that mess and can't for the love of god find a "manage all your accounts" interface on Slack. It's insanely counter-intuitive.
I'll avoid Slack as much as possible unless they fix this evil UX.
And when you access the site directly, you are always shown the front page which is basically a full-screen ad and serves no other purpose than user conversion. Furthermore, the sign-up link literally says "Open Discord in your browser" which can be read as "go to the app".
Ideally there was one single email address field and a combined sign up / sign in button that either took you to the password or new account creation dialog. If you're concerned about privacy implications, do realize that user signup forms leak the very same information.
it took me until right now to realize that this happened to me, and that I've been using the wrong account for the last six months and I actually have two accounts... so really, at this point my "wrong" account is my real one.
The reason it happened is b/c I use email aliases for stuff I sign up for, and sometimes I forget them...
I think discord is great but I do agree with you. The whole "join a new server" UX is in this weird place where you might not use it that often (even if you are a heavy discord user), discord having an unusual concept of servers, combined with the flip-flop dance between browser and native app.
The end result feels slightly off. Like I can't say what should be happening, but what is actually happening feels not quite right.
A tiny button is far from the worst: try logging into your paid account on the mobile website of a service that not only has a free tier but also an app! (I'm looking at you, Strava)
Another annoyance is when you can’t access their landing page until logging out (like visiting example.com redirects or just hyperscripts you into the dashboard if a session cookie exists). You log out, look for the info and then search for a login div again, where you have to spend another minute differentiating between the “bring on”, “chime in”, “lay along”, “sing in”, “growl at”, “give up” and other low-contrast cretinisms in place where explicit login and register links should be.
A couple of frequent mistakes with signin which are usually caused by junior product owners/ux persons not reflecting on what they are doing and blindly copying what they believe is the way to do things.
- Having confusing language and poor differentiation between the sign in and sign up form. Symptom, users start filling in the wrong form only to realize their mistake.
- Separating the password from the email field with an extra mouse click sucks if you are using a password manager. Doubly so on mobile where using password managers involve a bit of fiddly interactions. Having to do this twice sucks. If you do this, at least have one of the fields in the dom tree but hidden so that it gets filled with one click via your password manager.
- Not making the login form password manager friendly my not sticking to conventions for field names for this.
Even if password managers handle the two-page scenario you still have the delay of loading the second page. On high-latency connections this is a major problem.
> Separating the password from the email field with an extra mouse click sucks if you are using a password manager.
If I understand correctly, the reason behind this pattern is SSO.
Most websites are gaining SSO capabilities. Before asking for your email/user, they don't really now if you're gonna login using password, or you should be redirected to an IdentityProvider.
I'd be happy to know if there are better patterns here but I think password managers should get a bit smarter and work with this trend.
Honestly asking, what's wrong with "Password (Leave empty if you're using {Name of SSO}): ____"?
If you are going to tell that may confuse users, I think not having a password field is already confusing the other half, while also not being password-manager-friendly.
I don't think making the user read instructions is the solution. Most (myself included) will begin typing before they finish reading.
The current trend to only show the password box after the username is provided doesn't have to be bad for password managers. I use loads of sites that do this (so they can support SSO) and they just use hidden form fields so the password managers know what to do.
I'd be curious to hear any suggestions you have for password managers to improve here though. I can't think of anything short of a .well-defined login route.
My company uses an SSO provider with Google Workspace. Most employees have no idea about any of that, they wouldn't know and probably would type their company password there.
Firefox also handles every one of these perfectly. I assume there is a hidden password field already but whatever it is it doesn't cause me issues other than an extra click.
Most websites I've used where this is a thing, definitely don't do this. All the projects where I dealt with PMs / designers insisting on this they would not even had a clue about what SSO was or how it impacts their UX. There are plenty of websites out there with sane login flows.
Passwords work off well publicized naming conventions. That's why they work on the vast majority of websites. The problem is junior developers not knowing that is a thing getting creative with naming things. No-one on such projects even thinks about testing this or pointing out to their PMs that this does not work. 9 out of 10 times you'd get the response to "please fix that". Because why would you not.
They could just check if the username needs to be redirected, and if they do then ignore the password. It wouldn't be that hard.
The only downside is the user submitting a password they dont need to, but if you're using js you could post the username first and only post the password if needed. That would be the same exact process, except from the users perspective it would be seamless. You could even have it check the username as they type, and lock the password field if its not needed.
I could see a lot of large companies that integrate with other B2B sites recoil in horror with a UI that encourages employees to enter their corporate email address and a password. Many employees would use their corporate passwords.
this is exactly the sort of thought process that leads to terrible login flows. yes, it's technically possible, and it works for you.
but the login flow is one area of your product that needs to work for everybody. There's plenty of features that can be tailored to a power-user workflow because they're the only people that will see it, but the sign-in flow is not one of those. any confusing UI in your sign-in flow is going to confuse your least-confident users. and asking people using Facebook Sign-in to enter a password when they haven't ever set a password for your site is extremely confusing. all just to save a couple keystrokes for the most-technically-competent users.
Well for facebook, and any other big ones they could just click "sign in with facebook" thats common enough.
The problem is when you have a bunch of enterprise customers and you're not sure which custom login to use, and you dont want to list all your clients.
Ideally, this is solved by the client company telling its employees to use an internal link that authenticates and redirects. Though I'm sure not all clients are capable of this, and still want to use SSO. In that case, I think my solution is much nicer than requiring a two step login.
- Defocusing input fields in the middle of typing login information
I guess i'm in the minority these days but I like to keep strong passwords in my head.
This usually happens due to some side effect of the login page being absolutely fucking massive and not fully loading or executing before I start to fill in the form, then one of three things usually happens in order of frequency:
1. cookie banner blocks input and defocuses
2. it defocuses for no apparent reason (I suspect MVC "rendering")
3. it "helpfully" re-focuses on the first input element
The last one is the most annoying because in the worst case i type my password in visible text.
Only login I regularly use that does not suffer from this problem (or any others!), is HN:
I use Surfing Keys, a vim-like plugin for browsers. When inputs defocus unexpectedly while I'm typing all of the navigation shortcuts kick in and it's like "roll a d100 to see which random negative consequence you get." Usually I at least lose the page that I'm on and I have to start the form over.
This reminds me of when certain browsers used to emulate IE by mapping backspace to "go back". I lost so many forms to that feature before Safari came up with the "are you sure you want to leave without submitting this form you started filling out?" dialog and they copied it
Since I started using facebook (2010) until today, it happens to unfocus and is very weird. If I go to login page, start typing my email very fast, it lose focus after 1s even before I finish typing.
Right, often those sites have customers with different SSO systems. I type my company mail address and am redirected to company SSO.
I like this more than other sites where I have to find the right button between different login options (sign in with google, sign in with facebook, sign in with sso, ...) and then have to type the company name ... whatever might be the choice the admins did there that time ...
I also think that approach was initially created by Yahoo! So they could shown the user's avatar on the password page to prove authority. Not sure whether that still is a thing somewhere, considering that a recent trend is not to verify whether an account exists ...
This is always still annoying since you type in your email, then get sent off to your SSO page - and they can never be bothered to post your email over, so now you have to enter it again.
Agreed. It always seemed to me as analogous to the situation whereby one enters some identifying information in a phone prompt, only to have to spell it out again for a CSR. Both are just plain bad design.
I don't know if all of the SSO login sites do this, but Office 365 authentication makes it a huge pain in the ass to get back to the page that you tried to login from; usually you get dumped back to the home page, and have to try to navigate back to where ever it was you were.
Azure Active Directory does not make it easy to do this, with the way you have to explicitly whitelist post-back URLs, or else you get the dreaded login.microsoft.com 401 page of death, where you have to parse out information buried in the query-string to determine why you didn't get redirected properly (usually it is a trailing slash on the URL... %2F)
from the meeting where it was explained to me that we couldn't use "login", it is too technical-sounding and not friendly enough. "log in" is computer language, "sign in" is human language.
What is the origin of sign in? I imagine the old days when you needed to sign a book when entering premises? Is this the floppy disk for save action of web jargon?
As I said, English is not my native tongue. Choose whatever synonyms are appropriate. Even google translate gets confused. If I enter "sing in" it translates it to Spanish as "registrarse" which is actually "sign up"! How about using enroll, or register instead of "sign up"?
At the last big subscription company I was at, it wasn't a product owner seniority thing, it was a organizational problem.
Signup is a big thing with lots of stakeholders and interest. User acquisition is an easy metric to track for business health. Everyone wants to push not-logged-in users to sign up.
Ownership of logging in was much less clear. It's not a full time job for a person or team in the same way customer acquisition is. So you put some buttons/links on the page, but then there's no single owner of them to get pissed off when other teams start moving their shit around.
(The other aspect here is that the website was a declining platform compared to the apps, where a not-logged-in user is much more captive and there's a more obvious single "login or signup" landing page point. On the web most media sites, at least, try to provide SOME sort of preview/partially functional experience version of the logged-in view, which wasn't designed with a prominent "SIGN IN" button in mind.)
This is what is screams to me. When I have a hard time finding the sign-in link it says "We don't care about our existing users, we only care about getting new ones." It is a big red flag for me these days.
212 comments
[ 3.9 ms ] story [ 244 ms ] threadhttps://mixergy.com/paul-graham-design/
Kind of along those lines.
They know exactly why they’re doing though, and I think OP is preaching to the converted. Those doing this don’t need a tutorial explaining how not to do it, they need to lose money (users) until they stop doing these dark patterns.
Rather than find a more in depth/better designed solution, it's easier just to remove the "sign in" button and any "confusion" that might cause for users who would otherwise complete the sign up workflow. If their A/B testing indicates that removing the button improves sign up rates, that's exactly what they'll do.
It's super-annoying and short-sighted - not to mention lazy - but this kind of micro/over-optimisation of behaviour on the web has been de rigeur for at least a decade now.
A better approach would be to try to understand why "confusion" around sign up/sign in is happening - i.e., what's the real reason having both buttons/links on a page decreases sign up rate? Root cause the issue and you can fix the real problem in a way that probably doesn't annoy your customers. That's effort though and most customers probably don't care enough to complain about the annoyance of hunting around for a sign in button or link.
The trend of the not having a log in button and only a sign up button, requiring multiple clicks just to login. I get that less friction for a new user is better being the thinking but I truly hate having to go through multiple pages just to sign in.
What happened to having sign in/sign up being on the same page? Seems the simple and easy, as well as lowest friction way of splitting the difference between new and existing users.
Why seldom used? Because you stay logged in for a long time.
Is UX bull on this issue? Maybe, but if you are logged in for a long time, and then you come to log in when you've been logged out, it might be that you accept the lousy experience on this issue because you actually want to use the site... all that said I wouldn't care if the UX research suggested it was a good move. I wouldn't do it (on anything I owned, I would just argue against it if asked to implement it)
99% of sites don't have so many features and sections that they'd need to omit some of them from the landing page. But for some reason they think replacing UI elements with screen-filling fancy animations and a lot of empty space inbetween is somehow a good thing. I never saw any upside in this.
I have a short attention span and am easily distracted, and modern UI trends are catastrophic from my perspective. I don't care about a fancy "hero area", just give me a menu bar that stays in the same place and gets me anywhere I need.
(sorry for the !!!'s. but this one really gets my goat)
We already have technologies such as Kerberos that are supported in every browser and seem like they would solve this problem.
In any case, as a website operator you can mitigate this. Have separate pages for SSO/non-SSO, dynamically hide the password field if the username is associated with an SSO provider, or just ignore the password field and have a subtitle along the lines of "leave password empty for SSO accounts".
In many cases the homepage login forms took years to come back, after we got to a point where virtually every site was all-HTTPS on all pages. In some cases they never did.
It seems rather straightforward to me, from their example, to de-emphasize the "Sign Up" button and prioritize the "Sign In" button for someone who already has an account.
1. Less likely to abandon your service than prospective users
2. by far less likely to even see your landing page, since they’re usually already logged in.
In this specific context, your existing users are the less important ones.
It's otherwise very hard to convey that you care about existing customers so this seems like a no-brainer.
I don’t understand the problem, if people want to try or sign-up for your service they’ll locate the signup button. That’s a one time problem. A hidden login button just annoys existing customers.
My feeling is that this is down to testing without privacy in mind. Your site might be fine, but others aren’t so a minority of users will clear cookies at the end of each browser session. That’s not a senario most will test for or experience.
I was able to directly link this page however, which I bookmarked:
https://personal.vanguard.com/us/AuthLogin
precisely
Perhaps these are similar symptoms.
I keep my windows in a grid and I end up just making my window wider because it’s easier than using their god forsaken hamburger menu.
The login button is just hard to find on the homepage.
If a user doesn't sign up, they'll never login.
If I'm signing in, there's a good chance there is no cookie saying I have ever signed in.
But nothing can beat MS Teams "Close" document preview button, which once clicked, uncovers chat "Call" button. Add some laggy nature of Teams and you call the entire channel/chat just by trying to close an opened document with too many clicks.
There’s a business service site I have to log into once a month who’ve hidden the login behind a drop down and it’s really annoying!
This is why you should avoid making a SPA unless you know what you're doing, if you're going to use one at least put a spinner or something so it's clear the site's doing something.
The site doesn't have much traffic right now and is running entirely on serverless lambda, it's likely you arrived while it was idle and had to wait for it to wake up...
> at least put a spinner or something so it's clear the site's doing something
def should improve the loading state for when it hasn't woken up yet.
Why have two very different options with almost the same label?
Especially given that I have some insider knowledge on how large publishers translate tech books and the way they do it is, in one word, awful.
I think Windows translators are real humans, because quality is much better than whatever Bing Translator spits out (seriously, who thought it was good idea to automatically redirect to Bing-translated MSDN pages), but translated completely without any context. For example, task manager now have RAM "Form factor" translated as "Współczynnik postaci"...
Similar errors are often found throughout programs new with Windows 10 and sentence structures are directly copied from English. I have never found a single error in Windows XP/7.
Why, github, why?!
When you receive an invitation to a server, you're presented with a textbox that reads "What should everyone call you?" and you're unknowingly creating a new account. Then you're asked your birth date and then for your email. You type your email and it's already used, obviously.
By this point you don't want to go through the whole process of deleting your browser history to log into your existing account, so you go along with the new account thing and use another email address.
Before you know it, you have 5 different accounts and don't remember which ones you use for which servers.
Yes, there is a "use existing account" link, but it's not prominent, the "What should everyone call you?" textbox with the big "Continue" button are the only psychologically viable option unless you've already gone through the whole process of involuntarily creating many accounts.
I'll avoid Slack as much as possible unless they fix this evil UX.
Ideally there was one single email address field and a combined sign up / sign in button that either took you to the password or new account creation dialog. If you're concerned about privacy implications, do realize that user signup forms leak the very same information.
The reason it happened is b/c I use email aliases for stuff I sign up for, and sometimes I forget them...
The end result feels slightly off. Like I can't say what should be happening, but what is actually happening feels not quite right.
I know it is a blog but still it's part of the website and as a customer I should be able to access "Sign In" with one click from any page, right?
Ooft.
- Having confusing language and poor differentiation between the sign in and sign up form. Symptom, users start filling in the wrong form only to realize their mistake.
- Separating the password from the email field with an extra mouse click sucks if you are using a password manager. Doubly so on mobile where using password managers involve a bit of fiddly interactions. Having to do this twice sucks. If you do this, at least have one of the fields in the dom tree but hidden so that it gets filled with one click via your password manager.
- Not making the login form password manager friendly my not sticking to conventions for field names for this.
This is useful if you support authentication methods other than password
> - Not making the login form password manager friendly my not sticking to conventions for field names for this
Instead of relying on heuristics based on field names, it's also possible to annotate the field with the autocomplete attribute
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
If I understand correctly, the reason behind this pattern is SSO.
Most websites are gaining SSO capabilities. Before asking for your email/user, they don't really now if you're gonna login using password, or you should be redirected to an IdentityProvider.
I'd be happy to know if there are better patterns here but I think password managers should get a bit smarter and work with this trend.
If you are going to tell that may confuse users, I think not having a password field is already confusing the other half, while also not being password-manager-friendly.
The current trend to only show the password box after the username is provided doesn't have to be bad for password managers. I use loads of sites that do this (so they can support SSO) and they just use hidden form fields so the password managers know what to do.
I'd be curious to hear any suggestions you have for password managers to improve here though. I can't think of anything short of a .well-defined login route.
> Using Single Sign-on (SSO)? Simply enter your company email address and click sign in.
Seems simple enough to me as a user, not sure how most people interact with it though or how many companies A/B test these things.
(Just don't forget to donate, if you have the means.)
Passwords work off well publicized naming conventions. That's why they work on the vast majority of websites. The problem is junior developers not knowing that is a thing getting creative with naming things. No-one on such projects even thinks about testing this or pointing out to their PMs that this does not work. 9 out of 10 times you'd get the response to "please fix that". Because why would you not.
The only downside is the user submitting a password they dont need to, but if you're using js you could post the username first and only post the password if needed. That would be the same exact process, except from the users perspective it would be seamless. You could even have it check the username as they type, and lock the password field if its not needed.
but the login flow is one area of your product that needs to work for everybody. There's plenty of features that can be tailored to a power-user workflow because they're the only people that will see it, but the sign-in flow is not one of those. any confusing UI in your sign-in flow is going to confuse your least-confident users. and asking people using Facebook Sign-in to enter a password when they haven't ever set a password for your site is extremely confusing. all just to save a couple keystrokes for the most-technically-competent users.
The problem is when you have a bunch of enterprise customers and you're not sure which custom login to use, and you dont want to list all your clients.
Ideally, this is solved by the client company telling its employees to use an internal link that authenticates and redirects. Though I'm sure not all clients are capable of this, and still want to use SSO. In that case, I think my solution is much nicer than requiring a two step login.
- Defocusing input fields in the middle of typing login information
I guess i'm in the minority these days but I like to keep strong passwords in my head.
This usually happens due to some side effect of the login page being absolutely fucking massive and not fully loading or executing before I start to fill in the form, then one of three things usually happens in order of frequency:
The last one is the most annoying because in the worst case i type my password in visible text.Only login I regularly use that does not suffer from this problem (or any others!), is HN:
https://news.ycombinator.com/login is 1.07KB
Causes only one secondary HTTP request to favicon at 7.66KB which doesn't interfere with the page in any way.
Browser url-bars are shooketh...
I use Surfing Keys, a vim-like plugin for browsers. When inputs defocus unexpectedly while I'm typing all of the navigation shortcuts kick in and it's like "roll a d100 to see which random negative consequence you get." Usually I at least lose the page that I'm on and I have to start the form over.
I think they mostly do this so SSO customers do not accidentally enter their company password on the site every time.
I like this more than other sites where I have to find the right button between different login options (sign in with google, sign in with facebook, sign in with sso, ...) and then have to type the company name ... whatever might be the choice the admins did there that time ...
I also think that approach was initially created by Yahoo! So they could shown the user's avatar on the password page to prove authority. Not sure whether that still is a thing somewhere, considering that a recent trend is not to verify whether an account exists ...
Anyway my name is remembered on my company SSO form, and I never sign in as someone else.
Azure Active Directory does not make it easy to do this, with the way you have to explicitly whitelist post-back URLs, or else you get the dreaded login.microsoft.com 401 page of death, where you have to parse out information buried in the query-string to determine why you didn't get redirected properly (usually it is a trailing slash on the URL... %2F)
Signup is a big thing with lots of stakeholders and interest. User acquisition is an easy metric to track for business health. Everyone wants to push not-logged-in users to sign up.
Ownership of logging in was much less clear. It's not a full time job for a person or team in the same way customer acquisition is. So you put some buttons/links on the page, but then there's no single owner of them to get pissed off when other teams start moving their shit around.
(The other aspect here is that the website was a declining platform compared to the apps, where a not-logged-in user is much more captive and there's a more obvious single "login or signup" landing page point. On the web most media sites, at least, try to provide SOME sort of preview/partially functional experience version of the logged-in view, which wasn't designed with a prominent "SIGN IN" button in mind.)