Making Forms Convert Through Awesome Inline Labels

Jonathan wrote this on in . It has 23 comments.

Forms are everywhere on the web – it's the primary way users can interact with a web-based system. If your site or app uses forms (and we'd bet that it does) those forms need to be well designed, or users aren't going to follow through. They may not sign up for your service, they may not fill out their demographic information, they may not even log in again after sign up.

We love well-designed forms here at ZURB, and recently we've been exploring some cool new tricks for how we can display form inputs and labels in a concise, usable and totally awesome way.

Inline labels are nothing new – in fact the easiest way to label a field is to simply set the field value up front and blow it away when the field gains focus. Easy, right? But what if the browser focuses on the first field right off the bat...what field is it? The label is gone, so to find out what we're supposed to type we have to switch out, then back...what a terrible interaction! This little jolt could be the difference between a conversion and an abandoned form. Happily, there's a better way.

The first implementation we saw of this was over on the MobileMe login screen. We sniffed around a little and figured out how to create that type of interaction ourselves in an abstracted fashion – now we can use it when we want with a simple plugin. You can too. Check it out:

The HTML

Nothing shocking here: in order to get the effect we want you need three elements.

  1. A container div for the input (we'll use span.wrap)
  2. A label (label.overlay)
  3. A form input (input.input-text)

The only piece here beyond even the most basic forms is the input/label container which actually works for us, allowing us to tailor our CSS and Javascript to only the elements we want. This technique is cool, yeah, but with great power comes great responsibility: we want to use this in certain circumstances but certainly not everywhere.

The CSS

The CSS is dead simple. For our example we'll set all our inputs to a width of 200px and a font-size of 18px. You don't have to use static widths for this to work but it simplifies our example.

Now we position the label behind the form element and set the form element background to "none." The label then becomes the form element background and between the two we can still create any form element design we'd like.

The Javascript

There's nothing too fancy about the Javascript but there are a couple of nuances. At ZURB we generally use either JQuery or Prototype – this example uses Prototype to select the element but how you select these is totally up to you.

The Javascript has to accomplish a few goals:

  1. When the user clicks into an element, reduce the label opacity by half
  2. When the user starts typing, reduce the label opacity to 0
  3. When the user switches out of the field check if the field is empty - if so, bring the label back to the original opacity

The observer snippet in the middle of that javascript code block solves an odd little problem for us: autocomplete doesn't fire javascript events in most browsers. If Firefox drops in your username and password for you, the labels won't fade back like they should. We get around that by checking the field value on a timer – the user will see a flash after the autocomplete and everything will be just ducky. Cool, huh?

Et Voila! Super Awesome Form Labels

When you've got these few pieces in place you'll have forms that look more or less like these. We added some styles to the form inputs for the grey borders, etc – but you can handle all that. We also threw in some sweet CSS3 transitions that make these elements really sing in cutting-edge browsers.

Use Sparingly

This is a cool effect that solves an obnoxious little usability problem for inline labels, and we're getting some great use out of it already on the public facing pages for Notable, our upcoming feedback tool – but we don't use it everywhere and neither should you. It has strong novelty appeal to help you get that conversion, and the interaction is pretty smooth, but in a large form ease of comprehension is more important than slick presentation. Use your best judgement: we trust you.

See more Product Engineering and Design Jobs on Job Board from ZURB.

23 comments

RichardZ (ZURB) says

The 3-D illustration under the heading "The CSS" is bad-ass. Great visual representation of something that is lost in linear code.


dannyoyello (ZURB) says

Poorly done inline labels say, "We never even watched ONE user try to complete this form." Great job!


Jonathan (ZURB) says

@RichardZ Thanks! It's great the little touches we can add that illustrate things like code and require really minimal time investment. That illustration was the work of maybe a couple minutes in Illustrator.


chris (ZURB) says

Nice explanation of the problem and solution in a manner that both tells how to achieve the desired end result and is easy to understand the usefulness in the larger picture.


Dries (ZURB) says

Nice technique, nice explanation, display in IE6 could use a bit of magic though :)


Jonathan (ZURB) says

@Dries I think we can all agree that IE6 could use a lot of magic :)


Joseph (ZURB) says

Instead of using the opacity setting, wouldn't it be more compatible if you just changed the font color closer or further from the background color? Of course this wouldn't be as portable because you might have different background colors for different pages but you could just make different rules for different pages or use the JavaScript to extrapolate the background color of the the containers or something..


Jonathan (ZURB) says

@Joseph You're right that the opacity setting doesn't come across in older browsers, however you can use -moz-opacity for Firefox 2, and use filter: alpha(opacity=XX) for IE6 and IE7: which works surprisingly well. They won't get the cool transition fade, but short of using jQuery that's just not gonna happen.


Alexander Bickov (ZURB) says

Nice example for professionals


Brad Sherrill (ZURB) says

Excellent


Ben Bodien (ZURB) says

Great technique! I'll definitely add this to the toolbox for future projects.


