Float Label Pattern | Hacker News Reader

Float Label Pattern

bradfrostweb.com

162 pointsryanjodonnell33 comments

Even though the space for the small labels is there the whole time, I think this approach is better than having the small labels visible the entire time. Consider if the labels were tiny and always visible: the form would contain very tiny text and odd spaces where the existing placeholder should be.

Gray placeholder text also provides the needed contrast with the black user-entered text, so as not to confuse the two types of large text.

The animation is very clean as well.

My reaction was the opposite, I thought it would be more effective to just have the small labels from the start and no animation when you start entering a value. I'm pretty anti-animation on forms though. Just seems gratuitous.

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.

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

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.

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)

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

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

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

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?

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.

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.

Perhaps it could take effect after focus was lost (and something had been typed in).

All that and there's no link to the iOS implementation? https://www.cocoacontrols.com/controls/rpfloatingplaceholder...

n.b. I created the site I link to above, etc etc.

I love this idea. I did a quick pure-CSS implementation, not bullet-proof by any means - biggest downside is it's reliance on the `required` attribute: http://jsfiddle.net/thetron/qpsnH/

Implementation using CSS3:

http://jsfiddle.net/spectre/52Bf2/3/embedded/result/

I spiced it up a bit with a little animation. kind of hacky since I position the element over the input placeholder using absolute positioning.

http://jsbin.com/OTaYIFE/1/

My beef with the placeholder pattern was that once you typed a character you wouldn't know what the field is all about. This pattern fixes this.

Surely the placeholder is meant to contain a hint rather than just another copy of the label text, though?

I don't feel that this solves anything that a label + placeholder could accomplish in this demo. The space for the floating label is available the entire life of the form - before, during and after field focus. I just think that this solution is just putting lipstick on the pig of the issue via animations.

Sometimes a little lipstick massively increases form conversions. The more minimal and inviting the form looks, the less imposing it feels to the user.

I've made something similar on a data editing UI back in 2011. But I found that showing the label only on field focus wasn't really suitable for UIs that contained multiple fields of similar data.

Like in the example below[1] there are two fields where you can enter coordinates data, but without a hint you wouldn't be able to distinguish where should one or the other go.

[1] http://www.pmura.com/media/af-ui-input-2011.png

In that screenshot, it would help if the toolkit showed the extent of the textboxes. Having the bare floating text in a sea of white provides minimal context.

Actually it does when you focus on an input. Having borders/backgrounds on every piece of text proved to be a bit messy in my case.

It would've been cooler if I could've capture the interaction, but I don't have access neither to the live webapp, neither do I have a deployed development version at hand :(.

This might be the most beautiful form that I've ever seen. Just gorgeous. I can't think of any way to improve it, and so have nothing valuable to add as a comment.

Not to be that guy, but could you possibly have picked any color other than that particular shade of brown for the header?

Other than that, this is a really gorgeous solution. I'm going to see if I can implement something like this for Android.

Quick example by the author http://codepen.io/iamjordanlittle/pen/AHdfn

This is beautiful. I'm going to keep a tab on this idea for the next time I need to implement a labeled interface in iOS.

Its always nice to see new approaches, but I think the smaller label text is just too small for lots of users.

I hated when I have to choose between label and placeholder, and this has the best of both worlds!

Can someone explain to me the difference between an inline label and placeholder text?

The inline label doesn't disappear when you type something.

A clear cons is the fuckload of problems you get with IE trying to do that.. and people entering their emails where it asks emails and vice-versa. I know there are fixes.. but still, always a pain to deal with.

Reply on news.ycombinator.com