3

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.

William
  • 448
  • 2
  • 11
gaba
  • 31
  • 1
  • 3
  • 3
    Can we know what the constraints are? – Matt Obee Oct 01 '14 at 08: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 01 '14 at 08: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: http://ifdefined.com/images/projistics_compare.gif | http://www.operon.com/services/dna-sequencing/images/comparison%20chart%20v4.jpg

     – Paul S Oct 01 '14 at 08: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 01 '14 at 09:01
  • Single radio button? While 'usual' checkbox is square, true/false checkbox is round. – Serg Oct 01 '14 at 12:25
  • @gaba, it's not a good idea to rely on color alone to convey meaning. That's been heavily discussed here before. If you are looking to also convey "error", then it's no longer Boolean, it's at least a tri-state: true/false/error. You might also consider including "null" and "warning", in case those are possible states, too. Common representations include a green checkmark for true, a red X for false, an exclamation point in a yellow triangle for a warning/non-fatal error, a red circle with either a white X or a white horizontal bar for a serious/critical error, and a blank for null. – John Deters Oct 01 '14 at 16:57
  • From a user perspective, I don't think there's such a thing as "true/false values" unless the user is a logician working with truth tables or similar. Can you clarify what you mean? This is not just pedantry but a core issue to the UX question. On/off, enable/disable, block/unblock, opt-in/no, opt-out/no, etc. are all different kinds of boolean states that can be confusing to users if the UI representation does not help them establish an intuitive link with the semantics. – R.. GitHub STOP HELPING ICE Oct 01 '14 at 21:24

6 Answers6

7

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.

Izhaki
  • 32,595
  • 5
  • 66
  • 99
  • 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 01 '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 01 '14 at 12:10
5

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...

Henrik Ekblom
  • 4,188
  • 22
  • 24
  • 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 01 '14 at 12:03
  • 1
    Control you should exhibit state-action ambiguity and present serious usability issues. See more: http://ux.stackexchange.com/questions/63884/checkbox-vs-toggle/63886#63886 – Izhaki Oct 01 '14 at 12:11
  • The implementation will be the deciding factor if the controls are understandable or not... – Henrik Ekblom Oct 01 '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 01 '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 01 '14 at 16:29
4

I think it really depends on the area, but maybe just the typography can help you: some ideas:
1)Strike-through

PARTICIPANTS
Jim
Tim
Bob

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 :)

Sohcahtoa82
  • 103
  • 3
Francesco Mapelli
  • 186
  • 4
  • 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. – zkwsk Oct 01 '14 at 18:25
3

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.

Thijs
  • 173
  • 10
  • Yes that`s also a possibility , we are looking in to that option , thanks @thijis :) – gaba Oct 01 '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 02 '14 at 09:41
3

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.

Scott
  • 31
  • 1
  • 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. – zkwsk Oct 01 '14 at 18:23
1

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

colmcq
  • 8,240
  • 1
  • 32
  • 58