4 ms·

Not bad. Certainly better than inline labels. However, I think another con is the distraction of stuff moving around as soon as I start to type. Let me be cl

by nfoz 13y ago

Not bad. Certainly better than inline labels. However, I think another con is the distraction of stuff moving around as soon as I start to type. Let me be clear, it's not that there's movement. It's that if a box asks me to enter something, then my answer is premised on what was asked of me. If the moment I start typing it seems like something in the environment is changing -- suddenly I'm like, whoa, what changed? Is what I'm typing still what the box wants? Did I do something that caused state to change simply by typing a character? There's this tiiiiny moment of hesitation at that first character, before my eyes scan what happened, re-read the label text, and I see what occurred and that my input is still valid. tl;dr: might take a bit of getting used to seeing stuff change on the screen the moment you type into a box.

zepolen 13y ago
I agree I think it would be better if the label floated up the moment the text box gained focus.
- lstamour 13y ago
  Fixes the complaint mentioned in the blog post of losing the ability to set both placeholder and label. Once floated, a new placeholder can be set and animate from the bottom of the box, or just fade in. Alternatively, to address the password example head on: a well-placed tooltip, or better yet a button to generate passwords or an autosuggestion to fix passwords to match complexity requirements (done locally so password need not be sent multiple times) might be interesting. Actually, hide the suggestions until a user clicks for them. Never know what environment they're in. Auto generating a password they can choose to change might be interesting too.
  - harlanlewis 13y ago
    I have never seen a form auto generate a password, but intrigued by the concept. How would you communicate it to the user? At some point you'd need to send it in plain text (not to mention trust they'd remember/record it, unless you're optioning for a 'reset your password ever time' flow)
    - msohcw 13y ago
      Two small icons next to the field, one for autogeneration (a refresh maybe?) and one for password visibility (an eye like IE uses perhaps, a concept common to other software as well.) Keep the generation code in js client side , and send the plaintext to the server via SSL as always. Normal operation of user creation. The plaintext has to be sent at least once over SSL to get hashed on the server side. Hashing on the client side is generally worse because then you'd be more susceptible to MITM attacks. (Actually, either way you'd be more susceptible. Just rely on strong SSL.)
      - lstamour 13y ago
        Yes re client side generation though it might not be as random, the point is to encourage people to not use the same password. It could be combined with an educational note "Why use this password?" or "Why should I remember a different password? You don't need to..." Client-side is always MITM friendly without certificate pinning and strong SSL, which is why I have to dial down the paranoia a bit myself: I was just now thinking that you could plant a non-random auto-completed password, but then if you can do that you could just listen for the real password too. (We're assuming you're running JavaScript here after all.)
    - lstamour 13y ago
      Beyond LastPass and such, one long-standing UX implementation is in Mac OS X, when you go to change a user's password. It even has an interesting dialog box, though the pre-selected passwords tend not to be quite random enough for my tastes if pronounceable. A variation of this has appeared in Safari on iOS 7 with iCloud Keychain turned on: Safari will now suggest a password in the autocomplete when you go to fill in a registration form it can recognize. This, while surprising, really does work assuming someone can "save" the password at the same time. (Hence why it's rarely done on the web unless you have such tools, but people more often do these days.)
justinpombrio 13y ago
This is a good point; I feel the same thing. Do you think it could be solved by replacing the inline label with a floating label when the user selects the text box, instead of when they start typing?
- nfoz 13y ago
  I do think that's better. But I'm concerned that if focus changes have a visible effect, that could also be disconcerting to a user. I think I'd have to try it out.
  - deskamess 13y ago
    Perhaps it could take effect after focus was lost (and something had been typed in).
- lstamour 13y ago
  This solves two problems: 1. Your float label animation can now sync with whatever form focus style changes would occur, so it just becomes a natural extension of selecting the field. 2. It fixes the "Can't use Label and Placeholder" by letting a new placeholder animate in when the old placeholder floats out. :) This could easily be accessible and in fact, if done on focus could almost entirely be done with CSS. I've got to try this one for myself now.

by nfoz 13y ago

zepolen 13y ago

I agree I think it would be better if the label floated up the moment the text box gained focus.

lstamour 13y ago
Fixes the complaint mentioned in the blog post of losing the ability to set both placeholder and label. Once floated, a new placeholder can be set and animate from the bottom of the box, or just fade in. Alternatively, to address the password example head on: a well-placed tooltip, or better yet a button to generate passwords or an autosuggestion to fix passwords to match complexity requirements (done locally so password need not be sent multiple times) might be interesting. Actually, hide the suggestions until a user clicks for them. Never know what environment they're in. Auto generating a password they can choose to change might be interesting too.
- harlanlewis 13y ago
  I have never seen a form auto generate a password, but intrigued by the concept. How would you communicate it to the user? At some point you'd need to send it in plain text (not to mention trust they'd remember/record it, unless you're optioning for a 'reset your password ever time' flow)
  - msohcw 13y ago
    Two small icons next to the field, one for autogeneration (a refresh maybe?) and one for password visibility (an eye like IE uses perhaps, a concept common to other software as well.) Keep the generation code in js client side , and send the plaintext to the server via SSL as always. Normal operation of user creation. The plaintext has to be sent at least once over SSL to get hashed on the server side. Hashing on the client side is generally worse because then you'd be more susceptible to MITM attacks. (Actually, either way you'd be more susceptible. Just rely on strong SSL.)
    - lstamour 13y ago
      Yes re client side generation though it might not be as random, the point is to encourage people to not use the same password. It could be combined with an educational note "Why use this password?" or "Why should I remember a different password? You don't need to..." Client-side is always MITM friendly without certificate pinning and strong SSL, which is why I have to dial down the paranoia a bit myself: I was just now thinking that you could plant a non-random auto-completed password, but then if you can do that you could just listen for the real password too. (We're assuming you're running JavaScript here after all.)
  - lstamour 13y ago
    Beyond LastPass and such, one long-standing UX implementation is in Mac OS X, when you go to change a user's password. It even has an interesting dialog box, though the pre-selected passwords tend not to be quite random enough for my tastes if pronounceable. A variation of this has appeared in Safari on iOS 7 with iCloud Keychain turned on: Safari will now suggest a password in the autocomplete when you go to fill in a registration form it can recognize. This, while surprising, really does work assuming someone can "save" the password at the same time. (Hence why it's rarely done on the web unless you have such tools, but people more often do these days.)

justinpombrio 13y ago

This is a good point; I feel the same thing. Do you think it could be solved by replacing the inline label with a floating label when the user selects the text box, instead of when they start typing?

nfoz 13y ago
I do think that's better. But I'm concerned that if focus changes have a visible effect, that could also be disconcerting to a user. I think I'd have to try it out.
- deskamess 13y ago
  Perhaps it could take effect after focus was lost (and something had been typed in).
lstamour 13y ago
This solves two problems: 1. Your float label animation can now sync with whatever form focus style changes would occur, so it just becomes a natural extension of selecting the field. 2. It fixes the "Can't use Label and Placeholder" by letting a new placeholder animate in when the old placeholder floats out. :) This could easily be accessible and in fact, if done on focus could almost entirely be done with CSS. I've got to try this one for myself now.