Checkbox field labels

[Jonathon Menz]

It's always bothered me that checkbox field labels have less weight than other fields even though they might be just as important. How about a change like this?

Before:

After:

[Sam Minnée]

What's it going to look like without descriptions? The bulk of fields don't have descriptions.

I could see value in using a heavier weight, but is pushing the label further away from the field a wise move?

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Patrick Nelson]

This will already do what you need:

$composite = new FieldGroup("Some Title Here", [CheckboxField::create('TestCheckbox', 'Test Checkbox')]);
$fields->addFieldsToTab("Root.Main", [$composite]);

However: Contextually speaking you could call this a "LeftTitle" maybe (new field). I happened to notice a setter for ->setLeftTitle() on FormField but I'm not really seeing it referenced anywhere; maybe you could use that when defining in ->getCMSFields() and then reference it in the FormField_holder.ss template? That way it's backward compatible (i.e. Title is still used as the checkbox's label) but would still be able to add functionality, in the special case of one-off checkboxes to incorporate a bold title on the left.

[Patrick Nelson]

p.s., It also looks like this (I forgot to provide that before):

Plus it has the benefit of already being consistent in providing the same interface for having one checkbox or a group of check boxes. That is, if you reorder things, they're still semantically and visually grouped together and your special title field isn't sensitive to which checkbox is first in the set (since it's in an array underneath the FieldGroup).

[Jonathon Menz]

@Sam without a description it would just be the bold text label, then the checkbox on the right:

This is consistent with other fields and although the label is further away from the checkbox, I think the connection between the label and checkbox is actually a lot clearer this way. In the original example the enabled and featured checkboxes look like sub-items of the Sub title field. There's a definite disconnect and a visual hierarchy problem currently:

@Patrick thanks, yes I've done that before a few times but it's a hack - think we could have a better default here. setLeftTitle() was superseded by setDescription() I think, which is what I used to render the help text in the example.

[Jonathon Menz]

Yeah - for a field group or checkboxsetfield we'd keep doing it the same way it currently works. I'm just talking about a better default for when you have a lonely checkboxfield all by itself.

[Jonathon Menz]

p.s. @Sam - just on the idea that "The bulk of fields don't have descriptions" I would argue that's currently true, but only because the current layout encourages developers to abuse the Title property and use it like a Description, because they know it will be displayed inline next to the input.

[Patrick Nelson]

Re:

@Patrick thanks, yes I've done that before a few times but it's a hack - think we could have a better default here. setLeftTitle() was superseded by setDescription() I think, which is what I used to render the help text in the example.

If you're referring to the use of FieldGroup: Why is that a hack? To me this is not only a visual grouping, but again, a semantic grouping of multiple fields and (just in this case) you happen to only need one bold title there on the left side. You could just as easily use my suggested technique to do this (which I think looks a tad bit cleaner than what you've recommended if you were willing to group those options together):

$composite = FieldGroup::create('Options', [
   CheckboxField::create('Enabled', 'Enabled')->setDescription('Useful description goes here.'),
   CheckboxField::create('Featured', 'Featured')->setDescription('Useful description goes here.'),
]);

The only hacky part I'm seeing here is that I think SilverStripe is killing the field descriptions (which would prevent you from doing what you wanted here). So that's not actually currently possible, so never mind :) But that's an unrelated issue and should be considered a bug IMHO. That or I'm missing a different object you can use as a wrapper (I'd assume it would be a child of CompositeField like FieldGroup is).

Re:

Yeah - for a field group or checkboxsetfield we'd keep doing it the same way it currently works. I'm just talking about a better default for when you have a lonely checkboxfield all by itself.

Well, even then if it's "just for one field" it's only a few extra lines of code (or one line since you can just wrap it in the new FieldGrup constructor/create() method). It's just a tradeoff of which you'll need more frequently and, since it's at a CMS/framework level, I think it makes more sense to go with the most consistent/logical route. I agree though -- I think it should be simpler and more intuitive and less "hacky" looking, albeit I don't see this hacky (in a practical sense) at all, except for the aforementioned description bug which is I think outside of the scope of the theory I'm trying to put across here.

[Jonathon Menz]

It's only semantic to use a group if you're actually grouping things :) we're talking about a single item, so it's not a group. I have no beef with the way groups of checkboxes are displayed, only single ones.

Might be easier to pretend I only included one checkbox in the mockups, sorry if that was misleading! They are completely separate fields, they just happen to be next to each other.

[Patrick Nelson]

No, it's simple; I get it. My point being that this new thing is indeed separate and probably shouldn't be tightly coupled to the checkbox field itself. Especially when this is already possible via another means. I'm only selling the ability to extend it further (with more checkboxes) as an added bonus.

[Paul Clarke]

I think the top example can work but I think the use of labels aren't the right way round, as long as the action (verb) remains with the checkbox this pattern will work (see bottom example). I think if a pattern can be described to devs but give them the flexibility to use it how it makes sense for their user case is best. I'm in favor of the inline styling.

[Paul Clarke]

Example for post above.

[Jonathon Menz]

Thanks for your feedback Paul. What you described can already be accomplished by wrapping a checkbox field in a field group and setting a label on the group (just like Patrick suggested) so let's leave things how they are and I'll keep doing it that way :)

[Sam Minnée]

I like everything except for "Hide"—that should say "Show". Checked should mean visible. Double-negatives in UI controls aren't not a bad idea. It's the same problem as this guy:

Do you wish to cancel?

[Confirm]   [Cancel]

--