Best Practices on toggle switches and defaults in forms?

Question

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:

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

Answer 1

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:

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:

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.

Answer 2

I'm not sure if this will answer your question perfectly as this might not be the best practise in the design community but as a user I noticed apple does it with multiple toggle buttons to keep it straight forward Now for the second question it’s upto the style you prefer for your app but the first option looks more comfortable to me [Only my opinion!]. But if the options are not obvious like male/female or send/receive I think the second option where you show both the options will be helpful.

Answer 3

The first part is about how to represent a default state on an optional toggle control, and I would suggest that the best way to avoid confusion is not to show it at all, but create a control that activates the option. For example, it can just be a button to trigger the toggle switch to appear. However, if you are providing a default value then this is not a valid option. I think it is about providing appropriate messaging and labeling that will avoid ambiguity. If you use too many combinations of colours and styles then it just becomes more confusing for the user. Unfortunately I don't think there is a standard convention, or if there is then it varies depending on the context of the user and the application.

The second part is about displaying or representing the state of the toggle buttons, and there have been similar discussions in the areas of toggle buttons and indicating the state of buttons. The short answer is that you need to make sure that wherever the labeling occurs it is clear and not ambiguous whether it is indicating the state (current or future) or the action that the user is going to perform. The best way is to actually play around with the labels and test it out with actual users because the context could vary the approach you should choose considerably. With the options you have shown, I think you don't necessarily need to grey out the non-selected option, as it seems to suggest a disabled state. The only element you need to differentiate is whether the option is selected or not, so I think the style on the DELIVERY and RETRIEVAL should be the same.

Answer 4

Im curious how the testing went. I found this post because we have the exact same situation where we want to show both selections and it can't be framed as a yes/no or on/off selection. We can have a default selection though (unlike make/female). So our case is a little different because it doesn't need a neutral setting. I researched other UI Dev Guidelines and I don't see a standard.... yet.

We went with version 4 of your example because it matched our product branding. Version 1 and 3 were what we discussed on a white board and were well recieved. I really like the solution you chose with the null state. I would advise that the 3 dot locations be placed about 45 pixels apart because I notice on my iPhone the tap doesn't always register when the on/off selections are close and its fat-fingered.