Elizabeth K. Barone (ZURB) says

Although this is a really cool effect, I have a couple of problems with it: it doesn't display well in Firefox, and in IE8 the background label is too dark, causing the user's input to be really difficult to read.

I'd rather use the effect that makes the label disappear when the user clicks on the field.


Stormy (ZURB) says

Cool effect, but a couple potential problems with this. First, what if the user doesnt fill out the form and submits? Do you get a buncj of bogus data shipped in with these dummay field data? Many times we run server-side checks as well, where if the form is empty, that triggers validation client and/or server-side. That would fail in many such scripts. Also, having a user download a giant Prototype library just to fill out a simple form field is a waste of kilobytes and time. That also can destroy usability. Also, what happens for mobile browsers or minis that dont support scripting? What happens for the 11% of people that dont have javascript enabled or run anti-scripting software? What happens for people that depend on tooltips for clues to what the form does? Many disabled people run screen readers that are setup for tooltips that would fail here.

JavaScript may be the coolest trick now for solving usability issues but its also creating its own. (This form itself was almost impossible for me to fill oput as your script kept refreshing on onChange. Bad design!) I think two many of the younger web kiddos are sucked into scripting as the end game of web design when in many cases its killing what once were simple, very usable and fast web page parsing. I would consider a script free webpage test online compared to one packed with all these circus tricks and see which one your users actually prefer...


Matt (ZURB) says

@Stormy Interesting point, however I tested these forms in elinks and was pleased to see them degrade perfectly. Good markup can ensure that JavaScript heavy pages still render properly on mobile devices and play nicely with screen readers.

Regarding the prototype library, yes it's large but if you minify, gzip and properly set the cache-control header you can greatly reduce page load time spent on this asset.

Most sites that appear slow due to large js libraries are failing to implement these tricks or are implementing them incorrectly.


Jonathan (ZURB) says

@Elizabeth The benefit to this approach over the values in the fields which disppears onFocus is that people who click in the first field immediately lose the input label - they may not know what field they're typing into. By keeping the label behind the input and just fading it back, user's who click (or pages that autofocus) will still display the label, until the user starts to type (and presumably is aware of what they're typing).

As for IE8 we're only just getting into IE8 testing - haven't had as much exposure as we'd like to the tricks of correct IE8 display. Guess it'd be too much to ask that IE8 just render everything correctly, huh? :)


Colin (ZURB) says

Has anyone ported this to jQuery at all? My JavaScript skills aren't the best, unfortunately, but I love the technique.


Jonathan (ZURB) says

What sort of conversion rate increase are we talking here?

Did you do any rigorous A/B testing?

You titled the article as if you knew these items, which are very important... but seem to be absent. Are you guessing? Are there any numbers at all?

Inquiring minds, and all that...


Marcelo (ZURB) says

Jonathan or someone!

Could you please illustrate the .js code as he would in jQuery?

Thanks!


Quin (ZURB) says

Brilliant little tut !

There is just one thing that I can´t work out on the MobileMe page, how dit they get the span tags that contain the custom checkmark to be clickable and behave like normal checkboxes?

Does anyone here know?

Would love to make that happen on one of my projects.


Quin (ZURB) says

Sorry about the silly question.

I see now how its done. I guess the same technique above for text fields would be true for any input control.


prisme (ZURB) says

great tut, well explained and illustrated, except for the part about the Timed Observer.

I've translated the Prototype code to jQuery, and spent a good amount of the time understanding that the Prototype Form.Observer() was just a setInterval() with more options ...

Also, I've used jQuery's animate() function to get the animation even in firefox and let it take care of the opacity cross-browser issues. And added a little tweak to add the inside

here's my jQuery code :

$().ready(function(){

// Select all textboxes and assign them to an array
var textboxes = $('form.awesome input.input-text');

// Iterate through all textboxes in the form
textboxes.each(function(index, input){

var label = $(input).prev();

label.wrapInner("<span></span>")
label.children("span").animate({opacity: 0.6},0);

// check for autocomplete by browser
if( index == 0 ){
  setInterval(function(){
     textboxes.each(function(index,inputX){
      if ( inputX.value!="" ) {
        $(inputX).prev().children("span").animate({opacity: 0},0);
      }
    });
 }, 100);
}

// Fade the label back when a field gains focus     
input.onfocus = function(){
  if (input.value==""){
    label.children("span").animate({opacity: 0.4},200)     
  }
}

// Check if a field is empty when the user switches out
input.onblur = function(){
  if (input.value==""){
    label.children("span").animate({opacity: 0.6},200)        
  }
}

// Fade the label back if a field has text      
if (input.value!="") {
  label.addClass('hastext');
}

// Fade the label back when the user starts to type     
input.onkeypress = function(){
  label.children("span").animate({opacity: 0},200) 
};

});

});


Wandaufkleber (ZURB) says

Hey prisme, many thanks for the great code, Maik



Get a job, nerd!

via Job Board from ZURB