A toggle is a switch that can be in either of two positions: on or off. A toggle can be pressed, clicked, or tapped to change its position. Toggles can be used to update preferences, settings, and other types of information. When used effectively they are a user-interface component that can be extremely useful and powerful. The key to using toggles effectively is to provide direct labels, follow standard visual design principles, and deliver immediate results when clicked.
This is why it is often preferable to use toggles over checkboxes or radio buttons. For example, on mobile devices where screen space is limited and the default state of a control (ON or OFF) has already been determined for the user, toggles allow us to display the controls with less vertical real estate, thus conserving valuable above the fold space. Additionally, toggles don’t require a “Save” or “Confirm” button to apply changes. This means that users can toggle a control with confidence and the toggle’s new state will take effect immediately.
The word toggle is derived from the 18th century definition of “a pin passed transversely through the eye or bight of a rope or chain to bind it temporarily.” Toggle is also a verb meaning “to bind or fasten with a toggle,” such as when you’re fastening a neckerchief around your neck and toggling between its open and closed position.
When a toggle is used to manage permissions for features this functionality can be extremely dynamic, as the toggling decision will typically be made on a per-request basis. This can be a benefit in terms of agility but can be challenging to test in an automated way as the toggle may not always be in its desired state. To address this challenge, some teams have a policy of adding a task to the team’s backlog for removing toggles that are no longer needed after a release cycle. Others have even gone so far as to add expiration dates to their toggles.
As a general rule, Feature Toggles shouldn’t stick around for very long (although a Canary Release or Champagne Brunch can be an exception to this). A short lifecycle is ideal because it minimizes the time and effort needed to verify how a particular toggle will behave once it’s deployed. To achieve this goal we need a system that allows us to change the configuration of a toggle without re-deploying code into our test environments. This can be accomplished in a variety of ways ranging from simple but less dynamic approaches such as commenting with the #ifdef preprocessor feature through to more sophisticated approaches that offer the ability to dynamically re-configure a toggle in runtime. This type of in-memory re-configuration is also important for experimental features that need to be rapidly swapped out with other configurations during the testing process.
