May 28. 2019
"Blogging".
I have written before about the urge to redesign a blog. It is a powerful thing to do, because it easy to convince yourself that easy technical tasks (rebuild some templates! write some CSS!) can act as levers for difficult non-technical ones (build inbound marketing funnels! proactively address support questions!)
...And thus, I redesigned Buttondown's blog. It is more of an undesign than anything: it is sparer, lighter, and less thematically similar to the splash page than the previous incarnation.
I have exactly two goals with Buttondown's blog:
- I want it to be a place where people go to answer questions about the tool, reducing my customer support burden.
- I want it to be a thing that generates registrations.
The second piece is easy to track, even if I haven't been doing a good job of tracking it (or investing in it): you look at overall traffic and overall conversions from blog.buttondown.email to buttondown.email/register. The first one is trickier, though — I don't have any metrics around how many support queries I'm answering in a given day, even though that sounds awfully like something I should be tracking, even if it's just in a Google Sheet somewhere.
This is a broader thing that I am growing increasingly thinking-face-emoji about — how much of my work should be metrics-driven, where I have a goal [signups; subscribers; revenue] that I am relentless driving towards, even at the cost of other important aspects, versus my current modus operandi — which is much more about me working mostly on what seems pertinent or top-of-mind?
But I digress. Just as I digressed by rebuilding a blog instead of creating content for it. I'm going to start marketing more, which means starting writing more, which sometimes means the front-end development equivalent of cleaning out your desk just to get it messy again.
Backlog.
I talk a lot about the surface area of Buttondown: how many things it can do and how many things it needs to be aware of. I try to be relatively conscious of this whenever I'm adding a new feature or addressing customer feedback: what impact does this have on my surface area? How much broader will this ultimately make the codebase?
I am not particularly great at answering these questions, and relatively small code changes can often have large repercussions.
Sure, when you're integrating with a new service you suddenly need to have an upstream dependency and ways to, say, handle outages or malformed API responses.
But things can sneak up on you.
A reasonable request ("hey, can I collate my RSS feed into an email like Mailchimp") means I suddenly need to have an entire suite dedicated to handling edge cases (what happens if the RSS feed is empty for a date range — should I send an empty email or no-op? What happens if the RSS feed is larger than the maximum size for an email in Gmail? etc. etc.) that I don't have the energy or resources to answer to fully.
Even bug fixes can increase the surface area of your application. My URL validation logic has intimate knowledge of Apple Maps thanks to some users correctly complaining that a link generated by Apple Maps is of the format maps://maps.apple.com/<location>, which is only parsable by Macs.
A revealing proxy for this is the size of my GitHub Issues backlog, and how its grown over time (source here):
That exponential growth is wild: it took me twelve months to hit a hundred open issues, then six months to hit two hundred, then three months to hit three hundred. Compare that with the number of closed issues, and you can see an unsustainable rate of growth:
I can only justify closing a small handful of these issues as things I'll never do. Almost all of them are valid and warranted — even if they never come to pass.
The to-do list.
I only got one of my three things done from this past week, but it was for (relatively) good reasons. I ended up not shipping CAPTCHA enrollment because I wanted to think about the UX a little bit more, and I ended up not shipping as much content as I wanted to because, well, I'm a coward and rebuilt the blog instead. But I had a pretty decent shipping cadence beyond that — the anti-malice detection went well, and I got a lot of work done on what I'm calling Panoply (because "multiple newsletters for a single user" is not nearly as catchy.)
And, as such, I have only two things I want to do this week, though it's going to be a tight week (I'll be in Portland this coming weekend, and largely unproductive):
- Write a lengthy post documenting Buttondown's Markdown usage.. This is something I'll probably want to back port to a marketing page eventually, but starting it out with code samples will be easier.
- Get Panoply to the point where I can dogfood it. It is so close, y'all. If I play my cards right, there will be screenshots on Monday.