20

I have a group of toggles (styled checkboxes) in my interface to activate/deactivate the visibility of input fields in a form in he front-end. Two of those inputs are required for the form to work so they are always on. I would still like to display the toggles to show these fields as "on".

How do I clearly indicate these fields as "on" but disabled for the user. I've tried: grey (looks if they're off) and darker green (doesn't really communicate the functionality).

example of a list of field toggles with the always on fields on top

3
  • 6
    Now I wonder why the Field column uses sliding toggles and the Required column uses ticking boxes; theyre both boolean so why the difference? Anyhoo, I wouldn't present any choice to the user (don't put toggles for the name)
    – Caius Jard
    Jun 9 at 14:41
  • 1
    (Or if you're desperate to show something next to name and email, have you considered to script-ly toggle it back on as soon as the user toggles it off and show a toaster saying it's always required (maybe with a "because.." if there is one) )
    – Caius Jard
    Jun 9 at 14:48
  • 1
    @CaiusJard You've been reading too much Douglas Adams: "Please do not press this button again."!
    – TripeHound
    Jun 10 at 13:08
55

Consider removing UI elements that have no function, and add labels to emphasize the options the user does have.

For a simple form, there's a lot going on in this interface. Not only are you letting the user tell the system what fields are visible and/or required, but you're also trying to communicate to the user the situations where they aren't allowed to make that choice. Plus, it looks like there might be circumstances where the user could make an invisible field required, and you probably don't want that to happen.

I would suggest moving the visibility toggles into their own labeled column for clarity, and removing the toggles from the two rows where they don't make sense. Having them there, no matter the visual style, will only confuse users who assume there must be some (hidden) way to interact with them. Disabling a control should only be done when the user has some way to enable it nearby.

That also allows you to use the disabled style for when the user checks the optional Required box for a field. You can lock it to "on" when it is required not only to convey why the toggle is no longer available, but to also sidestep the issue of required invisible fields.

Revised interface mockup with a separate column for visibility toggles.

3
  • 1
    Put the mandatory ones in a separate group (rather than a separate column)?
    – Caius Jard
    Jun 9 at 14:44
  • 1
    Not keen on the disabled radio button, disabling visibility could uncheck the required. But having visibility in its own column and not showing the radio buttons for the ones that never get toggled is definitely a good solution. Jun 10 at 8:07
  • @ShaneHudson That is a fair point, though either way you wind up with one control that changes the value of another. If that is a common use case, it could lead to MTCoster's answer being a better fit if users prefer 1 choice with 3 options rather than 2 choices with interconnected options. Jun 10 at 13:03
14

Since the enabled-disabled and required-optional fields are interdependent, why not combine them to make the concept of enabled implicit?

   Field      | Disabled  Optional  Required
--------------+------------------------------
Name          |                        X
Email Address |                        X
Phone Number  |   [ ]       [X]       [ ]
Date of birth |   [ ]       [ ]       [X]
Place of res. |   [X]       [ ]       [ ]
Street Addr.  |   [X]       [ ]       [ ]

(Apologies for the terrible ascii art - no graphics package on this system)


Alternative if the fields are intended to be reorderable by the user:

Remove the disabled fields entirely, and just have a (possibly disabled) toggle for required. Allow the user to add "new" (currently disabled) fields by dragging them from a selection bin into the list. Again, the concept of enabled becomes implicit.

4
  • 3
    I like the intuitive leap to the fact that there are only 3 "modes" of operation for these fields which could be represented by radio buttons or a select input. You'd want to do some user testing to see if their mental model fits with two choices per field (visibility & required) or one choice per field. Jun 9 at 19:57
  • 2
    This. And it can be achieved with a toggle with middle position or checkbox or radio buttons.
    – mishan
    Jun 9 at 21:44
  • @mishan Yeah, but then it has to explain itself because tri-state checkboxes are clear as mud. Combo box anyone?
    – Caius Jard
    Jun 10 at 16:22
  • 1
    @CaiusJard I imagine by "tri-state" they meant something like a segmented control
    – MTCoster
    Jun 10 at 20:16
9

