11–20 of 61 posts
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.
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 b…
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.
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.
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.
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 b…
But agreed on the other points. Usability FAIL.
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 t…
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 p…
That said, you're right that it would be a better implementation, assuming backspace effectively shift-tabbed.