You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, our feature flag creation UI has different interfaces for boolean flags versus multivariate flags, despite boolean flags essentially being a special case of multivariate flags (with true/false variants). This inconsistency creates unnecessary cognitive load for users who work with both types of flags.
Current Behavior
Boolean flags have a distinct UI layout
Multivariate flags have a separate interface for defining variants
The two interfaces feel disconnected despite serving similar purposes
Proposed Solution
Unify the flag creation interface to treat all flags consistently:
Present boolean flags as a special case of multivariate flags (with true/false variants)
Use a consistent layout and interaction pattern for all flag types
Maintain the simplicity of boolean flag creation while fitting into the multivariate paradigm
Technical Considerations
May require updates to flag payload/serializer logic to properly detect flag type
Need to ensure backwards compatibility with existing flag configurations
Should maintain current functionality while improving UX
Previous Work
A design proposal was created ~2 years ago addressing this issue (see attached mockup)
Previous implementation was deprioritized due to resource constraints
I think this may make sense for power users once they understand variants, but I worry it would be confusing to new users and people who use simple feature flags.
My conceptual model for a feature flag is simple: A flag returns true or false if the user matches a set of conditions. Our default UI seems to capture that use case well.
The UI here would make me a little confused in the default case: Why is true a variant key when there's only one variant? Also, does that UI mean we return true or the string "true". Returning "true" the string could be confusing.
I think we may want to consider 3 cases:
Flag has a single boolean return value
Flag has a single variant
Flag has more than one variant.
For case 1, we want a way to convert it to a variant.
For case 2, we then have the option to add a variant or go back to being a boolean return value.
For case 3, it behaves pretty much the way it does today.
What the boolean return value and variants have in common is they're both the values that we serve. So I tried to lean into that a bit.
Background
Currently, our feature flag creation UI has different interfaces for boolean flags versus multivariate flags, despite boolean flags essentially being a special case of multivariate flags (with true/false variants). This inconsistency creates unnecessary cognitive load for users who work with both types of flags.
Current Behavior
Proposed Solution
Unify the flag creation interface to treat all flags consistently:
Technical Considerations
Previous Work
Reference
Original discussion
The text was updated successfully, but these errors were encountered: