I'm thinking of adding:
1. Prioritization based on content preferences, evolving reading interests and value delivered. The current reverse chronological ordering does not work when one feed generates too much content and it's not possible to go through all feeds individually. Basically, trying to surface the most valuable content at the top to save time.
2. I feel that having autogenerated TLDRs would also help the user in having a quick glance-able view and distinguishing valuable/interesting content from already known facts/noise.
Would be really interested in learning how do you solve this problem of filtering out noisy/not-so-valuable content currently?
Relying only on a few trusted sources helps, but I feel that leads to missing out on a lot of other sources that could've been useful. Even otherwise, for me, the list of trusted sources grows continuously.
Questions:
1. How do you solve these problems currently?
2. Would you keep the feed readers same or would want to see them evolve to counter these problems?
3. Why are feed readers not so common? Are there not enough people out there who're interested in keeping up with multiple sources?
I've discovered RSS readers very recently, so these might be newbie questions. Please let me know your thoughts. Thanks!
I agree on the noisy feeds. I had to unsubscribe from Rolling Stone because although they have a few good articles most are crap. You could consider a mute button for specific authors or topics if the stream includes that or keywords if it does not. I think preferences have to be learned and there’s no way to do this up front.
One of the problems with RSS readers for me is that they present you with an unread count, which like email can be stressful. I always want to get the unread to 0 even if that means just scanning the headlines and clicking read all. A format that presents a reasonably sized feed without an unread count would be a psychological improvement for me at least. A read more button could always be included.
You could look at Google Reader which had some unique ideas for RSS and a lot of people loved. I never got to use it but I believe that it had dynamic keyword based searches for articles about certain topics. This is another technique to deal with the noise.
I believe feed readers are not used today because there are several firehoses of information on the internet that are filling the void with as much content as people can consume. When feedreaders first appeared you had to actively seek out content which meant checking the home page of your favorite sites. Now that content comes to you through Twitter Facebook Reddit and email newsletters. Along the same lines there’s also the social component not offered by feed readers, which some people tend to crave. They want to engage with a story after reading it which is not a feature of most feed readers (this was possible on google reader from what I’ve heard)
My personal wish is to be able to create feeds (or have a reader be able to essentially present in feed form) for websites that have no/inadequate feed.
My solution is a very simple set of PHP scripts that fetch a page with cURL and then scan the DOM for a CSS selector and put each item as an entry in a feed. There are services that do this, but they're paid and I'm a cheapskate :-D Unfortunately I have to tweak the scripts every so often to handle something I hadn't considered before.
How about adding support for “playlists”? Drawing on music apps and even stock picking apps this pattern is about supporting a layer of curators who could curate articles from various sources into their lists and these lists could be subscribable In addition to standard RSS following for single domains.
Would make for more use friendly onboarding experiences. And could be as simple as curators sharing their own lists of “tagged” articles/domains.
Nowadays feeds are harder to come by without being prompted to sign into the service or being directed to their page to read the article.
I wish there was something like Castro or a ranking system for RSS feeds for me to look for.
I think rss is so niche in this day and age you couldn’t monetize rss curation.
I would love to use RSS for semi-real time, one way communication.
What would help make this practical is one simple, cross-platform reader available everywhere --- Windows, Linux, Android, iOS and Web/browser.
Only support feeds the user manually subscribes too. Check for new content in the background on a user defined interval. Notify the user if something new is available.
Easy, simple but universal would be the key for me.
The idea is you let people code open source scrapers in JavaScript for each data source (or data source type). Developers just need to extend a base class and implement an interface with methods for e.g. getting the latest posts from this data source, fetching a single post for this data source, etc. The SDK would include a toolkit for things like stripping ads / getting the meat of the content. It would also include renderers for different data types, e.g. video vs. article. But you could maybe let the developer specify a custom renderer too, if you get the whole thing working in some sort of web shell.
Then you let users subscribe to arbitrary data sources, and you let them package them into playlists (incidentally, another comment here suggests the same -- probably a good sign). Users can subscribe to other users' playlists. For choosing data sources, users can select one from a list of pre-approved sources, or specify a GitHub URL to a scraper implementation.
When the user opens the app, you call the e.g. `fetchUpdates` function on all the data sources they're subscribed to. All the fetching happens on the client, which avoids IP blocks / bot detection / DMCA SPOF. (Alternatively, you could execute the scrapers on a server somewhere, and have the client open a proxy that the server can use when fetching content for that client.)
Other than that, users browse content in a fairly standard interface. I'd look at Apollo Reddit client as the best-in-class for content browsing on iOS.
Originally I thought it would be cool to build the main core of the app in Go (or Rust, or anything cross-platform), and use a JS engine to implement the scripting. Then you could make the shell in React Native and most of the platform-specific code would be bridging to the Go/Rust core. Unfortunately, I think Apple would have a problem with running arbitrary JS code. You can only run untrusted code in JavaScriptCore. So you would need to find a cross platform way of running sandboxed JS, using JavaScriptCore on iOS and some equivalent on Android (idk the ecosystem). (The first time I was thinking of this app was a few years ago, and this is actually how I discovered Ryan Dahl working on Go + JS, which later became Deno and Rust + JS).
You would get pushback on this if you focus too much on fetching content / removing ads / circumventing paywalls. But the beauty of it is that all the logic is happening client side. And if, for example, you're using JavaScriptCore on iOS, how is that any different than Chrome for iOS? So to avoid the pushback, you can market the app as a custom web browser for news.
Bonus points for making a web client or open sourcing the protocol so people can do things like create a "morning PDF" for arbitrary groups of sources, each with its own fetching logic defined by a plugin.
It's kind of like a combo of Gopher and Greasemonkey.
If anyone seriously wants to build this, email me and I'd be happy to talk through the idea, you can have it 100%, I just think it'd be awesome. Would also be tons of work to get right.