This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > Stylesheets > August 2004 > form label
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Brian 2004-08-26, 12:28 pm |
| I'm wondering what the group thinks is the best way to display the
<label> element. The default rendering in Moz and MSIE/Win (probably
others, too) only changes the mouse cursor (that's a strange term) from
text-select to default (an arrow). That, to me, is too subtle, and is a
bit like "mystery meat" navigation. The user must hover the mouse before
they know there was something special.
Simon Willison suggested changing the cursor to pointer used for links.
I don't like that approache for two reasons: one, it confused links with
labels; and two, it still suffers "mystery meat" syndrome.
I've decided to add underlining to my labels, at least on a trial basis.
The advantage is that it gives the user a clear indication that there's
something different about that text. The danger is that it, too, could
confuse visitors into thinking there's a link. The only distinguishing
characteristic is the color: black for <label>, and the user's default
link color for <a>. But then, there's no real danger to a user clicking
on a label. It will only change focus to the associated field.
Here's an example:
http://www.bonfete.biz/contact/
Any thoughts?
--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/
| |
|
| On Wed, 25 Aug 2004 13:09:49 -0400, Brian
<usenet3@julietremblay.com.invalid> wrote:
> I'm wondering what the group thinks is the best way to display the
> <label> element. The default rendering in Moz and MSIE/Win (probably
> others, too) only changes the mouse cursor (that's a strange term) from
> text-select to default (an arrow). That, to me, is too subtle, and is a
> bit like "mystery meat" navigation. The user must hover the mouse before
> they know there was something special.
Yet there are form controls available, so the label not being clearly
identified as having special powers doesn't really reduce functionality
like true mystery meat. Rather, it fails to notify the user that there is
anything special.
> Simon Willison suggested changing the cursor to pointer used for links.
> I don't like that approache for two reasons: one, it confused links with
> labels; and two, it still suffers "mystery meat" syndrome.
>
> I've decided to add underlining to my labels, at least on a trial basis.
> The advantage is that it gives the user a clear indication that there's
> something different about that text. The danger is that it, too, could
> confuse visitors into thinking there's a link.
I don't like either for the same reason.
> The only distinguishing characteristic is the color: black for <label>,
> and the user's default link color for <a>. But then, there's no real
> danger to a user clicking on a label. It will only change focus to the
> associated field.
No danger, no, but...
> Here's an example:
>
> http://www.bonfete.biz/contact/
>
> Any thoughts?
.... I'm thinking this just feels awkward to me to use. Not the ideal
solution, I think.
Perhaps a dotted under-border, then if the user expects a tooltip you can
add title to tell them this is a label for a form item. Or something along
those lines.
What's hard is the typical user knows links are underlined, so a solid
underline is going to bear similarity to a user experience, for good or
bad. But I can't imagine most people are aware of how form labels work at
any level, and besides browsers don't really do anything special to them
so how would they? Since there's no commonly-known UA behavior to work
from with these, we're inventing whatever usability-friendly method we use
from scratch, which means no pages will do it the same, which means the
users won't ever have a way that they're most used to.
Interesting topic.
| |
| Brian 2004-08-26, 12:28 pm |
| Neal wrote:
> Brian wrote:
>
>
> Yet there are form controls available, so the label not being clearly
> identified as having special powers doesn't really reduce
> functionality like true mystery meat.
Well, ok, but if you lose the funtionality of the label because it's not
apparent, then there is something missing.
>
> I don't like either for the same reason.
Well, poo! :-p
>
> Perhaps a dotted under-border, then if the user expects a tooltip you
> can add title to tell them this is a label for a form item. Or
> something along those lines.
Not ideal. What should one put in the title that isn't device specific?
i.e., "click this text to focus on the 'email' input" is awkward, and
far too concerned with the mechanics, which is a bad idea. What if the
user does not use a mouse? Will they understand "focus"? Or "input"?
> besides browsers don't really do anything special to them so how
> would they?
The problem as I see it is that there is a limted number of things we
can do to distinguish text, and we've already expended our reserve:
underline -> links
dotted bottom border -> abbr and acronym
italics -> emphasis, definition, book title, foreign words, etc.
bold -> strong emphasis
> Since there's no commonly-known UA behavior to work from with these,
> we're inventing whatever usability-friendly method we use from
> scratch, which means no pages will do it the same, which means the
> users won't ever have a way that they're most used to.
Yeah, that's the really awful part of it. I suppose it's no worse than
before <label> was added. But it pains me, because <label> is one of the
few elements that truly enhances a page and adds usability, especially
for selecting those tiny checkboxes and radio buttons.
--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/
| |
|
| On Wed, 25 Aug 2004 15:12:26 -0400, Brian
<usenet3@julietremblay.com.invalid> wrote:
> Neal wrote:
>
>
> Not ideal. What should one put in the title that isn't device specific?
> i.e., "click this text to focus on the 'email' input" is awkward, and
> far too concerned with the mechanics, which is a bad idea. What if the
> user does not use a mouse? Will they understand "focus"? Or "input"?
That's just it - what terminology could you use that would be more
universally applicable AND understood than "Try clicking me ;)"? (Which I
kinda like, except that some users don't click.) As it's a tooltip, it
seems this would be more appropriate a place than any other to put
something dealing with the machanics.
> I suppose it's no worse than
> before <label> was added. But it pains me, because <label> is one of the
> few elements that truly enhances a page and adds usability, especially
> for selecting those tiny checkboxes and radio buttons.
All the old Myst players will click anywhere anyway, so they'll find it
fine. It is a shame though. Those buggers are too useful to be left with
no recognizable rendering.
| |
| Brian 2004-08-26, 12:28 pm |
| Neal wrote:
> Brian wrote:
>
>
>
> ... I'm thinking this just feels awkward to me to use. Not the ideal
> solution, I think.
>
> Perhaps a dotted under-border, then if the user expects a tooltip you
> can add title to tell them this is a label for a form item.
I decided to change it to a dashed border. That's different than <abbr>
and <a href...>. The disadvantage is that MSIE/Win cannot do dashed
border, so it'll still be solid in that (cough)piece of s***(cough)
browser. I changed the color of the border to something a bit more mute.
--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/
| |
| Brian 2004-08-26, 12:28 pm |
| Neal wrote:
> Brian wrote:
>
>
> That's just it - what terminology could you use that would be more
> universally applicable AND understood than "Try clicking me ;)"?
> (Which I kinda like, except that some users don't click.) As it's a
> tooltip, it seems this would be more appropriate a place than any
> other to put something dealing with the machanics.
Eh, I don't like mechanics anywhere. Title != tooltip, even if browsers
present them as such. Who knows what might come along to change that
rendering.
> All the old Myst players will click anywhere anyway, so they'll find
> it fine.
You've lost me. What is "Myst"?
--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/
| |
|
| On Wed, 25 Aug 2004 20:56:37 -0400, Brian
<usenet3@julietremblay.com.invalid> wrote:
> Neal wrote:
>
> You've lost me. What is "Myst"?
http://www.mismatch.co.uk/myst.htm
It's a classic game, the graphic rendering was considered
state-of-the-art. If you're into thoughtful logic games try it.
| |
| Pierre Goiffon 2004-08-26, 12:28 pm |
| "Brian" <usenet3@julietremblay.com.invalid> a écrit dans le message de
news:10iphvla2420dd8@corp.supernews.com
> http://www.bonfete.biz/contact/
Err, in french we say "bonne fête" instead of "bon fête"
| |
| Jukka K. Korpela 2004-08-26, 12:28 pm |
| Brian <usenet3@julietremblay.com.invalid> wrote:
> I'm wondering what the group thinks is the best way to display the
> <label> element.
I think the first question should be "why". That is, what do we try to
achieve by changing the element's appearance?
There are various things that <label> elements may do to help the user.
I _just_ learned that for a text field, you can click on the label, too,
in order to focus on the field! But I don't think that's a particularly
useful feature (though not harmful either).
More importantly, users may need to be helped to see the _association_
between labels and fields. But in the most common designs, the
association is pretty obvious anyway, since each line or row contains one
label and one field.
This leaves, in my opinion, the feature that you can toggle the setting
of a radio button or a checkbox by clicking on its label, as mentioned
elsewhere in the thread. This is something relevant especially to people
with motoric disabilities or motorically challenged situation (try
clicking on a ridiculously small radio button using a portable computer's
excuse for a surrogate for a mouse, while sitting in a moving bus).
And users may even expect, from other user interfaces, that clicking on
the label affects the setting.
For this, I think putting the radio button or the checkbox in a bordered
box together with its label, with a distinctive background color for the
box, makes the situation as clear as possible without being too explicit.
(You could always write some text on the page, explaining how people can
click on the labels, but this gets awkward, especially since you would
then mislead many people who use browsers where things don't work that
way.) There are some examples of this approach at
http://www.cs.tut.fi/~jkorpela/forms/kbd.html
--
Yucca, http://www.cs.tut.fi/~jkorpela/
| |
|
| Pierre Goiffon wrote:
> Brian a écrit
>
>
>
> Err, in french we say "bonne fête" instead of "bon fête"
Wait til I tell the client (my sister) that one! :-D
We've already prepared a page on this:
http://www.bonfete.biz/about/name
In case you don't want to read it, here's the story: In the U.S., where
this company is based, people are familiar with "bon", from the phrase
"bon appetit" if nothing else. However, people are not familiar with the
feminine form, "bonne". Thus, my sister named her company Bon Fête.
--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/
| |
| Nick Kew 2004-08-26, 7:17 pm |
| In article <412d91ad$0$18624$626a14ce@news.free.fr>,
"Pierre Goiffon" <pgoiffon@nowhere.invalid> writes:
> Err, in french we say "bonne fête" instead of "bon fête"
Pierre, don't let it worry you. They mangle English too.
(They being usually 'merkins; I don't know if that incluses Brian)
--
Nick Kew
| |
| Harlan Messinger 2004-08-26, 7:17 pm |
|
"Nick Kew" <nick@hugin.webthing.com> wrote in message
news:9rn102-111.ln1@webthing.com...
> In article <412d91ad$0$18624$626a14ce@news.free.fr>,
> "Pierre Goiffon" <pgoiffon@nowhere.invalid> writes:
>
>
> Pierre, don't let it worry you. They mangle English too.
>
> (They being usually 'merkins; I don't know if that incluses Brian)
The Brits mangled both languages so much after 1066 that they got fused
together and are known now as Middle English.
| |
|
| Nick Kew wrote:
> "Pierre Goiffon" <pgoiffon@nowhere.invalid> writes:
>
>
>
>
> Pierre, don't let it worry you. They mangle English too.
>
> (They being usually 'merkins; I don't know if that incluses Brian)
Those does incluses me. I being 'merkin. Shute, I been malined now.
--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/
| |
| Nick Kew 2004-08-27, 4:16 am |
| In article <10ishmrfmga2m88@corp.supernews.com>,
Brian <usenet3@julietremblay.com.invalid> writes:
>
> Those does incluses me. I being 'merkin. Shute, I been malined now.
Hehe. I meant to put 'They' in quotes, to indicate better that 'they'
and merkins were separate entities with no direct relationship beyond
the fact that a high proportion of the worst offenders are 'merkin:-)
As Harlan points out, the Brits have a longer history of it ...
--
Oook!
| |
| Pierre Goiffon 2004-08-27, 7:15 am |
| "Brian" <usenet3@julietremblay.com.invalid> a écrit dans le message de
news:10is1g2j94k4tef@corp.supernews.com
>
> Wait til I tell the client (my sister) that one! :-D
>
> We've already prepared a page on this:
> http://www.bonfete.biz/about/name
Oh well, good :)
| |
| Pierre Goiffon 2004-08-27, 7:15 am |
| "Jukka K. Korpela" <jkorpela@cs.tut.fi> a écrit dans le message de
news:Xns955183176F404jkorpelacstutfi@193.229.0.31
>
> I think the first question should be "why". That is, what do we try to
> achieve by changing the element's appearance?
>
> There are various things that <label> elements may do to help the
> user. I _just_ learned that for a text field, you can click on the
> label, too, in order to focus on the field! But I don't think that's
> a particularly useful feature (though not harmful either).
Yes it's useful !! Nowdays you've got pretty complex applications on the
web. For now, the vast majority of this complexity is in the back office web
pages... And sometimes you can find a lots of checkboxes ! So its very very
usefull then to be able to check them using the label, it's really time
saving : don't need to point exactly in the checbox...
This is very common in UI, but in a web context <label> is used for that
just since a little time. So users are not used to be able to check a
checkbox or a readio button clicking on its associated label... And you have
to show her/him that he can do it, otherwise she/he will continue to point
exactly to the form object. The best I can see now is to use the CSS cursor:
pointer for labels... Underlining labels is I think a bad solution : you
have to keep the underline form to their common uses (links and "important"
text)
| |
| Brian 2004-08-27, 12:16 pm |
| Pierre Goiffon wrote:
> "Jukka K. Korpela" a écrit
>
[color=darkred]
> Yes it's useful !! Nowdays you've got pretty complex applications on
> the web. For now, the vast majority of this complexity is in the back
> office web pages... And sometimes you can find a lots of checkboxes !
I think J.Korpela was saying that <label> isn't really necessary for
input boxes and textareas. And I think he's right. So for the form on
bonfete.biz, I could just ignore it. But I was asking specifically for
checkboxes and radio buttons.
> So its very very usefull then to be able to check them using the
> label, it's really time saving : don't need to point exactly in the
> checbox...
I think we're all in agreement on this point.
> This is very common in UI, but in a web context <label> is used for
> that just since a little time. So users are not used to be able to
> check a checkbox or a readio button clicking on its associated
> label... And you have to show her/him that he can do it, otherwise
> she/he will continue to point exactly to the form object. The best I
> can see now is to use the CSS cursor: pointer for labels...
> Underlining labels is I think a bad solution : you have to keep the
> underline form to their common uses (links and "important" text)
The "pointer" is also used for links, so this seems to be at least as
bad. And it suffers from mystery meat syndrome, as I mentioned earlier.
The <label> is not very useful if users have to guess that it will do
something, and hover their mouse to find out. An underline would tell
them there's something there just by looking. The underline should be
the same color of the label text, and certainly different than link text.
But I see your point about confusing them. I've changed to dashed green
bottom border. And I may yet adopt J.Korpela's solution of a border
around the label and associated input.
--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/
| |
| Jukka K. Korpela 2004-08-27, 7:17 pm |
| Brian <usenet3@julietremblay.com.invalid> wrote:
> I think J.Korpela was saying that <label> isn't really necessary for
> input boxes and textareas.
Oh, I seem to manage to get misunderstood quite successfully. :-)
What I referred to was the particular effect that clicking on a label
focuses on an input box (or textarea). I cannot find it useful, though I
might miss something.
But using <label> is useful for other purposes, such as helping speech
browsers to associate labels with fields - and perhaps for styling
purposes as well.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
| |
|
| On Wed, 25 Aug 2004 13:09:49 -0400, Brian
<usenet3@julietremblay.com.invalid> wrote:
> I'm wondering what the group thinks is the best way to display the
> <label> element. The default rendering in Moz and MSIE/Win (probably
> others, too) only changes the mouse cursor (that's a strange term) from
> text-select to default (an arrow). That, to me, is too subtle, and is a
> bit like "mystery meat" navigation. The user must hover the mouse before
> they know there was something special.
Yet there are form controls available, so the label not being clearly
identified as having special powers doesn't really reduce functionality
like true mystery meat. Rather, it fails to notify the user that there is
anything special.
> Simon Willison suggested changing the cursor to pointer used for links.
> I don't like that approache for two reasons: one, it confused links with
> labels; and two, it still suffers "mystery meat" syndrome.
>
> I've decided to add underlining to my labels, at least on a trial basis.
> The advantage is that it gives the user a clear indication that there's
> something different about that text. The danger is that it, too, could
> confuse visitors into thinking there's a link.
I don't like either for the same reason.
> The only distinguishing characteristic is the color: black for <label>,
> and the user's default link color for <a>. But then, there's no real
> danger to a user clicking on a label. It will only change focus to the
> associated field.
No danger, no, but...
> Here's an example:
>
> http://www.bonfete.biz/contact/
>
> Any thoughts?
.... I'm thinking this just feels awkward to me to use. Not the ideal
solution, I think.
Perhaps a dotted under-border, then if the user expects a tooltip you can
add title to tell them this is a label for a form item. Or something along
those lines.
What's hard is the typical user knows links are underlined, so a solid
underline is going to bear similarity to a user experience, for good or
bad. But I can't imagine most people are aware of how form labels work at
any level, and besides browsers don't really do anything special to them
so how would they? Since there's no commonly-known UA behavior to work
from with these, we're inventing whatever usability-friendly method we use
from scratch, which means no pages will do it the same, which means the
users won't ever have a way that they're most used to.
Interesting topic.
| |
|
| Neal wrote:
> Brian wrote:
>
>
> Yet there are form controls available, so the label not being clearly
> identified as having special powers doesn't really reduce
> functionality like true mystery meat.
Well, ok, but if you lose the funtionality of the label because it's not
apparent, then there is something missing.
>
> I don't like either for the same reason.
Well, poo! :-p
>
> Perhaps a dotted under-border, then if the user expects a tooltip you
> can add title to tell them this is a label for a form item. Or
> something along those lines.
Not ideal. What should one put in the title that isn't device specific?
i.e., "click this text to focus on the 'email' input" is awkward, and
far too concerned with the mechanics, which is a bad idea. What if the
user does not use a mouse? Will they understand "focus"? Or "input"?
> besides browsers don't really do anything special to them so how
> would they?
The problem as I see it is that there is a limted number of things we
can do to distinguish text, and we've already expended our reserve:
underline -> links
dotted bottom border -> abbr and acronym
italics -> emphasis, definition, book title, foreign words, etc.
bold -> strong emphasis
> Since there's no commonly-known UA behavior to work from with these,
> we're inventing whatever usability-friendly method we use from
> scratch, which means no pages will do it the same, which means the
> users won't ever have a way that they're most used to.
Yeah, that's the really awful part of it. I suppose it's no worse than
before <label> was added. But it pains me, because <label> is one of the
few elements that truly enhances a page and adds usability, especially
for selecting those tiny checkboxes and radio buttons.
--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/
| |
|
| On Wed, 25 Aug 2004 15:12:26 -0400, Brian
<usenet3@julietremblay.com.invalid> wrote:
> Neal wrote:
>
>
> Not ideal. What should one put in the title that isn't device specific?
> i.e., "click this text to focus on the 'email' input" is awkward, and
> far too concerned with the mechanics, which is a bad idea. What if the
> user does not use a mouse? Will they understand "focus"? Or "input"?
That's just it - what terminology could you use that would be more
universally applicable AND understood than "Try clicking me ;)"? (Which I
kinda like, except that some users don't click.) As it's a tooltip, it
seems this would be more appropriate a place than any other to put
something dealing with the machanics.
> I suppose it's no worse than
> before <label> was added. But it pains me, because <label> is one of the
> few elements that truly enhances a page and adds usability, especially
> for selecting those tiny checkboxes and radio buttons.
All the old Myst players will click anywhere anyway, so they'll find it
fine. It is a shame though. Those buggers are too useful to be left with
no recognizable rendering.
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|