Single input login form

1. Besides the obvious UX problem of unfamiliarity, I would also expect some people (myself included) to worry about whether or not their password will be masked.

2. The “Password” placeholder in the mockup is actually impossible to reliably implement (on the web)… consider a 44-character username, for starters.

3. You are now responsible for removing the password from the DOM on page back/forward, something browsers often do automatically with real password fields. Good luck doing this x-browser.

4. The time your JS doesn’t load? That’s when your user sees their password displayed in unmasked plaintext.

--

Addendum Amazon implemented a similar concept with their PayPhrase. Even if you’re not logged in, entering your unique phrase on a product page allows you to then enter a 4-digit PIN and BAM, you’ve ordered a product (to your previously entered credit card and location). The PayPhrase is notably neither a username or password, but is nevertheless uniquely tied to your account, and takes the place of your traditional credentials. Not only does this sidestep most of the issues of the combined username+password box, it’s purely optional, meaning it shouldn’t frustrate anyone.

* Have a text input and password input HTML entities next to each other with CSS that removed the right/left border and spacing (dynamically resize the input boxes if you like)

* Capture a space keyprees event to shift focus to the password field

* Same effect, but degrades in non-JS browsers to a normal entry field and allows the browser to still provide password remember, masking and form parsing on the backend.

I don't like the idea of splitting/parsing the field on the client side in JS - there is too much that can go wrong. You are telling the browser that this is just a normal text field, so the value will pop up (in the clear) on other sites that share the same input name.

1) It's unfamiliar, and this will slow people down. While this is not a major issue, compared to the rest, it may certainly increase support costs, which may not be allowable if you're working on Enterprise software with a huge userbase.

2) It would require a nonstandard UI widget in order to display the username in cleartext while hiding the password in the same field. If you're designing for the web, this means you're messing with people on mobile devices, which are a fast-growing segment of the population.

3) If space is the delimiter for username/password, it means that you can't use space in your username. I HATE when you can't use space in your username and possibly in your password, depending upon on how well-designed and well-followed your spec is and becomes. For one, I prefer having my username as "Dan Hulton", not "DanHulton", though that's a minor quibble. More importantly, more entropy is more better, and allowing people to use spaces in their usernames/passwords encourages the use of passphrases, which are LEAGUES better than passwords.

Also, having separate warnings for your username and password matches is a bad security practice. Best to just say "username/password combination not found" instead of letting a potential hacker know he's stumbled upon a valid username.

1) Breaks password managers and broswers' save password function. Many users are helpless without these.

2) You know how your browser helpfully remembers and fills in your name and address across different websites? Yeah, now it'll fill in your username and password too, making it accessible via javascript to any site that wants it. Since the password isn't in a password field, the browser doesn't know to restrict it to the original site.

For an example of using javascript to get this kind of information, see Jeremiah Grossman's blog: http://jeremiahgrossman.blogspot.com/2010/07/i-know-who-your...

I also wonder about the accessibility issues that would be inherent. JS would seem to be a large part of getting this solution to function and that can be an issue for screen reader users for example.

My instinctual reaction is to think that this is a solution that causes more problems than it solves. But none the less, I like it when people challenge the status quo and propose something new. Sometimes it pays off, sometimes it doesn't but if no one ever did this, where would we be?

If you want to save me some typing, allow me to login with my SSL certificate.

To me it feels a little like you're trying to solve a problem that doesn't exist. Just about everyone is familiar with the username/password paradigm, and honestly I've never seen anyone have a problem with it.

Usernames (or email addresses, as is common) and passwords are two distinct pieces of data, they are not one, so why should they be presented as one? Basically, the only advantage here is that you can hit space instead of tab as far as I can see it… and the time needed to read the helper text above the input field far outweighs the time novice users who click in each field will take to do so. This seems to me like a net loss, and source of "WTFery" for everyone. Separating username and password is not some senseless convention or relic from the past, it's the logical visual result of this authentication model.

