Use Dropdown Login Boxes for a Faster Login | Hacker News Reader

Use Dropdown Login Boxes for a Faster Login

uxmovement.com

17 pointsUXMovement18 comments

Worst. idea. ever. I hate this on Twitter, it breaks the password manager and it is an additional click just to show a login. How is it so intrusive to have 2 fields on a page?

How is it so intrusive to have 2 fields on a page?

Depends on the design, goals and intended audience.

Form fields are harder to ignore than most page elements and have a sort of gravitational pull on the eyeballs, so you can easily imagine situations where it's better to avoid them. Like, say, on public marketing pages for first time visitors to a microblogging app that's way hard to explain to your average non-blogging Yahoo-using grandma in flyover country.

That makes sense, and says what I've felt/intuited (but never known for sure).

I typically put a username / password box on any pages I want people to be logged in for. Now, obviously, this includes pages that they must be logged in for, but those pages should enforce authentication more strictly; But what I really mean are the pages that don't 'require' authentication, but for any number of reasons, it is preferred.

Also, I've always believed that the 'two boxes on a page' approach draws them torwards the login, and acts more as a call to action than Twitter's dropdown approach.

As alabut says though, use where appropriate.

It doesn't always... 1password seems to manage with some but not others. Have never bothered to check exactly why/why not. Perhaps to do with complexity of the javascript control? (although I agree from a ux perspective it's still a disaster)

What password manager does it break for you? (Firefox's built-in login cache has no problems autofilling Twitter's dropdown.)

One click to show is better than one click to load a wholly-separate login page.

... it breaks the password manager...

Doesn't that mean the password manager is buggy?

Two text fields, a checkbox, three labels, a button, three links. (That’s for Twitter.)

That’s pretty damn intrusive if the main purpose of your homepage isn’t even to provide you with the ability to log in. You obviously want to make it work with password managers but they should be able to pick it up. Mine can.

While hiding the respective fields on a homepage which has the main purpose of providing you with a login might not be such a good idea this is definitely so much better than any other solution which loads up a different page just to let you log in.

Bleh, left a comment and forgot about it, bad of me.

Depends on how the fields are added/removed from the page, but if they're dynamically created (I don't think they are in this case) then they wouldn't exist at the document load time which is when the manager tends to fill in fields, to my knowledge.

While I can at least see the argument of form fields possibly being intrusive, it seems like a long stretch to me in this case. Were it a multi-field form collecting data, I get it, but for a login form on a site where 99% of the activity takes place behind that login it seems damn silly to me to hide it so much.

Javascript, password managers & regression aside, the thought process behind the article makes sense. What sent up red flags is the only evidence for this UX is anecdotal: "twitter uses so it must be good."

When developing UX methods, you must test the fuck out of them. I wish the article had some numbers to back up their "we removed two boxes" illustrations.

from day-one (Oct 2008), I designed the login form on http://costpad.com to be

  - embedded in every page so the user logs in whenever he/she wants
  - always shown so a single click starts the process
  - keyboard-friendly by using Tab to navigate to the input boxes
  - Javascript-less friendly, so to be able to log in without JS 
   and not having to "bypass" my beloved NoScript
  - big-styled (as the rest of the webapp) so to be tablet/finger friendly.

Yes, this implementation occupies quite a lot of space up there, but I think the trade-off is fine.

The popup/dropdown login form is certainly cool and space-saving, but I couldn't come up with an implementation that satisfies me...

I've only seen dropdown login boxes on non-SSL pages. Which means I never use them.

This was the point I wanted to bring up; if you have your login form on a non-ssl page, it's possible for a man-in-the-middle attack to replace the "action" on the form and send your login credentials anywhere they want. To prevent this with the drop-down login, you have to make your homepage SSL, which has other drawbacks.

How does popping up a new set of elements but merely on the same page entirely remove the "visual processing" step? You still have to look and work out how the form works, much the same as if it were on a new page.

It does not remove the visual processing step, it simply reduces the amount of visual processing required.

Eyes tend to automatically fixate on motion. When the whole page transitions the eye has no single point of change/motion to fix on and must scan the whole page to identify the shapes that represent a login form. With a dropdown, the only change/movement is the login form, which the eye is naturally drawn to.

just having two fields and login button achieves much more than his method.

it should read second lowest method for login.

I have one complaint with the Twitter login dropdown, when you miss the arrow it loads the login page. That's fixed here but it doesn't work without JS. You should probably fix that.

To provide another example, there's reddit. Pop-up lightbox style. I've always appreciated it not taking me from what I was reading.

Also worth noting how many of those examples use "login" as a verb. "login" is the noun, "log in" is the verb.

Reply on news.ycombinator.com