
Single input login form - gaelian
http://www.awayback.com/single-input-login-form-2/
======
alanh
Please, please don’t use this.

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.

~~~
eps
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.

~~~
pavel_lishin
> both the username and the password lengths are typically capped at
> relatively short values

What? They are? The only place I've seen this is on bank websites.

------
bl4k
A better way to do this:

* 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.

~~~
alanh
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.

~~~
bl4k
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.

------
DanHulton
I have some problems with this.

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.

~~~
johnwatson11218
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.

~~~
fhars
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.

[edit: stupid comment parser ate math symbols]

~~~
epochwolf
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)

------
kogir
Two major problems come to mind.

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...](http://jeremiahgrossman.blogspot.com/2010/07/i-know-who-your-name-
where-you-work-and.html)

------
gaelian
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?

------
jrockway
Uh, what? Why is pressing space and violating 50 years of UI convention easier
than pressing tab and keeping yourself consistent?

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

~~~
fragmede
Or ssh key, a-la git (hub) commits.

------
obeattie
As I posted on the article:

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.)

------
corin_
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.

~~~
varikin
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?

------
alexg0
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?

------
sahillavingia
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.

~~~
brianlash
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.

~~~
Qz
Simpler solution is probably the opposite -- leave sign in forms as they are
and just let space key yield a tab.

------
laughinghan
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.

------
iuguy
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).

------
afshin
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?

------
Sakes
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.

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

------
ggruschow
_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.

~~~
Alexx
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.

~~~
ggruschow
You could just make min(len(secret_username)) = 1 + min(len(username)) +
min(len(password))... if that's what you wanted.

Not all systems need to have the same level of security though, nor do they
all need to assume their users are ignorant.

------
toast76
I actually think this is an awesome idea.

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.

------
ugh
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.

------
sp4rki
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.

------
chrischen
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.

------
tomjen3
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.

------
dpavlenkov
Your username is incorrect, but password ok!

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.

~~~
DisposaBoy
I beg to disagree.

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.

------
mikeknoop
I see single form logins useful on Mobile devices -- especially since I do not
particularly care if my password is masked on mobile devices.

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

~~~
alanh
> 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

------
blahpro
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".

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

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

------
evanchen
There's no significant problem to solve here.

~~~
pbhjpbhj
> _There's no significant problem to solve here._

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).

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

------
joshstrike
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.

Bad idea.

