A toggle is a switch that has two positions, either on or off. It’s a familiar control in most hardware and software — you might see it on the keyboard’s Caps Lock or Num Lock keys, for example. Toggles are particularly well-suited to change system settings and preferences because they take up less space than two radio buttons and can be pressed with one finger. On mobile devices they’re the preferred way to adjust settings because of their simplicity and speed.
Unlike most other interface elements that require users to click a Save or Confirm button for changes to take effect, a toggle will immediately reflect the current state of its default. This is important because a user should not be required to take extra steps to ensure that the toggle switch will be set to its correct state. For this reason, toggles are best used to enable system settings that will have immediate impact such as “Airplane Mode.” In the case of setting a preference that will only have an indirect effect (e.g. a different UI for email sending) it’s usually better to use a checkbox instead.
As the name implies, a toggle has an on and off position but it can also have any number of intermediate states. This makes it a great control for changing settings that can have both positive and negative impacts. It’s often useful to add a label for each state to help the user understand what each will do and when they can expect the toggle switch to return to its default state.
Like all interface elements it’s important to test toggle switches appropriately. Since Release Toggles are often transitional in nature they should generally not stick around for more than a week or so (although product-centric toggles may need to be maintained for longer). In order to keep the amount of inventory in production down a team can be proactive about adding a task to their backlog for removing toggles as soon as they’re no longer needed. Some teams even go so far as to put “expiration dates” on their toggles that will automatically fail a unit test or CI/CD job when the toggle reaches its limit.
Once a team reaches a certain size the process of manually managing toggle configuration through static files begins to become cumbersome. In response many organizations choose to move their toggle configuration into some form of centralized repository. This might be an existing application DB or it might be some type of admin UI that allows system operators, testers and product managers to view and modify Features Toggles and their configuration.
