We're working on a ton of exciting stuff at Flipper, and we've been releasing updates at a feverish pace. Now we're getting close to releasing a wholly underwhelming and truly boring feature that will play a key role in Flipper's overall user experience even if nobody ever realizes it. Too often, "user experience improvements" are shallow and superficial. The focus ends up being on what it looks like or how it feels, but that's the tip of the iceberg.
The thing is, it's right there in the name—user experience. It's about how people experience something, and that involves every imaginable touch point from the initial sales process all the way to the moment someone chooses to no longer use a product. It's why Apple's products—and even their shipping packages—are easy to open. It's why some companies are known almost entirely for amazing customer service. The phrase "user experience" encompasses all of that and more.
As we're shipping more updates to Flipper more frequently, we're paying close attention to both how we communicate around new versions as well as how versions of the underlying dependencies like Ruby and Rails play into the updates. Nobody likes surprises, and nobody wants to update a critical tool only to have it break. Soon Flipper Cloud and Flipper UI will proactively help stay on top of those updates.
Cloud and Cloudless UI dependency deprecations, releases and versions.
So even though it's not a core selling point for Flipper, we've started working on something to help with the process. We're still testing it out (behind a flag of course), but we've built some infrastructure to help proactively manage Flipper gem versions as well as Ruby and Rails.
Caveat
In all honesty, our motivations for this feature are selfish. We want to:
- move faster.
- spend less time supporting outdated versions of Ruby and Rails.
- get everyone using the latest version of Flipper, so they can use the new features we've built.
The faster everyone updates to the latest releases, the faster we can move. Though our motivations are selfish, the result is a much better user experience.
Less Burden
Every project environment will soon provide insights about the current versions as well as providing guidance if a key version is significantly behind or about to be deprecated. Or, if everything is as current as it needs to be, it will provide reassurance that no action needs to be taken.
And it's not a system to simply gripe about out-of-date versions. It's not there to be heavy-handed and demand constant dependency updates. It's there to reduce the cognitive burden of staying current. Can I upgrade? Do I need to? How critical is it for me to upgrade? How long do I have until version X will no longer be supported?
More Balance
Naturally, this is just the first iteration, and we'll surely have some polishing to do in order to keep it helpful rather than obtrusive, but getting started is the key. For us, a significant part of the overall experience with Flipper boils down to managing versions and dependencies, and that's never fun. It is, however, still part of the experience, and it needs to be as painless as possible. Anybody who's ever tried to decipher the impact of a dependency upgrade by looking at a half-assed changelog knows how tedious this process can feel.
Juggling and prioritizing customer-facing work against dependency upgrades and infrastructure management is already soul-crushing enough, but when it's difficult to find answers to these questions, it's even more tedious. Just because it's invisible or how most tools work doesn't mean it's good enough.
Less Stress
This is all part of the experience, and an experience that enables more peace of mind or more relevant guidance is a better experience. It's not just what it looks like or how it works or even how it feels. It's about reducing the cognitive burden in world full of noise.
The entire point of feature flags is to reduce risk and stress. If we manage to reduce the risk of releases but cancel it out through the burden of yet-another-dependency-to-manage, then that defeats the purpose.
On plenty of other teams I've been involved with, this kind of feature would fall all the way to the bottom of the backlog because all of the benefits are second-order benefits. It's not the type of thing that customers would explicitly ask for, and nobody is going to be throwing a launch party about it.
It's also somewhat involved to build because we have to know what versions people are running, what versions are supported, and what versions might lose support in the future.
More Peace
It's not something we added because it was easy or trivial. It's something we're adding because it's an unavoidable part of the experience.
And we care about experience.
The benefits aren't easily quantifiable or obvious, but it will make things that much less tedious for everyone who manages a Flipper install. It will help reduce support requests and provide peace of mind. It will save people time swimming through change logs or ascertaining how pressing a given update will be.
Or, more simply, it will play some small part to chip away at the tedium, so we can all spend more time and brainpower on everything else.