Posted On: 2021-02-01
Maintaining this site is, generally, a fairly small time investment. Most of my work time is spent focused on my current project, and the remaining time is generally spent authoring the content for my weekly blog posts. Actual maintenance work, whether that's fixing bugs or adding new features, is fairly rare, and it takes up only a tiny percent of my overall working time. While good for staying on-task, this comes with a downside: there are things that would be nice to have (or perhaps even are expected) that simply won't happen for the foreseeable future.
This past week includes a simple example of this: I have (for quite some time) wanted to provide my blog posts as an RSS feed, in addition to the regular format. After spending much of the month focused on story and narrative work, I thought I'd change things up a bit and at least see what it would take to use RSS. After a couple hours of research and testing, it became clear that, although most of the technical tasks are simple, there are three significant obstacles that will obstruct being able to accomplish this in the future:
One of the quirks of the template engine that I use is that, even though I author posts' content individually, I can't actually use said content separately from the rest of the markup of the page. As such, if I put the posts directly into the RSS feed as-is, then it would include everything in the page (menu bar, invisible meta tags, etc.) In order to overcome the issue, I'd need to spend additional time - perhaps by switching templating engines, working around the limitations via automation, or manually authoring (and storing) separate descriptions for each post.
Although RSS is technically supposed to be machine-readable, ultimately those machine instructions become content that is displayed to users. Much the way browsers turn (machine-readable) html into rich visual experiences, RSS readers turn RSS feeds into interactive experiences that satisfy users' needs. As such, in order to effectively present RSS content, I need to understand RSS readers and their compatibility differences, as well as routinely test any new or modified posts to verify their behavior in both the browser and reader.
This is, fundamentally, the core problem - and perhaps one that I should have appreciated sooner. If I were an RSS user, I'd have prior knowledge and opinions that would serve as a jumping off point for getting the feed to work with at least one RSS reader.
Facing those obstacles, I've stashed my work on the RSS, and set aside any thoughts of further working on it. In an ideal world, this shouldn't be nearly the scale of problem that it is, but, in the actual world, I've learned that I simply cannot achieve this with the amount of time I'm willing to invest into it*.
Hopefully this write-up of my process for evaluating a particular site feature (RSS feed support) has been interesting for you. It is quite similar to the process I use for evaluating most tasks (both for the site and my project): research up-front followed by a more informed estimation of just how much work it would really take to accomplish it. Although one could be tempted to view the research as wasted effort (since the task was eventually canceled), I've come to believe that such estimation research is intrinsically valuable: in my experience, it's been better to take time to make an informed decision than rush to make the wrong one*.