I've tried: grey (looks if they're off) and darker green (doesn't really communicate the functionality).

You're absolutely right that making the toggle switches grey would look like they were 'off', and dark green would only confuse its function; "Why is this dark green, and the others are not?"

I would suggest a very common practice, which is to 'disable' the toggle switch:

  • It is used for virtually every type of input field or button that is 'disabled'
  • Keeping it green indicates to the user that the toggle is 'on', just not clickable/able to be changed.

The Boolean disabled attribute, when present, makes the element not mutable, focusable, or even submitted with the form. The user can neither edit nor focus on the control, nor its form control descendants. If the disabled attribute is specified on a form control, the element and its form control descendants do not participate in constraint validation.

source enter image description here

10
  • 5
    One more alternative: if it's not toggleable, don't show a toggle, even disabled. Just show no icon, or if an icon is really needed, perhaps a green checkmark (✓ not ☑). The parallelism with the remaining toggles is nice, but I think having any toggle button, disabled or not, is potentially misleading (it makes me think there might be a way to enable it — maybe it depends on some other setting, maybe I need admin access?...) Jun 9 at 11:25
  • 1
    Good point Luke! I agree that it would be unwise to show a (disabled) toggle switch when there is never a situation that that toggle can be used, for any person and with any level of permissions. Making the element look 'disabled' works well universally, because you can apply the same effect on almost anything: input fields, buttons, links, and that consistency is incredibly valuable for clarity toward the users. Additionally, the use of tool tips on hover can help explain why certain elements are locked. Jun 9 at 13:10
  • 3
    I really, really hate the idea of locking a control which, by definition, is supposed to be operable. That violates all UI/UX concepts. Why provide a non-working control? I can't emphasize enough that the right answer is to NOT have an option for fields that can't be turned off. This is the essence of great UI (and product design) that a certain Apple CEO understood -- don't give users options that they don't need, and especially, don't give them options that don't work.
    – user8356
    Jun 9 at 14:38
  • 3
    I also hate the idea of providing something that doesn't work, and then having to explain why it's locked - otherwise the user just wonders "i can see it but it's disabled, what the heck do I have to do make it enabled?". Even saying "Always visible" may not be enough, as it might just lead them to think "it's 'always visible' right now, but somewhere there must be a setting that lets me turn off 'names are always visible', so I can change that toggle"
    – Caius Jard
    Jun 9 at 14:43
  • 1
    (If the user can switch themselves into admin mode, fine; show the toggle.. If they will never in all their working life be an admin unless they switch jobs, then no)
    – Caius Jard
    Jun 10 at 16:20
6

If you want to keep the green (to indicate that the field will be present), but don't want to allow the state to be toggled, then one possibility is to keep the green, but lose the toggle:

enter image description here

1
  • One problem with this approach is that the only indicator of status is color. It would be better to show something to differentiate (an icon, text) to people with less than perfect vision.
    – Beejamin
    Jun 15 at 0:27
3

Question - how would a colour blind person tell the difference between the toggle being on or off? Many colour blind people like myself cannot "see" green, both options appear grey for me.

To be fully accessible you shouldn't rely on colour alone. You can get around this by displaying the appropriate toggle value as a label, e.g.

[on] [theToggle/checkbox] [off]

or if the option cannot be changed apply relevent text next to the input, such as

[theDisabledToggle] This setting is always on because...

Once you have adequate labelling in place you can colour the toggles however you want.

1
  • The toggle is indicated not only by colour, but also the position of the switch. Of course, it's not obvious which end turns the toggle "on", but the end doesn't need to be explicitly labelled. It could be indicated by a tooltip "This toggle is off" "This toggle cannot be turned off" "This toggle is disabled" etc. That information is useful to everyone, and can also be read by screenreaders. Jun 12 at 13:04
1

The switch position is useless unless you know which side is "on" or "off", that's why having appropriate labels is necessary.

Tooltips are tricky, not a good choice, you'd have to indicate the toggle has tooltips, then how do you tap the toggle to get the tooltip on a phone or tablet without triggering the toggle?

Ever since toggles were introduced they have caused issues without proper labeling, especially for people who suffer from colour blindness (including me!). The most all round accessible solution for toggles is to use labels.

Of course using plain checkbox or radio input pairs with labels is virtually foolproof, but "designers know best" don't they!

0

I think the thing you're trying to convey is that some sets of controls are 'locked' so the user can't change them. In this case, I can understand wanting to show the toggles, even though they can't be changed, as they have the same 'visible' status as the other fields. A 'lock' icon might work here:

Locked toggles

Alternatively, you could show that the whole row (visibility and required) are locked by omitting the controls and just showing the lock:

Locked rows

2
  • IMO unnecessary skeuomorphism... Maybe grayed out field name would suffice?
    – Trang Oul
    Jun 10 at 6:34
  • 3
    I don't agree that adding an icon of a lock is skeuomorphic: it's an indicator of a status just like a checkmark is. Skeuomorphic might be if you displayed the locked rows as being behind a piece of glass. In any case, the toggle-switch style already in use is definitely skeuomorphic. As for greying out a field name, that's bad on several levels: it relies on the user having excellent vision, and doesn't give any extra indication of what the status is: is it disabled? unavailable? locked? There's also no 'widget' which could be clickable/hoverable for extra contextual information.
    – Beejamin
    Jun 10 at 7:17
0

In addition to the other suggestions, you can grey out the text of locked options. So, for instance, the text "Date of Birth" would be greyed out.

-4

I think you're going about all of this wrong.

Considering the type of data that you require, you should have a form with input fields, where mandatory fields are marked with an asterisk, and optional ones are not (alternatively, some recommend that optional ones have written "optional" in the parentheses, while mandatory don't have anything). Additionally, when pressing the submit button, a tooltip should appear for those required fields that aren't filled in with a message "This field is required".

Using switches in your case doesn't make sense to me.

Something like this:

enter image description here

enter image description here

3
  • 4
    The OP's case (as I understand it) is that their screen is configuring what the actual input screen will look like. The toggles decide whether there will be an input box or not... it's not where the data will be entered.
    – TripeHound
    Jun 10 at 10:19
  • Yes - OP is building a 'form designer', not a form.
    – Beejamin
    Jun 10 at 11:38
  • Then this should've been more clearly stated.
    – stackzebra
    Jun 12 at 11:05

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.