The company I'm working for is looking to develop a new user control to convey true / false values to users. Currently we are using checkboxes but due to some constraints we are now forced to develop a new control for this purpose.

Any suggestions?

P.S. The new control can be read-only for the moment, because so far true / false is shown to the user in a read only manner.

But of course we have to keep in mind the possibility of it being a mode of input in the future.

  • 3
    Can we know what the constraints are? – Matt Obee Oct 1 '14 at 8:42
  • @MattObee Hi Matt , the constraint is sometimes we have True/False indicating checkboxes and normal checkboxes mixed together , so we want to give the users a clear visual separation between the two types. – gaba Oct 1 '14 at 8:48
  • 3
    @gaba - perhaps you could give some made-up examples that would distinguish between normal checkboxes and True/False indicating checkboxes. Could use a tick/cross or splodge/no-splodge: ifdefined.com/images/projistics_compare.gif | operon.com/services/dna-sequencing/images/… – Paul S Oct 1 '14 at 8:52
  • @PaulS Hi Paul , we considered tick/cross thing too , but will it give an idea to the user like something went wrong ? Maybe we can use another color instead of red. The splodge was also considered but most people seem to find it unfriendly :( . Thanks for your help mate (Y) – gaba Oct 1 '14 at 9:01
  • Single radio button? While 'usual' checkbox is square, true/false checkbox is round. – Serg Oct 1 '14 at 12:25

The short answer

Simply use labels.

The long answer

If you are to design anything based on future possibilities, you will never finish a design, because possibilities are endless.

There are basically 3 design approaches (UX or software):

  • Throwaway (revolutionary)
    • When you have little understanding of the problem (high level of uncertainty)
    • You design quick, test quick, and mainly to learn what works and what not.
    • Normally a quick process, but designs are likely to be discarded (leading to redesigns or rework).
  • Evolutionary
    • When you have some or fair understanding of the problem/requirements, but it is incomplete and you suspect new requirements will be added.
    • You build the design step-by-step, accounting for new knowledge in each iteration.
    • Designs typically serve as basis for next iteration.
    • The danger is that bad designs may persist.
  • Increamental
    • When you have clear understanding of the problem and requirements.
    • You design to meet all requirements.
    • This process can be long.

When you say 'there is a possibility', it seems you are uncertain, which means a throwaway approach is probably the way to go.

What's more, if your design is based on a requirement that isn't quite really needed just yet, you may provide an odd solution that isn't tailored to what the users really need.

I suspect that this is exactly what's happening here - to convey yes or no to users, simply use labels; why provide a (disabled) control? This makes no sense from usability point of view (users might think: Why can't I interact with this control? Why is it always disabled?).

When you do need a control (something the users can interact with), iterate the design.

  • thanks for your answer mate , yes we can use a design approach like the ones you mentioned,but at the moment im having trouble figuring out the type of user control to actually use for this scenario – gaba Oct 1 '14 at 10:43
  • By 'control' I mean something the users can interact with. Although, for programmers, a 'label' is also a control. Anyhow, my suggestion is just using a label. – Izhaki Oct 1 '14 at 12:10

To show this as a two state controller, you could try any of the following. Depending of the audience's knowledge of the matter, 1 and 0 could replace true and false to save space.

enter image description here

If they are to be read only, you have the choice of disabling them, or just print them as labels (e.g. similar to a button, but not able to press it) - all depending what you want to convey to the users. Should they be aware that this is a state that can (somehow) be changed or not...

  • 4
    This would be my usual choice as well. But there is one thing I hate about these: they are so easy to get wrong. I've seen them so often implemented in such a way that you can't recognize which is the currently active state. So, if you go for these, please get a designer who knows what he's doing and can style the toggle well, to make it really obvious. It's one of the places where skeuomorphic works best, so if your designer is on the "flat is the best, skueoumorphic is so 2012" bandwagon, please insist that here, usability is more important than slick looks. – Rumi P. Oct 1 '14 at 12:03
  • 1
    Control you should exhibit state-action ambiguity and present serious usability issues. See more: ux.stackexchange.com/questions/63884/checkbox-vs-toggle/… – Izhaki Oct 1 '14 at 12:11
  • The implementation will be the deciding factor if the controls are understandable or not... – Henrik Ekblom Oct 1 '14 at 14:41
  • So whether something is usable or not is based on its implementation and not design? Aren't programmers suppose to implement something per the design given to them? – Izhaki Oct 1 '14 at 16:26
  • I meant the design implementation (how the designer interprets the controller and choses to design it) - not the implementation of the code. A bit unclear from my side :) – Henrik Ekblom Oct 1 '14 at 16:29

I think it really depends on the area, but maybe just the typography can help you: some ideas:


It's quite clear who is participating and who's not.

2) disabled look

enter image description here

I guess you can get what options are included :)

  • Really good idea to try to contextualize the "true/falsy" answers. It might not be suited for all kinds of data, though, but if it fits the data this would be my choice. – funkylaundry Oct 1 '14 at 18:25

So it's a control that represents something extremely intuitive to human beings... Yes/No, True/False. The problem that you state is the the current check boxes look too similar to some check boxes that represent something else. My suggesting is to use the tried and true images... A green checkmark for True and a Red X for false. (Maybe an option for changing the colors if you're concerned about color blind users.) It's intuitive. Easy to implement. And clicking on the image can easily change the value and image to the opposite when you're ready to make it interactive.

To represent whether or not the control is editable/interactive, you could place a border (3D or flat, depending on preference) around the image to represent locked and no border for editable.

It's not exactly an original concept. But it's intuitive and solves the problems that you identified.

  • This was what I was planning to suggest. Basically what you need is just a way to distinguish whether a checkbox is interactive or read-only. It would be a mistake to try to re-invent a proven pattern like a checkbox, but you are right that standard checkboxes are conceived as interactive by default. But if you take the checkmark out of the context of the checkbox it should not be perceived as such. – funkylaundry Oct 1 '14 at 18:23

You could use icons. Price tables like on this site sometimes use it. If it can be more childish, you can use emoticons (smile/frown, thumb up/down, ...).

enter image description here

Edit: Paul S already mentions this in a comment.

  • Yes that`s also a possibility , we are looking in to that option , thanks @thijis :) – gaba Oct 1 '14 at 10:44
  • 1
    -1 Because you've linked to a page that is likely to change in the future. Do a screen grab (screenshot) as well so it is preserved for the future. – tim.baker Oct 2 '14 at 9:41

how about you write true or false somewhere on the interface?

  • that wont do unfortunately :( but thanks for the suggestion @colmcq ! – gaba Oct 1 '14 at 10:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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