4 ms·

I miss going to foo.com and having user/pass fields on the top row of the screen, with maybe a sign up link next to it.

jspash 6y ago
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)
- jtvjan 6y ago
  That's to support single sign-on. It checks whether to show the in-house sign-in page or to redirect.
  - midasuni 6y ago
    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”
    - isbvhodnvemrwvn 6y ago
      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.
  - daniellarusso 6y ago
    I thought it was to make scraping slightly more difficult.
  - Nextgrid 6y ago
    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".
    - AgentME 6y ago
      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.
macNchz 6y ago
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!
sethhochberg 6y ago
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.

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)

jtvjan 6y ago
That's to support single sign-on. It checks whether to show the in-house sign-in page or to redirect.
- midasuni 6y ago
  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”
  - isbvhodnvemrwvn 6y ago
    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.
- daniellarusso 6y ago
  I thought it was to make scraping slightly more difficult.
- Nextgrid 6y ago
  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".
  - AgentME 6y ago
    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.

macNchz 6y ago

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!

sethhochberg 6y ago

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.