(I disagree with those saying that OpenID is a great login experience; for me, it's by far the worst login experience I've seen. The example given [StackOverflow] caters to a very technical audience anyway, so it's a non-issue there, but for Joe Public it's just a constant source of confusion. This has been debated to death elsewhere, though.)

From the point of view of more generic computer users (such as my mother), I wouldn't think learning to type a space would be any easier than learning to hit tab, and would probably just cause confusion, due to the fact that different websites use different formats.

On second note, would not putting 2 fields in one line, and having space switch from username to password in JS achieve the same thing similar benefits without the drawbacks?

Is it worth the change in paradigm for this small benefit? I guess only A/B testing will tell.

2) This is virtually impossible to implement, input textboxes are very not hack-friendly.

A password input box without a border, really? Surely you wouldn't have the username be an ugly fixed-width font, so how do you know how wide the username is?

Have fun detecting when the cursor has reached the left most edge of the password box, and focus should be transferred back to the username box and the cursor set to the rightmost edge of the username box, and vice versa. When someone tries to select text from both username and password boxes, seeing as they appear to be one contiguous textbox, there's no way to avoid somehow violating user expectations.

Tell the user their username is incorrect and you open yourself up to brute force enumeration of user accounts.

Tell the user their password is incorrect and there's now an easily scriptable way of brute forcing logins for an individual user.

The correct thing is to tell the user their credentials were incorrect, and offer a recovery mechanism based on something else (like an email password reset process).

That being said, the biggest problem I see is that there is no visual separation of the two fields, and the fact that the user has to read a sentence to figure out how to log in. A nice soft divider like a pipe bar or forward slash between the text "username" and "password" would help with this visual problem. More white space would help a lot too. I think you could make up for the remaining confusion with the following:

(I am assuming there are two form fields that are only visually changed to look like one form field)

1) When the user first sets focus to the username field, do not remove the "Username" text, but simply highlight it, which will give the field visual boundaries. Once the user begins typing replace "Username" with the input text. (Repeat for password field)

2) Key capture "tab" and either " | " or " / " (whichever you are using as the field separator). When they fire this key press, set focus to the "Password" field.

3) If the user hits the "Sign In" button with empty string in either the Username field or the Password field, set focus to the empty field and show tool tip.

4) If both fields lose focus while one has empty string as a value, show tool tip.

Using bold to convey focus is a nice touch by the way.

The sad thing is there will be a lot of users that do not like this, a lot. If they frequent the site enough, it will not be that big of a deal, they will learn quick enough. But like some previous posters said, if there is a large user base logging in through this form, you will get quite a bit of backlash. I created a js driven date form field that works just like the calendar field you see in both Mac OSX and Windows Vista. Even though every user has seen it, I got a lot of complaints the first week that it was included in our application. It was worth though, it rocks!

I really do like this single field login form, I'll be using it in my pet project.

The secret username can be associated with a display name, real name, physical/email addresses, etc. You can use the latter to look up the former along with a password/probing question/ping (email, text, phone) to retrieve the former.

It seems to make more sense to me logically anyway: I'm not anonymously entering a secret club with a password. I'm identifying myself, and based on my identity I'm allowed to do something.

I'd just make a couple of small changes though. Instead of using space to start entering your password, I'd use the TAB key (as people are familiar with it). Then, to make it more obvious to the user the separation (and protection) of their password and user name, I'd put the password in a second text box and label it "password".

The benefit of this approach is that I think users would be comfortable with it, it works with all modern browsers (without JS) and I think it will be a fairly easy to change our existing forms to suit.

I use tab but I know many people who don’t. Replacing tab with something much more common like space might help. Or it might just confuse. I honestly don’t know.

Using your "system" I would end up searching in the login form.

Oh and it doesn't work with any known password rememberer feature I know of.

Seriously, login is not the place to be helpful. On the contrary, for security reasons, the login control should be hard to find, and the error messages should be cryptic, like "ehh". You can reward their patience on the other side.

Mobile phones are distinctly lacking "tab" and changing input forms is usually a pain.

Bad idea.