W3C home > Mailing lists > Public > www-forms@w3.org > February 2007

Re: checkbox labels

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Sun, 4 Feb 2007 21:19:01 +0000
Message-ID: <640dd5060702041319y3f18534fh3c749613f5ee59ab@mail.gmail.com>
To: "Kirk.Johnson@zootweb.com" <Kirk.Johnson@zootweb.com>
Cc: www-forms@w3.org, www-forms-request@w3.org

Hi everyone,

I think the problem here is that XForms deals primarily in abstract UI
concepts, whilst the design world deals in rather specific widgets.
That doesn't mean the XForms community wants to ignore design and
layout considerations--far from it; we do want to bridge the gap, and
make it so that XForms as a language is capable of producing exactly
what a designer wants. But it's worth flagging up the different
starting points, right at the top, not to show different goals, but to
point out that the terminology has been extremely confused.

For example, people are using the notion of a boolean control and a
check-box interchangeably, as if they are one and the same thing. But
it is not necessarily the case. The XForms select control is a good
example; if @appearance is set to "full" then many processors will
render the control like this:

  Tags:   [ x ] XForms [   ] XPath [   ] XSLT [ x ] XML

So it's clear here that labels on the right of a check-box are well
used (in other words, all is harmonious between the design world and
the XForms world :)...but it's also clear from this that check-boxes
are not always used to represent straightforward 'booleans'.

If that was all there was to it though, then it would appear that
we're all in agreement, and from the design world's standpoint,
everything is in its place. However, I'd like to show that putting a
label to the _left_ of a checkbox is not so shocking, and can be
intuitive for a user.

Let's try first to break a 'boolean control' down into its
components--at least from an XForms/logical point of view. I'll work
backwards from other controls, to try to arrive at a boolean seems to

Imagine I have a xf:select1, with two choices--'yes' and 'no':

  <xf:select1 ref="replace">

Although rendering is secondary to the form logic, we know this would
most likely render as a 'drop-box' on a GUI-based system, as
illustrated in the screenshot here:


Now, if we add @appearance="full" to our control, we ensure (as much
as possible) that the choices are 'always visible', i.e., instead of
the user having to go find the choices, as with the previous example
(because @appearance="minimal" is the default), the choices are always
available, as illustrated here:


Note that the control has now been expanded from its 'drop-box'
appearance to something more like this:

  Replace:       ( * ) Yes   (   ) No

As you can see, we now have two 'levels' of labelling; we have the
label which marks out the control that we need the user to provide a
value for ('Replace') and then we have two more labels to indicate the
possible values that can be selected--labels which help the user to
make a choice.

(Erik has also made this point about two levels of labelling, earlier
in time than my email, but later in the thread because I wrote my
email in two sittings. :)

Now, let's change the value for @appearance to "compact", and let's
say that when there are only two choices in a xf:select1, it's a
perfectly acceptable 'normalisation' to render those choices as a
two-state check-box, and to remove the two second-level labels. This
seems perfectly intuitive for the user, provided that the primary
label is clear. All we've said is that these two renderings mean much
the same thing from a user-experience perspective:

  Replace:       ( * ) Yes   (   ) No

  Replace:       [ x ]

So given the similarity--and how easy it is to understand--why would
the mere use of a check-box to capture user input suddenly mean we
have to flip the label to the right-hand side? Why is our user going
to have problems with the rendering just shown?

To flip this back round again, what this also means is that a control
which is bound to an xsd:boolean can quite legitimately be seen as a
xf:select1 with two values--true and false. It may well be the case
that a voice system, for example, renders as a check-box in this way,
as two choices.

My point therefore is that making some hard and fast rules based only
on the fact that we have 'a checkbox' is flawed to say the least,
since all these rules do is favour form over content, and tell us
nothing about what the control _represents_.

Instead, we should look at the concepts we need to reflect to our
users, and try to use the best UI to convey them. In this case, I see
nothing wrong with saying that a label can appear to the left if the
control represents a full value in its own right, and on the right if
the 'control' is merely an option from a list which in turn is used to
set the value of a containing control. (Which I believe is what Erik
is arguing.)

There are many other issues going on here, I think, such as the use of
UI components like dialog boxes, and the way UI works in
software--which is what most people in this thread have been referring
to--versus the use of UI for data capture, which generally has a
different feel to it, and to some extent a slightly different set of
conventions. Of course we want to harmonise, and ensure that XForms
can be used for defining any user interface, but to do that we need to
understand what it is that we're representing, and we won't be able to
do that by simply referring to 'check-boxes'.



Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from

On 02/02/07, Kirk.Johnson@zootweb.com <Kirk.Johnson@zootweb.com> wrote:
> www-forms-request@w3.org wrote on 02/02/2007 04:06:23 AM:
> > I agree, however, that the aim should be to allow the designer to choose
> > and specify the location, if possible.
> I agree that choice would be best, but mostly to accomodate cultural
> differences in a shrinking world.
> I don't want to come off as holier-than-thou on this design convention. I
> freely confess: in my past, I have located labels on three of the four
> compass points around a checkbox - but never (cringe!) *under* a checkbox
> ;) And we are talking about a *convention* here, not a *commandment*
> handed down from on high.
> The fact that I have located boolean labels other than on the right
> doesn't make it a good idea, though, as *logical* as it might have seemed
> at the time. Many of us programmers place too much weight on logic in our
> UI designs, when a little more attention to convention would better serve
> our users. I'm trying to reform now :)
> Again, I invite you all to try to find even a *single* example, in
> commercial grade software, of a boolean label other than on the right. Not
> even Lotus Notes violates this design convention (it is probably the only
> design convention Notes doesn't violate).
> I'll be direct: I will not use any tool that makes it difficult to
> implement long-established, widely-held design conventions. This is a
> showstopper for me, personally. Yes, I am serious.
> I am sure the XForms working group has bigger fish to fry than this. I
> understand the notion of priorites. I do hope this is put on the to-do
> list to be addressed someday, though.
> Happy Friday, to all who reside in a culture where that is a happy thing
> :)
> Back to lurking,
> Kirk
Received on Sunday, 4 February 2007 21:19:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:55 UTC