A toggle is a button that allows users to select one of two options: ON or OFF. They are the preferred control for system settings and preferences such as enabling Airplane mode on mobile devices. They provide a much quicker way for users to adjust these settings than a radio button would. Moreover, they have the added benefit of clearly signaling which option is being selected.
Toggle is also an 18th century word for a pin passed transversely through the eye of a rope to fasten it, and later used as a synonym for the up-and-down switch that you might find on a keyboard that lets you toggle between caps lock and num lock functions. It’s still used for this type of fastener as well as the on-and-off command, like when you toggle between screens during a video chat.
As with other user interface components, when to use toggles is a design decision that requires careful consideration. It’s important to consider color, societal and cultural implications as well as the ease with which the toggle can be changed from one state to another. The goal should be to ensure that the toggle’s logical meaning is conveyed, and that the visual design matches this meaning.
The other key factor is how to handle the configuration of a toggle. While static configuration is preferable, there are some cases where a more dynamic approach might be required. This is most often the case with Experiment Toggles or other types of A/B testing. In this scenario it is important to be able to override the toggle’s default behavior by setting an alternative value at runtime.
This can be accomplished with either hardcoding the re-configuration of the toggle into source code (and potentially building that into a release) or through a more sophisticated approach such as using the preprocessor’s #ifdef feature. While the latter is more sophisticated it still imposes an additional burden of having to manually deploy a new version in order to change the toggle’s state. This can impact the overall speed of validation and can have a significant effect on the cycle time of your CI/CD process.
Finally, the ability to toggle a specific service instance should be limited to situations where it can be safely used. For example, it might be appropriate to allow users to toggle the Article Comparsion comparison between a Draft and an Published version. However, it’s probably best to not offer this capability in a live production environment because there could be unexpected side effects that can cause pain and confusion for users. For this reason, it’s often safer to simply enable a toggle for the Comparison in a live article and allow users to override this by explicitly clicking a Save or Confirm button in the final article. This type of explicit override is less risky and will not impact the ability for users to quickly evaluate and test the results of a toggle in action.
