Really enjoyed hearing your thoughts on this Matt. Thanks for writing this and being so polite about it at the same time. I am critical about the pattern so I appreciate your kindness and thoughtfulness that went into this.

Here’s my response to yours inline:

I really appreciate and admire his thoughtfulness of the tiny details in his articles

They aren’t all tiny details. Some are big details :)

a form alone isn’t going to boost conversion rates through the roof.

I absolutely disagree. The design details of a form alone can have a huge impact on conversion rates.

You have to create enough value and solve a big enough problem with your content so a user is actually motivated to use your form in the first place.

Yes this is absolutely true.

But this statement doesn’t stop the floating label pattern (or other patterns) being problematic. Best to get both right.

I myself have done no official float label split testing and can’t confidently recommend the pattern over a standard label, based on pure research alone.

I have not done split testing either.

Everyone kinda goes a bit mad if you haven’t proved it with numbers but statistics don’t tell you everything (there’s a phrase for that!) and it doesn’t excuse us from using our brain from analysing and using other people’s deeper research to form reasons against an approach.

Also the tests themselves need to be diverse. Unless you can guarantee that all of your users find small, low contrast, moving text easy to read. I doubt that is the case on the open web.

But I can say that I recently used float labels on my Intro to Icon Design course form and saw a conversion rate of over 30%. According to my quick research, that’s 10 times higher than the average opt in form that generates only 3% conversions.

Would the conversion rates been higher had I not used float labels? My gut says “no”, but I have no data to back that up.

You already stated honestly that this doesn’t mean much but I’m finding it hard not to ask why did you bother stating this? It suggests that it’s fine, when the points in my article (just common sense mostly) show otherwise.

However, If you really wanted a note or a hint, you could move it below the input field and simply push the other field down a bit.

You could, but that means it would require ARIA to connect the hint to the form control. The trade off is that assistive technology has less support for ARIA meaning it will exclude people unnecessarily.

Debating over hint placement is futile, unless you have an extremely clear picture of the exact problem trying to be solved with a form in the first place.

I wouldn’t say that. Putting the hint above the field allows us to avoid using ARIA (see benefits above). Meaning we can put it inside the label (or legend) making it fully inclusive by default.

Also, when focussing the input on mobile, the on-screen keyboard may well cover a hint if below the field.

In some cases hints or labels are incredibly helpful and in other cases they are a bandaid on a poorly designed form. It simply can’t be an absolute standard out of context.

Absolutely.

I’m talking about the case when they are incredibly helpful. Sometimes they are helpful on one particular field in one particular form. Why use a pattern that is constraining out of the box?

Furthermore, text size is relative to a design in general — not float labels themselves.

Floating labels use size (and colour, and space and animation and typography and etc). The pattern and the qualities of the pattern are inextricably linked.

I’ve never seen floating labels that have large text. Perhaps there is a floating label that has large text — I’ve just dug a little deeper and found your one but it still suffers from many other problems.

And if the user increases their text size a floating label is probably going to break the layout.

I don’t deny that 12px can be harder to read than 18px, but I see a float label as an artifact of the past, rather than a clue to the future.

Making the label hard to read, even if it’s after they started typing still makes the text hard to read. In some respects we may as well make it disappear instead of make it smaller but we know this is a bad idea — small text is like no text for some people.

[With regards to “they need space”…] If you agree that the Float Label is an artifact, rather than an instruction, you might also agree that it’s ok to go slightly smaller in text size than a standard label.

I don’t really think the artefact is a reasonable excuse to allow the text to go small. If small text is hard to read, then it’s hard to read. It might be slightly less hard to read because it was once big, but it’s still hard to read. How many times did I just say hard to read? :)

So if you save 8px on 5 input fields in a form, you’ve saved a total of 40px. That’s roughly the same height of a button on mobile screen.

Would that helpful for your project? I don’t know. You, as the designer, will have to decide that for every use case you come across.

I don’t recommend pixel pushing either as it’s often of little to no value but in this case it’s to do with the size of text so it’s an easy way to make interfaces inclusive.

If that adds 40 pixels to the scroll height then so be it. If it hides a button off screen then again so be it. I like the phrase clarity over brevity.

[With regards to the design that looked cleaner…] Then, I designed the form on the right as an alternative to the shear amount of craziness going on in the form. We all agreed that it felt more clean, less overwhelming, and better overall.

I agree that it looks cleaner. A cleaner interface is less overwhelming just like you say and whilst scrolling isn’t a problem, if we can minimise it that’s great.

However, users don’t just look at a screen. They interact with it. In this case they fill out the form. In which case the filling-a-form experience needs to be good too.

