A toggle is a small switch used to turn on and off an electrical device, usually a light or an appliance. It is also sometimes used to change the settings on a device, for example to move from one brightness level to another. It is also often used as a control for other types of application, such as a switch between different views of a website or app.
A savvy team will view the number of toggles in their codebase as inventory that comes with a carrying cost and seek to keep it low. In order to do so it’s wise to regularly review existing toggles and remove those that are no longer needed. Some teams have a rule of adding a toggle removal task to their backlog every time they introduce a new toggle. Others put “expiration dates” on their toggles to encourage them to be proactively removed as they become redundant.
Toggle switches can be very effective in applications where a user needs to make an immediate decision or perform a specific action. In these instances it’s a good idea to use a contrasting color to clearly indicate the active state of a toggle. In addition, it’s helpful to make toggle labels descriptive and concise. This is particularly important for users with impaired vision, who may need to rely on visual cues rather than text alone.
For applications where a user is making a less immediate decision or performing a more long-lived action it’s often preferable to use a checkbox instead of a toggle switch. The reason for this is that toggles require the user to click a button to apply their selected state, whereas a checkbox only requires a simple tap. This can reduce the overall cognitive load of a user and improve usability and accessibility for users with disabilities.
Lastly, it’s a good idea to avoid using toggle switches for forms that require the user to click a Save or Confirm button for their changes to take effect. Doing so can increase the total amount of interaction required for a user and negatively impact the speed of feedback that is provided through CI/CD.
Many teams choose to store their toggle configuration in a centralized location, usually an existing application DB. This helps ensure consistency across a fleet of servers and makes it easy for system operators, testers and product managers to view and modify feature flag configurations. Additionally, some teams opt to build-out a form of admin UI for their feature flags which allows them to expose the right toggle configuration to the right people at the right time. This approach is often called a Champagne Brunch release. It is similar to a Canary Release in that the feature is only activated for a small percentage of users. However, the difference is that the Champagne Brunch release is based on permissions rather than on a user group or demographic. This means that a Champagne Brunch release can be more long-lived than a Canary Release.
