4 ms·

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

by alanh 16y ago

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 16y ago
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 16y ago
  > 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.
chrisbroadfoot 16y ago
#4 isn't hard to overcome with unobtrusive JS. But agreed on the other points. Usability FAIL.
- epochwolf 16y ago
  > #4 isn't hard to overcome with unobtrusive JS. 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.)
  - chrisbroadfoot 16y ago
    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.

by alanh 16y ago

eps 16y ago

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 16y ago
> 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.

chrisbroadfoot 16y ago

#4 isn't hard to overcome with unobtrusive JS. But agreed on the other points. Usability FAIL.

epochwolf 16y ago
> #4 isn't hard to overcome with unobtrusive JS. 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.)
- chrisbroadfoot 16y ago
  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.