Inverting the tech tree
I have ranted a few times about how much I like the metaphor of a technology tree as a representation of a technical product roadmap. It does a good job of representing a number of unintuitive but important ideas: the role of invisible foundational work to enable downstream functionality; the seams and overlaps between various features and surfaces; the choices one must make between wildly orthogonal areas of investment. I have long wanted to make a technology tree for Buttondown, and at some point I should just dedicate the afternoon to doing so.
One pain point in any sort of planning (using a video game-y tech tree or otherwise) is that the map is not the territory — you can make a bunch of implicit and explicit decisions based on well-reasoned and charitable assumptions that end up being incorrect.
When I started the increasingly-not-tongue-in-cheek "Buttondown 2.0" effort two months ago, my thought was roughly: "I want to build a new authoring experience, which will require a bunch of refactoring changes to the current authoring experience & email abstractions. Once that is done, I can continue with other significant scaffolding changes to the IA and the settings." Basically, I assumed that the core changes I wanted to ship to improve the writing experience were completely independent of the other changes I had in mind.
Reality — and user testing, thanks again to those who provided feedback — reveals otherwise! As I touched on last week, the big piece of feedback needing redress was an improvement in switching between open drafts. "Okay," I thought. "Time to start working on some of those IA changes and bring them in to shift from a big ol' dropdown to a more conventional collapseable sidebar." I have a WIP branch of that and I really like how that turned out (a drawer of recent drafts that you can click through to easily swap):
The problem? Well, this sidebar assumes an omnibus settings page (note how little real estate is devoted to navigation in this sidebar, compared to the current one!) So all of those changes I was mulling to the settings infrastructure — which I considered completely orthogonal to everything else I was working on — are suddenly a requirement to get the core IA improved, which means it's a requirement to get the core authoring experience improved. My mental model of how this work could be sequenced was completely wrong.
I do not think this is a big deal, or a particularly costly mistake. All of these are projects I wanted to do this quarter; I am under no time crunch or deadline that necessitate cutting corners to rush things over the line. It's more just funny — a rabbit hole inside a rabbit hole means the thing that is 99% ready to ship is going to languish on a staging server for another few weeks.
In particular, I'm quite happy with how the unified settings experience is turning out. The page depicted in that tweet still needs some TLC in terms of coloring and composition, but it feels like it's going to be a much more navigable flow than the current experience of being spread across a bunch of different pages. It's going to be another "more red than green" PR, and being able to improve my codebase quality concomitantly with an improvement of the actual user experience is my favorite genre of project.
But it feels a bit like a matryoshka doll at times. I get antsy when I go this long without shipping net new features; I'm excited to be able to push through these big changes and start working on some smaller stuff.