7

Just made the finishing touches on a new technique I developed for using a label in a textbox.

Here is the live demonstration: http://powabunga.nfshost.com/bestform/

There were a few things I was trying to accomplish here: With traditional inline labels, the label is actually programmed into the textbox, and sometimes doesn't go away quickly enough once the user enters focus.

In addition, because the label disappears, the user must keep a memory of each field they're entering rather than seeing the label persistently to the left of their input.

On some occasions, something goes wrong with the label and it actually stays in the input box. With this method, the label is actually a separate HTML element and could not possibly add itself to the user input.

I've also squeezed in some of my own favorite UI/UX practices, like automatic focus on the first field upon load.

Anyway, what does the community think of this method? What problems, if any, could arise from using these kinds of inputs?

Improve this question
9
  • Please don't auto-focus input fields unless the form is the sole purpose of the page... I really don't like pages that take input focus away from where I put it just because they happen to have a search box or a login form embedded somewhere as well.
    – Marjan Venema
    Commented Sep 14, 2011 at 7:12
  • 2
    Other than that: interesting concept! Is there a way to keep the cursor from - visibly - jumping from sort of the middle to the left when you just mouse click from control to control and go from one of the names to the e-mail one?
    – Marjan Venema
    Commented Sep 14, 2011 at 7:15
  • Thannks, Marjan. Yeah, that's probably the one thing I'm most unsure about. The idea there is that I want the user to be able to (upon clicking) enter in the data right next to the label. Then, the inputs are vertically lined up for review. For faster form fillers who tab into the box, the input also stays vertically inline. Since the movement is programmed to "mouseup" and not "click," the user can drag over a part of their input if part of it needs to be changed, without the whole input shifting upon drag.
    – Adam Grant
    Commented Sep 14, 2011 at 7:29
  • 2
    It's working okay for me.
    – Adam Grant
    Commented Sep 14, 2011 at 8:14
  • 1
    Please describe your technique in your question rather than just providing a link (which will likely go stale at some point rendering the question useless)
    – DA01
    Commented Sep 14, 2011 at 14:13

3 Answers 3

Reset to default
1

I'd like to see how this rolls out to more complex input fields.

I suspect it makes the fields less scannable to easily determine what needs to be entered before starting.

I have concerns about styling other input types in the same way, such as drop downs, or mixing with inputs that do not work like this such as checkboxes and other input types.

I also don't know how you deal with inline examples or hints - I guess that could still work. eg. slashdot sign up:

enter image description here

So - yes scalability is my concern - but I like the concept. +1 for thinking outside....errr...inside the box.

By the way - I in no way condone Slashdot's ridiculous communication of the set of allowed characters and implied restrictions on choosing a nickname!

Improve this answer
5
  • Excellent point, Roger. That definitely is a concern. I'll have to tinker around with more diverse forms using these inputs. "I suspect it makes the fields less scannable to easily determine what needs to be entered before starting." Why do you say that?
    – Adam Grant
    Commented Sep 14, 2011 at 7:38
  • "I also don't know how you deal with inline examples or hints" I suppose you'd have to favor sub-positioned labels like the one I have for the email. Also, I think this is best for some forms but not others. For instance, I wouldn't use this for a lone search box.
    – Adam Grant
    Commented Sep 14, 2011 at 7:41
  • @ajkochanowicz re: 'fields less scannable'. Because when you have the labels outside the boxes, there is no interleaved interference from the horizontal lines, so the vertical list of labels is easier to scan down. Inside the boxes, the labels are harder to visually lift out to the foreground to scan down the list. Again this was especially with regards to longer forms rather than the minimal signup/signin you have in your demo.
    – Roger Attrill
    Commented Sep 14, 2011 at 8:06
  • I'm with roger here, moreover by including labels inside the boxes and the fact that they persist means that you seriously reduce the length of characters that are permissable in the field.
    – colmcq
    Commented Sep 14, 2011 at 8:38
  • True, although I would argue that's a glass half empty/half full problem. In other words, it depends on whether not doing this is an alternate to having top-aligned labels or left-aligned labels. For the latter, the character limitation could be the same.
    – Adam Grant
    Commented Sep 14, 2011 at 16:25
1

It's an interesting idea.

I've been campaigning passionately against hints inside textboxes: see my article Don't put hints inside text boxes in web forms That's because I have lots of direct evidence to support my view that they are a bad idea.

I'm even more passionately against labels inside boxes, but up to now that's been simply because they just seem like a really stupid idea to me from various informal observations of people working with them and from personal experience. I haven't had the opportunity to test with them, because my clients have also considered them to be a really stupid idea and haven't implemented them.

Now, what you have programmed here isn't so much "label inside the box" as "box around label and space to type". In the days of paper, we called this style "caption in box". The crucial differences are: - the label persists as the user is typing - there is space for the user to type.

I'd love to see what ordinary everyday web users make of it. My concern would be that it's not immediately obvious where you are supposed to type. Generally speaking, "not immediately obvious" = "bad idea" when it comes to forms.

Anyone tried testing this with people who are not UX designers/programmers?

Improve this answer
2
  • 1
    The premise of your argument appears to be that help text would trigger users to believe that it is the default text of the field. That's certainly an issue to be aware of, but one that should be resolvable in a lot of cases through proper visual design and markup. HTML5, in fact, now even has a placeholder attribute specifically for help text (which I should be clear is different than a proper LABEL)
    – DA01
    Commented Sep 14, 2011 at 20:24
  • After reading some of the comments here, I think I have a better idea on how to implement, I'll update this later. For now, I think the key is--if this is a useful feature--understanding when it is useful. I have an idea.
    – Adam Grant
    Commented Sep 15, 2011 at 19:58
0

It's cute and clever but I don't see what purpose it serves. The typical reason for an in-field label is simply to compress the size of the form on the page. Since the label remains visible, I'm not sure how placing it inside the field is an advantage. Might as well just leave it as a normal label to the left.

From an HTML standpoint, I don't see an actual label on the page for each field. That's an important tag and needs to be part of the form itself for accessibility reasons. You're also using an alt attribute on an input tag. If you're looking to just be able to store text there, consider the placeholder attribute or data- attributes (though note that placeholder is not designed as a label replacement, though many use it that way)

Improve this answer
4
  • Thanks, DA01. I'm actually going for speed here, so I wouldn't consider left-aligned labels an alternative in this case. It takes longer for the user to parse. It's meant to be an alternative to top-aligned labels. Even though it "becomes" a left-aligned label, the user can treat it otherwise since she can click anywhere in the textbox, even over the label. The purpose it serves is speed (user's eye-movements are more linear with fewer fixations) and label persistence (the label remains as a guide while the user is typing.)
    – Adam Grant
    Commented Sep 14, 2011 at 16:22
  • And you're right about the "label" attribute. I was thinking "alt" was the accessibility attribute. My bad.
    – Adam Grant
    Commented Sep 14, 2011 at 16:23
  • well, what you have is pretty much left-aligned labels (your label text is to the left of the user-input data)...just that they are inside the form field. Not sure what the benefit of that is. (FYI, a person can click the LABEL tag to focus on the field as well). Again, it's interesting. Would be good to send it through some A/B user testing.
    – DA01
    Commented Sep 14, 2011 at 17:28
  • and label isn't an attribute. It's a tag. Each input should have a matching label. What I've done in the past for in-field labels is to make standard top-labels (label above the input) then move it via js or css so that it's visually on top of the field.
    – DA01
    Commented Sep 14, 2011 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.