On 17.01.2014, at 05:10, Bertrand Delacretaz <[email protected]> wrote:

>> Do you have a concrete use case for that ?
> 
> Not me but I'm not running any Sling-based sites myself ;-)
> 
> OTOH this is basic A/B testing, and also applies to soft launching a
> new feature (B) that replaces an existing one (A).

Apparently typical use cases are (from a discussion with our CMS product 
manager):

- test a certain new part of your website (some pages, just content) with only 
a few users
- test a new UI of your website (say a new navigation header, different 
components and/or content) with a few users (example: new features on facebook)
- A/B test a new UI of your website (say a new navigation header with 2,3,... 
variants; in addition to the old one) for a few users (and split them evenly 
for the A/B testing)

In all cases the feature flag would be something that is only enabled for a 
subset of users. How this works can be very dynamic, so it should be pluggable:
- known early adopters / power users
- geo location / geo ip (only users in Switzerland get the new feature)
- user profile data (for logged in users)
- cookie based
- random subset
- ...

Not sure if that is complete, but should be a good start. Especially the A/B 
part overlaps a lot with dedicated "targeting" solutions that are much more 
complex, especially in their end user UI to set up all the rules and different 
content. And they tend to focus on individual parts on websites, say just a 
banner or link snippet. I guess for feature flags the goal would be more 
broader - more on the level of entire sites.

Cheers,
Alex

Reply via email to