In-Field Labels: A Better Way + jQuery Plugin | Hacker News Reader

In-Field Labels: A Better Way + jQuery Plugin

fuelyourcoding.com

43 pointssant0sk124 comments

Once the user has filled in anything then the label is completely lost. How is that better then having the label above or to the right where it is always viewable?

It's sort of lost - the info is still there in the form of the information they entered, which is a pretty strong hint. You're not likely to forget your name or website url, for example.

You still have a point about the usability of labels outside the form field, especially given the caveat in the article that "this plugin still has problems when the browser tries to pre-fill the fields".

But it's still a useful technique because it makes the labels a lot easier to read because it's possible to left-align both the labels and the input fields. Just to give you a sense on how much thought needs to go into the graphic design of labels and form fields, here's a breakdown of the pros and cons behind labels arranged vertically, left-justified and right-justified:

http://www.lukew.com/resources/articles/web_forms.html

There's so much to learn about form design that the guy milked into an entire book.

The link has great info. Thanks!

LukeW did a talk in March that goes in to more depth then that article. It's definitely worth listening to: http://www.lukew.com/ff/entry.asp?794

I think it just saves space in applications where UI space is scarce. It's also a useless trick that amateurs can abuse for fun. Yay!

A plugin such as this has a very limited and specific set of use cases. The most obvious one being a search box that says search inside, but once it receives focus it goes away.

Thank you!! Finally someone who shares my sentiment!

What's worse is that this doesn't gracefully degrade. If you have javascript disabled your text will be written over top the label text and is completely unreadable.

Well instead of styling all labels in the css, you could create a css class for the overlay effect and then add that class to the labels (all or just some etc.) on the form with jquery. That way it's unobtrusive javascript and works when javascript is disabled without mucking up your form.

It's not completely lost. If you delete the content you fill in, the label returns.

The jQuery example plugin does this a tad better, but with out the special fade out a bit on click effect, which I actually prefer.

http://mucur.name/system/jquery_example/

I agree. Fading the text but not removing it may be confusing to some users who won't understand why there is text they can't delete in the text box.

It is pretty, though.

The benefit of the In-Field Label plugin is that there is never a "temporary" value in the field itself. Since the label is overlaid, the field remains empty. There is less to check for server side if a form gets submitted prematurely.

Better to use e.g., vertical or left-justified labeling and use the in-field support to put in example values.

Assuming, on the examples page, that there is no javascript being executed on page load except the initialization of the examples:

For six form fields, it took 500ms (according to firebug's profiler) to initialize on a 2.4ghz core 2 duo. Granted, I'm using Firefox 3, and not 3.5.

I'm assuming that this scales linearly with each form element that this trick is applied to, in which case a page with 12 form elements would take 1 full second to initialize the javascript.

I'd stay away from this if you have more than two form elements using it. It's bound to slow down the user experience unbearably.

I think you are including the jQuery load time as part of your example. If you have nothing else on the page (no other jQuery, etc) then don't use a plugin.

On the examples page, I profiled the five InFieldLabel calls at a total of just over 28ms. Firefox 3.5, 2.2 Ghz Core Duo. Its not the field calls that take 500ms, even in Firefox 3.0.

Well, if the jQuery library is loaded (file-wise), and nothing is used from it - well, nothing should init.

What I profiled as taking that long was the jQuery init functions, which I assumed were required (and called by) the plugin.

Then again, I'm not as familiar with jQuery as I once was. All I know is that I don't like method chaining (impossible to set mid-line breakpoints and try/catch blocks), the extended element (if it's anything like prototype) is extremely heavy and not needed a majority of the time, and if you use massive amounts of it (see: slashdot) the user experience is deleteriously affected.

And really, 500ms initialization (even if it's jQuery and not the plugin initializing, that's a long time) for a user-experience-worsening toy like this.. I don't see the point.

Since when did labels cause harm?

The main pain point of that is that you can't see what field means what once you've got content in it.

Oh and its dreadful if you disable Javascript.

The web pretty much runs on JavaScript these days, so anybody disabling it should be used to dreadful looking sites. I don't think GoogleBot minds too much either.

Labels don't cause harm, but if you are trying to put together a tiny login box on a page, or a condensed form, etc. If it’s a longer in page form, you shouldn't use this plugin.

As far as Javascript is concerned, I am going to add that into the plugin. Basically, add a class that moves the label over the field when the script is run. Good point though.

This type of plugin would be useful where space is a premium. A good example is the Site's contact form. You are correct to say that when 'javascript' is off the label should be outside the field. With javascript on it is simple to adjust the css to move the label over the field.

I voted the effort and the plugin.

This isn't a better way. Sure it looks neat, and seems better to people who know about this stuff, but people who aren't on computers every day might need to spend an extra minute figuring out what's going on when they try to select the text that is still there when they click on the field and they can't. So yeah, great for nerds, but not great for usability.

The link above posted by alabut is awesome, thanks.

Love this, makes more sense in small areas.

Terrible HCI. Another form of mystery meat.

Giving some people jQuery is like giving a monkey a gun.

Reply on news.ycombinator.com