Wednesday, October 23, 2019

radio buttons - Best Practices on toggle switches and defaults in forms?


In many cases, when creating an A/B choice for a user, there is a clear option that should be the default; if not, the debates can rage... and if the choices are not clearly boolean (Yes or No), it gets sticky.



I am working on an app in which the user can create a new "case" (database record) on the fly. When they create a new case, they are presented with a form, with many of the fields optional. Some of those optional fields are obvious boolean choices, such as "Yes/No"; others are less clear, such as "Delivery/Retrieval," "Imperial/Metric" and "Male/Female."




The first question is this: for fields that have an A/B exclusive option, a toggle seems to be an appropriate control to use (especially when one hates radio buttons). But if the fields are OPTIONAL and should not contain a value, how do you represent them by default when the form first appears?


There is no obvious default choice for Male/Female, and if the user does not select one at all, we don't want to throw a default into the data record. We could not enter the value into the record until they edit it, but if they look at a control and see a value that looks correct by default, they may not touch it, and in that situation it would therefore not be entered into the record at all, though it LOOKS selected.


Is there any best practice around defaulting this sort of non-boolean a/b choice? Anyone?




The second question is this: what is the best way to represent non-boolean values on a toggle switch? I have three possible options I'm playing with now:


Text on the switch and the background


Text on the switch that changes Text not on switch at all And sucking it up and doing it radio-style


There appear to be benefits and drawbacks to each - any thoughts around this from the community at large?




Answer



Well, after much deliberation, we've come up with a solution that I have not seen before, but seems as if it will solve our problem (and we'll see tomorrow if some user tests bear this out).


Stylistically, we decided to go with our third option above, the normal, iOS-style toggle with the labels on each side. However, to deal with the "optional" factor - and the fact that we don't want those optional fields entered into the database unless the user deliberately makes a selection, we've created a third state:


enter image description here


The toggle shows up, but rather than being active, it exists in a null state, with neither option selected, and the thumb sitting squarely in the middle, in the color we are using throughout to indicate a significant action.


If the user does nothing, those toggles remain in the null state. If, however, a user wants to set that value, the orange action color and grayed out options indicates to the user that they need to touch to activate the control.


Once they do, the "null toggle" (which is just a button overlaid on a real toggle, for which we have determined a default value) disappears, the default value of the real toggle is reveled, and that value is entered into the data record:


enter image description here


If they like the default value, they need do nothing more and their selection is recorded. If they touch it again to toggle, the value switches and the new value is recorded.


Clearly there is a certain amount of learning required. But this is a closed audience for a very specific and functional app, and once they have interacted with this control once, I expect that they will easily understand it everywhere else they encounter it.



I'd love to hear people's thoughts, and I'll reply with some results from our tests.


No comments:

Post a Comment

technique - How credible is wikipedia?

I understand that this question relates more to wikipedia than it does writing but... If I was going to use wikipedia for a source for a res...