Editing Splits is Now Faster Than Ever

Features By: Ed Sawma 2 min read
Thumbnail for Editing Splits is Now Faster Than Ever

The Split Feature Experimentation Platform brings together the world of software deployment and release with analytics to measure the impact of features and code changes. On the DevOps side of that equation, a fundamental result is that Split separates code deployment from feature release. Essentially, Split is abstracting out the logic from your code to designate which of your users will see a new feature. Or, which users will see a certain version of a new feature, what we call a Treatment.

Given that you are constantly building and rolling out new features, the control panel interface to define a feature roll-out plan becomes a key component in your workflow. It needs to be quick to configure your ordinary phased rollouts, yet intuitive in supporting much more sophisticated user targeting when needed.

To support this dual goal better than ever, our product and engineering teams recently did a deep dive with our customers to understand how they used the current Split editor. We discovered several ways that the editor could be improved to save customers time and make it easier to use.

We are excited that the following enhancements are now live on the Split Management Console:

Color Codes

The Split editor now automatically color-codes each treatment of a feature. The color codes are used throughout the editor and will be used in other areas of the management console as well. This provides you with an easy visual to see how a treatment is being rolled out and the impact of that roll-out on metrics.

Screenshot of selecting color codes in the Split editor

Whitelists as Needed

Whitelists are an easy way to assign some users or a segment of users (e.g. employees or beta users) to a treatment. However, if you have several treatments, you don’t necessarily want to have to scroll through a bunch of blank whitelist fields if they are not needed.

The new editor gives you the option to add as many whitelists as you need and apply them to the applicable treatment.

Screenshot of setting whitelists in the Split editor

Advanced Capabilities Hidden by Default

If you run a large scale app or are using Split for robust experimentation, you may want to scope down the overall set of users that are included in an experiment with the Traffic Allocation configuration. It’s a powerful feature.

Advanced targeting rules are needed by almost every Split customer, but they might not be needed for every feature roll-out.

Traffic Allocation is hidden by default and Targeting Rules can be added as needed. However, they remain easy to access and configure.

Easy, Intuitive Default Rule Setting

The UI for configuring a default rule is easier to interpret than ever, using the same color coding of treatments from the top of the editor page. And, with the more advanced features hidden by default, a developer or product manager can quickly create a basic Split with a simple percentage-based roll-out.

Screenshot showing the simplified rule setting features

Overall, the interface has gotten faster and easier to use. One thing we did preserve is the logical flow of the page. A rollout plan executes in the order that elements appear on the page, i.e. top to bottom. This gives you confidence in what your users are going to experience as you configure a Split.

Try it out, and let us know what you think. If you don’t have a Split account yet, sign up for our free 14-day trial.