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.
With regards to #2 - the assumption with his design appears to be that the input field is long enough to fit the longest username and the password. Given that both the username and the password lengths are typically capped at relatively short values, the assumption is reasonable. But even if there is an overflow, I don't really see it being a problem - the password is no different from a regular input except that all chars are dots. If whatever is typed does not fit, the regular scrolling paradigm will still apply here.
With regards to #3 and #4 - a standard password input control can be used to capture and display the password. Make it borderless and reposition it dynamically based on the length of the username. Not that it'd be a very elegant implementation, but it is doable nonetheless.
I cannot believe this statement. Unobstrusive javascript wires up events using javascript code instead of onclick attributes in tags. If your javascript doesn't load, it can't wire up events. Obtrusive javascript would work just fine because it's embedded in an attribute (like onlick) on the tag. (Assuming javascript is turned on and the browser supports it.)
This is not what I meant at all. If you have JS, you'd see one field. No JS, you see a regular login form. It has nothing to do with onclick attributes.
Also, just because it looks like one input field, doesn't mean it has to be one input field. It could be two fields masquerading as one.
Still, I don't think this is a useful design pattern.
* 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.
Why do this at all? Tab isn't any harder than teaching users that on your site and only your site, space works the same way on one field. Poor discovery and dubious benefit is not a great combo.
That said, you're right that it would be a better implementation, assuming backspace effectively shift-tabbed.
I wouldn't. My response was totally about a better way of doing it, otherwise I would have mocked this up and published it.
My own opinion is that the lack of consistency in registration and signup forms across the web is a real problem for regular users, and we do not need another yet more confusing option. I picked this up from watching regular people attempt to signup/signin to web services.
The web could use a standard style guide published by some sort of group. ie. this is what a reg form should look like, this is where a login box should be etc. It is a stretch to think it would work, but it would help regular users a lot (I am not talking about all forms having the same design, talking about standard field names and positions, standard features (eg. double prompt for password, show strength, password reset, no password in clear, email as username etc, always have a logout button in top-right, etc.).
There have been no real breakthroughs in design wrt the signup/signin/logout process online. HTTP auth didn't catch on, and that was the last chance we had at standardizing it.
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.
Does everyone agree about that last point? That having a single error message that says "username/password combo not found" is more secure? I have always thought that the username was not secret and to treat it as part of the secret is almost like saying there is no username just a big password that you enter in two distinct boxes. I understand that hackers do like ways to validate that they have an actual username and aren't just guessing ... it is like having the first half of the 'big secret password' cracked.
I am throwing this out there because I think it is important to know which pieces of your security model are 'load bearing' so to speak. I'm not really comfortable with this quasi secret status that the username enjoys. I think it is either a secret or it is public info.
Yes, it is. You should design your login system assuming that the username is public, of course (otherwise you would facilitate attacks targetet at a specific user), but for an attack on the site itself that needs just any one account, separate error messages reduce the complexity by several orders of magnitude.
Assume 8 characters out of A-Za-z0-9 for the username and 8 character out of 96 printable chars for the password. With a single error message, the search space is 62^8 times 96^8, with separate error messages it is 62^8+n times 96^8, with n being the number of users. This is far, far smaller if the number of users is noticably less then 62^8.
This doesn't work very well if your password reset screen gives errors if the user doesn't exist. Or you can look up users by a given url. (deviantArt.com gives each user a subdomain that is the same as their username, easy lookup)
I understand the security argument about not giving out more information than you absolutely need to.
But, I hate 'low-risk' sites that do this when I'm not sure of my username/password. If I can't remember what username I used 6 months ago when I signed up then at least tell me I got that wrong instead of trying different passwords.
Even better, scratch usernames and let me log in with my email address.
If that is the case, it probably deserve(s|d) a reason for support. "This." contains zero content aside from approval - functionally identical to the arrow, but at a much higher waste for everyone who encounters it.
> 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.
I don't see why that's generally going to be a security flaw; most services already indicate if a username is taken when signing up so a hacker can poll for random names there instead.
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.
I suspect 3rd party password managers and such similar features native to browsers would not cope well with this single input login form.
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?
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 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.
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.
This makes me think of the people that don't use the tab key to move through fields. Instead, they click on the next one. What is there to click on with this?
Don't do this. Will break password managers, like http://www.lastpass.com, with little upside.
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.
Is it worth the change in paradigm for this small benefit? I guess only A/B testing will tell.
I'm not a programmer but I feel like it would be straightforward enough to make the tab key yield a space in this instance, so that either the tab or the space key would work.
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.
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.
An interesting concept, albeit insecure. You should never tell the user which element of authentication was incorrect.
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).
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 & 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.
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.
Alternative: 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.
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.
The main problem with this is that it would greatly increase the effectiveness of brute-force attacks.
The secret username would have to be forced to be a long string without dictionary words, numbers, capitalization etc, which somewhat undoes any potential advantage. Even then it's not very secure in comparison.
Even if a potential intruder does know a username, there is only one possible pass key, but by removing that link you're free to guess the pass key of any user in the system.
I wasn't arguing it was more secure. It could be made equivalent, but that misses the point. You don't always need a deadbolt in addition to a lock in the door knob.
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.
This is one of those things that should be tested.
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.
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.
1) If your login form annoys me it's very likely that I won't be using your service e.g the HN OpenId login is pretty much broken if I have noscript enabled so if there wasn't a normal login I wouldn't be here. So yes, it should be helpful. I'm not a mind-reader and I don't like to play mind-games so if I do something wrong then I expect to be told what I did wrong.
2) I'm not sure how that helps security. If a human can find the login form it means a human can write a program(i.e a bot) that can also find that form...
2.5) For security reasons, I've never and understood this or where it came from. If your service allows login then in almost all cases it also allows registration. I can understand if you're among those who feel the need to annoy users that try to register by telling then that there's an error in the form they submitted with no indication of what that error is but otherwise you will return some error if they try to signup with an existing username. This boils down to one extra step to find out if the username is wrong or not. For a human that might be tedious. Even if you give vague error messages at registration it's still trivial to use this same vague error message to figure out if a username exists or not.
> Mobile phones are distinctly lacking "tab" and changing input forms is usually a pain.
iPhone ALWAYS provides "next" and "previous" (input) buttons when filling web forms. On my old phone, the arrow keys did this. What phones are you imagining?
Also keep in mind the hacks needed for this as mocked up are going to be even less reliable and less testable on mobile
I've had to enter username/passwords in to a mobile phone in the last couple of weeks and it's painful - I can see a unified input working for that. In short I see a problem that this may be a solution to (it was also mentioned in the comments of the linked article).
Of course my mobile provider could fix that one with a better interface too (it's not a smart phone).
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.
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.