Like you say, users need to be compelled to complete your form in the first place. In which case 40px is no big deal.

You can see that even though only half of the fields were top aligned it still resulted in over 420px of vertical height saved.

It saves space but at what cost?

Why not remove whitespace and squeeze it all in? Why not reduce text size to 6px? Why not reduce the horizontal line which occupies 20px or more? Why not reduce the height of every field by a pixel top and bottom? Why not get rid of the progress bar? etc

We probably don’t want to follow all these ‘recommendations’ because they make the interface hard to use. But they would save a lot of space, reduce scroll and elevate the submit button.

Same goes for floating labels.

We even had a few impromptu tests where we asked people, “which of these forms looks less overwhelming?” And they agreed the form on the right seemed better.

Right, but this means little. Good rule of thumb for testing is not to ask users this sort of question. Instead to give them tasks and observe. In your case ask the user to complete both forms. Observe the differences. But that of course is not the only variable.

Hang on a sec. If an animation is done well, then it is by definition “well,” “good,” “satisfactory,” “to be desired,” etc.

Therefore the phrase “distracting and disorienting” can’t coexist with “done well.”

What I meant be that is implemented well in code so that it isn’t janky. Not that it is or isn’t an appropriate use of animation.

I know that I’m incredibly biased, but when I fill out a form that really nails the Float Label animation, I get a teensy tiny little dopamine rush when the animation resolves and I move on to the next field. A small sense of completion that wasn’t quite there before.

It’s reminds me of a game where something visually happens in the wake of your character’s path. Like a footprint.

He he. I get what you mean. For you (and people like you perhaps) with your great eyesight, there may well be no problem and a bit of a boost emotionally. I dunno. :)

Low contrast has nothing to do with a float label and has everything to do with size and color.

Like I said above with regards to size. Floating labels use size, colour, space, typography and animation. Size is absolutely to do with floating labels.

We can’t decouple this problem unless of course floating label solutions have high contrast large text. I’ve never seen an example that doesn’t suffer from several of the problems in my article.

Plus to solve problem number 6 in my article, they need to be greyed out. But greyed out is hard to read. So round and round and round we go again. :)

[With regards to being mistaken for a value…] I can’t matter of factly say that this won’t be an issue. I don’t believe it would be in many cases, but making that assumption without hard data would be ignorant on my part.

I’ve observed this myself and research on the subject shows this to be the case. Though of course, not all colours, combinations and forms have been conclusively covered through research as that is Sisyphean.

[With regards to inconsistency with a select box…] This is a design problem, not a float label problem. Shopify does an incredible job with the float label on their input fields and select boxes.

I’ve seen the Shopify ones. You’re the second person to mention this to me. The shopify ones are prolematic. Select boxes too — on desktop the menu hides the label when open.

[With regards to cropped text…] This isn’t a float label issue per se, this is a bad form design issue.

No one should ever have a placeholder label that long.

That is a statement that I absolutely know isn’t true. Sometimes a hint consists of a lot of text to provide clarity to complex form fields. A floating label (or a placeholder) is constraining here.

And if you do truly need to ask a two line question as an input label, then I 100% recommend NOT using a float label.

Isn’t it preferential to use a pattern that works with (varying) content?

Some fields need a long hint, some a short, and some no hint at all.

The floating label can’t accommodate (varying) content and would therefore create an unnecessary inconsistency in your interface (if some used floating labels and others didn’t).

[With regards to standards…] The float label was created AFTER this standard was written. Is it not worth challenging original assumptions in old documents after new ideas arise? Especially ones that are getting adopted so quickly.

Is it reasonable to get curious about this rather than dismissive?

Standards and browsers aren’t always right. For example, they allow the placeholder attribute which as you know is very problematic. However, standards and browser vendors get way way way more right than they do wrong and I wanted to promote the standards here as it adds some value.

It’s good to challenge the way things have always done. Don’t stop doing that. But try and design new things with an inclusive lens — that’s where the real challenges are.

There’s got to be some valid reason why Google adopted this pattern as a standard in Material Design Guidelines.

This is appealing to authority. Google and many other ‘authorities’ do silly things all the time.

I wasn’t privy to the tests they run. I wouldn’t assume anything.

Summary

Thank you for writing this Matt. Really enjoyed your commentary on this.

In summary I think that we can’t possibly decouple the design treatment of floating labels from floating labels themselves. Without design (space, colour, contrast, animation) what is there?

What is good though is we certainly agree on the following:

• There are better and more productive techniques for improving form design
• We should spend time on all facets of form design
• Users want the outcome
• They can be entertaining I ‘spose :)