10000 Consolidate boolean and multivariate flag interfaces · Issue #26995 · PostHog/posthog · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Consolidate boolean and multivariate flag interfaces #26995

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dmarticus opened this issue Dec 17, 2024 · 1 comment
Open

Consolidate boolean and multivariate flag interfaces #26995

dmarticus opened this issue Dec 17, 2024 · 1 comment
Assignees
Labels

Comments

@dmarticus
Copy link
Contributor

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

  • 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

Reference

Original discussion

Image

@dmarticus dmarticus moved this to Backlog in Feature Flags Dec 17, 2024
@havenbarnes havenbarnes moved this from Backlog to Todo in Feature Flags Feb 7, 2025
@havenbarnes havenbarnes moved this from Todo to In Progress in Feature Flags Feb 18, 2025
@havenbarnes havenbarnes self-assigned this Feb 18, 2025
@haacked haacked added the feature/feature-flags Feature Tag: Feature flags label Feb 28, 2025
@haacked haacked assigned haacked and unassigned havenbarnes Mar 13, 2025
@haacked
Copy link
Contributor
haacked commented Mar 13, 2025

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:

  1. Flag has a single boolean return value
  2. Flag has a single variant
  3. 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.

Here's my crude mockup. Thoughts?

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

No branches or pull requests

3 participants
0