A toggle is a switch that can be turned either on or off. It is found in all sorts of hardware and software, from a keyboard’s Caps Lock and Num Lock buttons to the Airplane Mode switch on a smartphone. In software, toggles are commonly used in options or preferences menus. All of these examples use toggles because they are more effective than radio buttons or checkboxes for limiting user choice.
The downside of using toggles is that they are notoriously cognitively problematic for users, especially when the current state is not immediately apparent. For example, research shows that using the same color for on and off states can confuse users. That’s why so many designers add a secondary color or a border to help make the current state of a toggle clear to users. While this helps, it isn’t enough. The WCAG’s guidance on colors suggests that we should not rely on color alone to convey meaning and toggles fall well short of this standard.
Another problem is that when a toggle is configured via static files (e.g. HTML) it can be a challenge to manage at scale. Modifying these files becomes cumbersome and ensuring consistency across servers is difficult, particularly in a complex distributed application architecture. To address these issues, most teams choose to move toggle configuration into some form of centralized store – usually an existing application DB or a separate app config repository. This is often accompanied by the build out of some type of admin UI which allows product managers, testers and system operators to view, modify and test feature flags.
This approach to managing feature flags also introduces the additional complication of modifying a toggle at runtime. For example, a developer may want to rename an existing toggle or change its default state for a new release. For the most part, changing a toggle at runtime can be done through some sort of override mechanism — typically by exposing an endpoint which enables in-memory re-configuration of a flag. This provides more flexibility and reduces the time to deploy updates and re-test features at runtime, improving both cycle times and the all important feedback loop that CI/CD depends upon.
Savvy teams realize that a feature flag comes with its own inventory cost and seek to keep this as low as possible by being proactive about removing toggles once they are no longer needed. This can include adding a task to the team’s backlog whenever a toggle is introduced or even going so far as creating “time bombs” that will fail a test (or even refuse to start an application!) if a particular toggle remains active after its expiration date.
