Single input login form

Please, please don’t use this.<p>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.<p>2. The “Password” placeholder in the mockup is actually impossible to reliably implement (on the web)… consider a 44-character username, for starters.<p>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.<p>4. The time your JS doesn’t load? That’s when your user sees their password displayed in unmasked plaintext.<p>--<p><i>Addendum</i> Amazon implemented a similar <i>concept</i> 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 <i>purely optional,</i> meaning it shouldn’t frustrate anyone.

A better way to do this:<p>* 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)<p>* Capture a space keyprees event to shift focus to the password field<p>* 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.<p>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.

I have some problems with this.<p>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.<p>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.<p>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.<p>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.

Two major problems come to mind.<p>1) Breaks password managers and broswers' save password function. Many users are helpless without these.<p>2) You know how your browser helpfully remembers and fills in your name and address <i>across different websites</i>? 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.<p>For an example of using javascript to get this kind of information, see Jeremiah Grossman's blog: <a href="http://jeremiahgrossman.blogspot.com/2010/07/i-know-who-your-name-where-you-work-and.html" rel="nofollow">http://jeremiahgrossman.blogspot.com/2010/07/i-know-who-your...</a>

I suspect 3rd party password managers and such similar features native to browsers would not cope well with this single input login form.<p>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.<p>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?

Uh, what? Why is pressing space and violating 50 years of UI convention easier than pressing tab and keeping yourself consistent?<p>If you want to save me some typing, allow me to login with my SSL certificate.

As I posted on the article:<p>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.<p>Usernames (or email addresses, as is common) and passwords <i>are</i> 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.<p>(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 a personal point of view, I've been using keyboard buttons to navigate through forms for so many years (tab to go to next field, space to tick/untick a checkbox, etc.) that it wouldn't save me any time.<p>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.

Don't do this. Will break password managers, like <a href="http://www.lastpass.com" rel="nofollow">http://www.lastpass.com</a>, with little upside.<p>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?

This is very unique, however empirically it may not perform well. In the end, it has the same attribute as two fields, except that instead of tabbing to the next you hit space.<p>Is it worth the change in paradigm for this small benefit? I guess only A/B testing will tell.

1) Nielsen's First Law of Web Usability: People spend most of their time on _other_ people's websites. This wouldn't save anybody any amount of time at all.<p>2) This is virtually impossible to implement, input textboxes are very not hack-friendly.<p>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?<p>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.

An interesting concept, albeit insecure. You should never tell the user which element of authentication was incorrect.<p>Tell the user their username is incorrect and you open yourself up to brute force enumeration of user accounts.<p>Tell the user their password is incorrect and there's now an easily scriptable way of brute forcing logins for an individual user.<p>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).

In addition to all of the UX issues that have been brought up here, there's also the problem of spaces in a user name. Sure, an algorithm could be written where the last broken up block of a string split by spaces in considered the password ... but then what about passwords with spaces in them?

It might be the whiskey talking but I think this is a great idea! It would really clean up those embedded login forms placed in the header &#38; body of web pages. Think about how clunky text site searches would look and feel if the majority of them included 2 - 4 form fields.<p>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:<p>(I am assuming there are two form fields that are only visually changed to look like one form field)<p>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)<p>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.<p>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.<p>4) If both fields lose focus while one has empty string as a value, show tool tip.<p>Using bold to convey focus is a nice touch by the way.<p>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!<p>I really do like this single field login form, I'll be using it in my pet project.

An alternative is to use OpenID which requires a single input login form by design.

<i>Alternative</i>: There's no reason for my username to be public on the vast majority of sites/apps/crap that I use, so I'd rather just have a username, no password.<p>The <i>secret username</i> 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.<p>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 actually think this is an awesome idea.<p>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".<p>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.

This is one of those things that should be tested.<p>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.

This has so many security and design concerns it's not even funny. Everyone has already said so in this thread already so I won't add to that, but I do want to add an even better solution. Add a remember me checkbox that when checked sets a cookie that you can use to identify the person with later. When the user gets to the login, he's presented only with the option to enter his password, and a link to login as a different user. Single input element without the security concerns.

I think the usual username TAB password ENTER process is simple enough. If you want the space saving you can hide the password field until you press TAB.

That isn't very smart - whenever I need to find the search field, I scan the page for a single field with a button under it. Should I need to login, I scan for two fields above each other.<p>Using your "system" I would end up searching in the login form.<p>Oh and it doesn't work with any known password rememberer feature I know of.

Your username is incorrect, but password ok!<p>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.

I see single form logins useful on Mobile devices -- especially since I do not particularly care if my password is masked on mobile devices.<p>Mobile phones are distinctly lacking "tab" and changing input forms is usually a pain.

Interesting, but they're still two fields conceptually AFAICT. They just happen to be within a single box that makes them look like one "field".

I indeed designed this for myself some time back, but dropped due to the obvious UI problems.

It may be better but it has to be A LOT better. Difficult to defeat tab.

There's no significant problem to solve here.

Hey, let's do something completely differently than users have learned and expect! Why? Because we can!

Also remember that many browsers will autofill this field, including the password, if someone just types the first 2 characters of the username. And malicious websites can take advantage of that fact to scrape U/P pairs with half the work.<p>Bad idea.