Live data from Hacker News

Don't make customers hunt for the Sign In button on your website

blog.stunning.co

61–70 of 213 posts

Re: Don't make customers hunt for the Sign In button on your website

#61
post #47
post #42

Earlier quoted context omitted.

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)

That's to support single sign-on. It checks whether to show the in-house sign-in page or to redirect.

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

Re: Don't make customers hunt for the Sign In button on your website

#62

Discord is bad at this. 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 exist…

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.

Re: Don't make customers hunt for the Sign In button on your website

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

Re: Don't make customers hunt for the Sign In button on your website

#65
Don't make customer hunt for anything on your website.

Prioritize features (ideally based on studying user behavior), and make those features present and accessible. Hide the rest, if necessary, behind some menu system or toggle.

The minimalism trend (perhaps a reaction to the early amazingly busy Amazon UI?) has gone too far. One great (bad) example of this is Parabol.co. We use it at my company, and it provides just the right set of features we need. But for providing a relatively small feature set, it seems to go out of its way to make it difficult to know how to use those features. I only mention them because they are a good example of this, but there are countless other services that have user hostile (or frustrating) interfaces.

Re: Don't make customers hunt for the Sign In button on your website

#67

Earlier quoted context omitted.

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.

The same Vanguard that could have millions of dollars of investments in your account? What’s the appropriate time out?

Re: Don't make customers hunt for the Sign In button on your website

#69
post #47

Earlier quoted context omitted.

That's to support single sign-on. It checks whether to show the in-house sign-in page or to redirect.

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.

Re: Don't make customers hunt for the Sign In button on your website

#70

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…

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

Post reply on HN