Previously:
As I mentioned in my previous post, I’ve built several RSS readers over the years (but never released any of them). If I’m honest with myself, I don’t think any of them were good, because I was only focused on one aspect of an RSS reader: the reading experience. To create a successful product, this time, I must consider all parts of the app to be important.
As far as I can tell, there are three parts to the anatomy of an RSS reader:
- Discovery
- Management
- Reading
Discovery
RSS readers tend to be nerdier apps. Or, apps that have a nerdier audience. Podcasts hit the mainstream, after incubating in the nerd-sphere. And, there was a period where it was necessary to explain to everyone what a podcast was. RSS has never had that moment. I struggle to think of a single person in my life who wouldn’t enjoy the benefits of an RSS reader, nerd or not. In other words, that there isn’t a single website that they don’t, or wouldn’t, enjoy reading regularly. So, what needs to change for RSS to hit the mainstream, in the way podcasts did?
Often, RSS readers rely on a user to know what an RSS feed is and how to acquire one. Typically, we manually enter feed URLs, or import feeds from an OPML file. While those features should, and will, definitely be available, I think we can offer greater help to users to find content they love, without requiring any technical understanding.
While many websites publish a link element in their HTML pointing to an RSS feed, not all do. For example, theguardian.com does not, but RSS feeds are available by appending /rss to many URLs. A facility to auto-discover feeds for any given domain is available in some RSS readers, but I think the key is the presentation of the UI, and the choice of language to make it more accessible to more users. To not present it as a route to discover an RSS feed, but to discover content. As, the RSS feed is just another layer of indirection between the user and the content.
A long-term goal would be to include some sort of directory. Now, it is obviously impossible to include all available RSS feeds, but having many of the most commonly visited websites, for different content categories, allows for greater discovery for less technically minded users. I say a long-term goal because of the time and money required to host the infrastructure for such a solution. But more on that another time.
Along similar lines, a recommendation engine would be a useful inclusion, but again would require infrastructure to analyze people’s subscriptions. And to do so in a privacy-sensitive way. Again, this would be a more long-term goal, as you’d have to gather the data in the first place.
There are also other mechanisms for discovery of content, like Safari extensions. This would allow a user to (try) to subscribe to content as they are browsing the web, rather than after the fact. Integrating with the system, though shortcuts, URL schemes, app intents, etc. will also allow the more advanced users to build their own custom integrations, as is their wont.
I think my point, overall, is that (discovery) tools can often be difficult to use or incomprehensible to all but the most savvy users, but that needn’t be the case. To restate my question from Why I’m Building My Next App In Public (Part 2): Can I, or one, build an RSS reader whose UI and UX can effortlessly scale with the user’s preferences and needs? Can neophytes and experts both have their needs met by the same app?
In part 2, we’ll look at Management.