0

In the app the user is profiled according criteria. Let's say a criterion has 2 values : Aerial or Ground. What would be the best way to display the value of this criterion ? The value of this criterion wouldn't be editable.

I was thinking that it could be interesting to display the 2 possible values of my criterion and emphasize which value it takes.

Here are the 3 representations I had in mind enter image description here

Do you have any way of representation in mind ? Otherwise which one would be the more affordant ?

Edit: The representation should also work for 3/4 items which makes option 3 wrong. Also someone in the comments stated that option 2 didn't match the standard use of a switch. It leaves me with option 1 : someone suggested that the text goes grey to show this isn't editable plus the strike should be removed

enter image description here

  • 1
    What about two radiobuttons? I think from a usability standpoint they would be the most intuitive and you don't have to reinvent the wheel. – Nash Aug 13 '18 at 9:43
  • That could work but it isn't like a form, it is an information which has been determined through tests and I'm afraid that radio button doesn't show that the value has been "hard" to determine. You also have a reliability score for the value – BenDev88 Aug 13 '18 at 10:04
1

Based on the underlying data, mutually exclusive options, anything representing ‘radio buttons’ would be most clear.

The first option is, therefore, the best one. However, the strike through indicates deletion more than anything else, so I would use greyed out text instead.

A step up, visually, would be to use icons in addition the the labels.

And building on the high-low relation between Aerial and Ground, you could position them above each other instead of side by side, but that may not work in context.

  • Position one above the other may work for this criterion but won't for the others ones. So you would suggest the first option without the strike ? I may use icons but I don't have it yet. Is it clear in the first option that this isn't clickable ? To me it look like a tab and it seems that you can change the value. – BenDev88 Aug 13 '18 at 14:24
  • 1
    @BenDev88 Good point, and quite important! I think none of the options is clearer than the others in explaining that they cannot be changed. A ‘disabled’ state usually does the trick, which means greying them out (for example by reducing saturation or opacity of the entire control). Or instead of strike through, maybe grey text will work? – gerstemout Aug 13 '18 at 15:04
1

This decision will dictate your UI going forward, so to some extent the answer to this question depends on the other data you'll need to represent.

For the sake of consistency, make sure to think about whether you can apply the option you choose here to any other multi-choice questions in your form.

However, just within the context of your question, and considering that you've already stated your preference against vanilla radio buttons in a comment above, here are my opinions:

1st Option

This is a tab-style interface, and it benefits from familiarity and extensibility. In the future, if you have a series of options with more than two values, you can easily reuse this element, lending your UX some plus-points through consistency. This would be my choice from the options given.

2nd Option

This element is a switch, and it evokes an "on-off" impression. Traditionally, switches are not meant to function as radio buttons. I would recommend against this option simply because it goes against the interface language of many other apps out there, and doesn't offer any obvious benefits over the 1st option. You cannot extend this element to include non-boolean values, and you won't be able to use vanilla "on-off" switches in the future without causing dissonance.

3rd Option

This is the least recognisable element of the three, and it could use some tweaking, but it benefits from clear intent through the use of the arrow head. If you planned to install this element frequently throughout your system (particularly for datasets with more than two values, or a directional element like "north-east-south-west") I'd say give it a go. Not my first choice, but sure.

However it really could use some more clarity. For example, am I supposed to tap on the text, or the arrow? If I'm supposed to tap on the text, what separates it visually from your body text? Should it be underlined, or perhaps outlined as a button?

--

In short, this dataset doesn't really justify anything complicated, so if radio buttons are off the cards I personally recommend option 1.

  • About the second option you mean that a switch should be : " Label on/off " ? I guess I wasn't clear in the statement, these representations are not meant to be clickable it would just be a way to display the information. I would like that users understand this isn't clickable. Would the 3rd option fit ? – BenDev88 Aug 13 '18 at 13:08
  • 1
    @BenDev88 Without writing a wall of text, my personal preference is still Option 1. But if you've got your heart set on Option 3, sure. Before you present this to your development team however, make sure to consider: How you will present 3, 8, or 20 options using this element? What kind of maths will be required to spread these options evenly about the element? How tall will the element be once it's got more than two options, and will this destroy the vertical flow of your form? And can you justify the development and testing time required to make sure this isn't broken before publishing? – Andrew Harvey Aug 14 '18 at 8:34
  • this isn't a form it is more like a screens where the users can see informations we determined about himself and that's why this isn't editable. Good point about the "more than 2 options", I don't see the 3rd option work properly in that case. I'll edit the question – BenDev88 Aug 14 '18 at 8:58

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.