I have a form where I have a group of check boxes that are only applicable if a 'master' check box is ticked. At the moment, when the check box isn't ticked it looks like this: enter image description here

When the text box is checked by the user, a group of sub text boxes then slide down below it. This looks like this: enter image description here

This all feels quite clunky though. Not to mention, it doesn't look very intuitive. Would anyone have any recommendations of a pattern that could be used to solve this problem?

2 Answers 2


You need to structure the options so that it's clear that they are child options of the main option and can be ticked off only if the main one is selected. Moreover, I suggest:

  • not hiding the child options from the user - he should see what's inside before selecting the main one. Should there be a lot of stuff to display, there would be a reason behind hiding it, however in this case there seems to be no such reason (well, maybe if there is really a lot of other options). Instead, show that the child options are disabled to select.

  • grouping the options in columns - there are two groups: events and errors. Vertical grouping will be more clear to the user (due to scanning from top to bottom). I don't think you need to provide headers for these columns in this case.

  • checkbox should be on the left side of the label - this way you avoid it being closer or farther from the text while still having them aligned in columns.

  • switching positions of submit buttons - the one that is meant to finish the process is [Save configuration] so it should be placed on the rightmost position (but maybe I'm old fashioned).

  • In the same time Cancel should be both visible and degraded - I have changed it to a link instead of button.

Here's a quick wireframe for you (the app I'm using does not allow much modifications, so sorry for some details, like [x]-boxes or colors):

enter image description here

  • Great! Thanks, all of those sound like great suggestions. I'm just wondering about the rationale behind changing the cancel button to a link. What's your reasoning for this?
    – rheotron
    Apr 7, 2013 at 7:30
  • The reason is the same as behind switching positions of the buttons - to degrade "Cancel" and mark "Save" as the end of the process. In other words - "Cancel" is just a back door, and back doors are usually smaller than the main ones ;) Of course it can be a button, but in this case I would opt for making it smaller, and maybe reversed (grey button with red text?). Red is a "should have" for canceling, so leaving it of the same size as Save would give it the same importance. Apr 7, 2013 at 7:43
  • Adding to @Dominik Oslizlo suggesting grouping items into events and errors: they could be color coded to make this even clearer.
    – uxzapper
    Apr 8, 2013 at 1:43

No one seems to have mentioned the fact that having a label like "Enable Text Logging" with a checkbox is sub-optimal UI design.

The quick-and-easy checkbox is an example of an unconstrained control that decreases system visibility and forces us to lock the action (Enable) into the label.

This forces the user to think "unchecked 'enabled' is disabled, checked 'enabled' enabled", and on scanning the page the state of the system is not immediately obvious.

A more constrained control, like an on/off (or enabled/disabled) toggle, lets us remove the action from the label (now just "Text Logging") and offers greater at-a-glance system visibility.


download bmml source – Wireframes created with Balsamiq Mockups

If you're concerned with optimal UI/UX, and have the resources to do so, you should lose the checkbox and go with toggles.

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.