Don't make customers hunt for the Sign In button on your website
211–213 of 213 posts
Re: Don't make customers hunt for the Sign In button on your website
#212I've peeked into the dev tools to see how Tailwind is used there. And since I'm advocating against using Tailwind, this page seems to be a perfect example what problems it brings to the table. Plenty of elements had to use custom classes to randomly overwrite some Tailwind classes here and there (like .display-3 and .main-headline) or completely avoiding Tailwind, like for the #recovered-revenue-main.
It just shows that Tailwind did not solve issues it was claiming to solve, at least in this project. And I guess it must be a pain to maintain this project since PR reviewer and other coworkers now have to know Tailwind by heart to figure out quickly what really got overwritten and why.
Re: Don't make customers hunt for the Sign In button on your website
#213Earlier quoted context omitted.
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…
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.