30 March 2021
My first draft of this started out with a bunch of background on what I’ve been thinking lately, but I ended up getting lost while writing it, so instead I’ll just tell you what I’m planning to do. It’s a fairly mechanical description.
The Sample recommends newsletters. Findka Essays recommends individual articles, like random blog posts. There’s a lot of value in both areas, so I’d like to make The Sample good at recommending random blog posts too. However, I want to keep the product as simple as possible—in terms of both UI and implementation. So, I’m going to make a complementary, open-source web app that takes the random blog posts you find and turns them into a newsletter, which can then be imported into The Sample.
I don’t have a name for this app yet, so let’s call it Flub. Flub will have a form where you can submit URLs that you think are worth sharing. To make the form convenient, you can install a bookmarklet that will prefill the form with the current page’s URL (like this one for Airtable). The form will also let you choose tags for each URL. Flub will publish an Atom feed for each tag you create, and another feed that includes URLs from all tags. So I could e.g. have a feed for the Clojure articles I read, another one for the cheese articles, etc. I’ll use readability to get the content of each article so it can be included in the feed.
Then I’ll make another app: a feed-to-email gateway. It’ll be like Blogtrottr but with a few small improvements like different formatting. (Though perhaps for v1 Blogtrottr would be sufficient; I’ll decide later). Each Flub user will get a profile page that lists their feeds along with links to subscribe via email. Voila: a super easy way to share random blog posts via newsletter. I’ll add a button or something that lets you submit your newsletters to The Sample. I could auto-submit all the newsletters people make, but there might be a lot of one-off newsletters from people who are just experimenting and don’t intend to continue curating articles.
One more thing about Flub: the feeds will have an option to automatically re-share articles from their history. By that I mean, if on a given day you don’t submit a new article, then a random article you submitted in the past will be re-added to the head of the feed. Perhaps it will be a per-article setting (i.e. “this article is worth sharing again in the future”) instead of a per-feed setting.
Motivation: the best articles retain value for a long time. Findka Essays accounts for that by simply ignoring publish date. However, articles that lose value quickly (mainly news articles) aren’t always a waste of time. How do we know which kind a given article is? With Flub, we push that decision onto the user. Then The Sample can continue forwarding only the latest issue from each newsletter.
There’s one more problem I want to solve. To illustrate, you can partition newsletters into four groups:
Newsletters you don’t know about yet
Newsletters for which you want to receive every issue
Newsletters for which you want to receive some issues
Newsletters for which you don’t want to receive any issues
2 and 4 are easy. Either subscribe or don’t subscribe. 1 is what The Sample handles. But what about 3? Here’s where a third open-source app comes in. It’ll go like this:
Convert the newsletter to an Atom feed with Kill the Newsletter.
In the new app, paste in all your newsletter feeds.
The app lets you perform stream operations on the feeds. In particular, you could generate a single sink feed by once-per-day picking a random source feed and adding the latest item from it to the sink feed.
Use the aforementioned feed-to-email gateway to turn that sink feed back into a newsletter.
Add a link to each sink feed item that lets you request another article. You read an article, you click the link, another article goes on the feed, you get emailed again.
Anyway. That’s kind of a bunch of random stuff, but I think it might be just what The Sample needs to make the experience extremely awesome. I’m wary of feature creep, so I’ve tried to keep the design as simple as possible—and in fact, none of these actually involve changing The Sample at all. I’ll start out experimenting with these features as standalone apps, so they can be abandoned easily if they end up not being that useful. And since they’re open-source, they won’t add to my maintenance burden. If someone wants a new feature, they can add it themselves (if they’re a programmer).
Having all these features in separate apps might make things inconvenient, but not necessarily. Maybe it can be done in a way so that it feels seamless even though you’re switching domains when you navigate. If not, I can always integrate features directly into The Sample, after they’ve been fleshed out in Flub et. al.
I’m thinking about writing these apps on Replit, but I’m not fully decided yet. Replit makes it extremely easy to fork and deploy projects, which could be good for adoption. I would love to have Sample subscribers tinker around with these complementary apps. The downside is that Replit still has some significant limitations, so it’s a trade-off between power and convenience.
I was originally planning on actually merging The Sample with Findka Essays, i.e. migrating everyone and their data from Findka Essays to The Sample after I’d added enough features to make it subsume the former. But I think I won’t worry about doing that for a while. We’ll see how these open-source apps go first.