Hacker News Reader

Comment by jillesvangurp | Hacker News Reader

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.

View on HN

Another one:

- 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:

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.

> - Defocusing input fields in the middle of typing login information

Browser url-bars are shooketh...

The great internet speed divide has no patience for loading superfluous crap that is wasting their lives.

>defocuses for no apparent reason

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.

> 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.

The Oreilly learning platform does this. Email and password field on the same page and a message under the email field

> 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.

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.

The password field disappears if you enter an SSO-compatible email address.

Then you have to either leak a list of each customer to the client to verify there or send each key stroke and consider latency ...

That requires you to teach your users what SSO is. I don't think it's a great UX.

Seems like password managers should be able to handle the password being entered on the next page when there's no input on the current page.

KeepassXC (and its browser extension KeepassXC-Browser) does this. Not sure why anyone would even consider a different password manager.

(Just don't forget to donate, if you have the means.)

Because different people have different requirements.

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.

> Separating the password from the email field with an extra mouse click

I think they mostly do this so SSO customers do not accidentally enter their company password on the site every time.

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 kind of agree, but that seems more of a problem with the target system.

Anyway my name is remembered on my company SSO form, and I never sign in as someone else.

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)

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.

> - Separating the password from the email field

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...

You can still separate them and have a hidden password field for a password manager to bypass the other page or pass it through to the next page.

1Password manages to handle this just fine, even without the hidden password field trick. Perhaps we just need better password managers.

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.

Also, blocking right-click->paste is REALLY irritating.

As a non-native English speaker I always confused "sign in" and "sing up". I would prefer totally different words like "Enter" and "Register".

Yeah, those two phrases look too similar. What happened to good old "login" anyway?

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?

That's exactly it - you sign the guestbook when you arrive at the hotel.

You want to enter a site you're already on?

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"?

I feel that lately password managers (at leat 1Password, which is what I use) have been working even with split forms. So at least there is that.

Reply on news.ycombinator.com