For the last two years, I have been thinking a lot about content. How people consume news, discover it and more importantly what the future of content most probably looks like. RSS is a major part of how the content gets distributed around. In many cases — for news apps like Pulse, Flipboard etc — it might be abstracted from the users, but at the end of the day it is an integral part. If re-imagining RSS as the syndication layer is on your task-list, then some of the ideas around rethinking RSS might be relevant to you. It is a by product of inefficiencies in the current system and unnecessary reinventing of the wheel for every startup that tries to build a news app. I am taking the liberty to assign this with a pet name — Pulsar.
A side note before we dive in. This is not about Google Reader. It has nothing to do with Google shutting Reader down — which I think was a decision that we will thank them for — because of the amazing services around content it would lead to. Be that out of frustration or necessity or both. Having made that distinction clear, let's begin.
Abstract it from end user
This is a no-brainer. All that the end user should ever need to care about is the name of the publisher/blogger/writer they want to stay updated from. The process should be as simple as typing the name in search box or just clicking on add source button under the publisher logo. No feed urls, not API endpoints. Never.
Truly real time
RSS was never truly real time. There were projects like ‘pubsubhubbub’ to make it seem real time, but that never truly happened. It was always a few minutes behind which makes it almost useless for anyone who wants to be on top of news. Also in the age when Twitter and Facebook are the Way to discover news for most people, why this is important, especially if you are trying to build a reading experience, is not hard to fathom. Giving publishers the power to push content or information about new content is a strategic advantage over other large scale syndication & content infrastructures — assuming you are not the only one building such a thing.
A content API for publishers, not just a document syndication format
Today, content is a commodity. There are multiple places people can read the same content. Which means there is a lot more information around the core content that services can use and create better experiences for publishers. Some of them, in no particular order, are below:
- Main article & summary
- Revision history/updates
- Media associated with text — video, audio and photos (intentionally separated)
- Publisher info
- Author info
- Number of shares (Facebook, Twitter and other networks)
- Number of reads (polled or real time)
- Entities referenced in the article (people, places, events, things)
- Related articles from same/other publisher
- Pre reading for an article
- Further reading for article
- Discussions
- Semantic information to convey and use branding and templates for different content types
Think of what the exchange format looks like
I am not an API designer or an engineer, but I am not sure if XML is still the best interchange format for this purpose or what we are aiming for this to be. Content today is much less about being a single document and a lot more about the data around it. Something like JSON might serve us better based on the above listed requirements.
Entities and commerce hooks
Can you make it easy for publishers to syndicate context around articles. Be that around related stories or be that around more information about the people mentioned in an article. If a story about the revolution in Syria is syndicated via your API, would not it be amazing if the reader has easy access to find out more about some key entities like leaders referenced in the article? It could even be something as simple as a link to a Wikipedia article. Another one is the commerce hooks. Often articles have links to buy things or recommend gadgets. Can there be a unified payments API that makes it simpler for publishers for all kinds and types to process payments without having to leave the app they were accessing the content from? The app developer would merely have a request handler or callback URL for certain types of links and the API handles everything else.
Security credentials
Extending the last point to premium subscriptions. Can this new format make it easier for publishers to syndicate premium content rather than force them to the limited options of paywalls or a Newsstand model on iOS?
A two way exchange
If the last few pointers are any indication of the direction I would ideally dream for this, then it is clear that this would benefit from being a two way exchange. Publishers should not only be able to use this to send information and content, but also be able to receive useful information like user's device type, maybe even information about identity, location etc after due permissions have been given by the user. It is not hard to imagine of exciting possibilities that begin to emerge when articles can be sent in real time and the publisher knows my location. Am I the only one getting excited at the thought of publishers playing with certain aspects of articles in real time depending on geolocation, time of the day etc?
Discussions
So far the discussions on the web around articles have not been a smooth experience. Leave alone the point about the quality of these discussions. Every publisher has their own discussion platform. Worse yet, news apps often are ambitious to try their own discussion platform. Sadly RSS does not syndicate these discussions with the main article and frankly it was never designed to. It is so broken that we have a startup like Branch, that is trying to make the two totally separate and promote discussions as a content form of its own. Would this change if discussions travelled with the content, no matter where it was made accessible?
A dashboard for Publishers
If Google's treatment of it's feed related products is any indicator, then Feedburner is on it's way out. A company or tool that makes it easier for publishers to have all of their content related data in one place irrespective of whether it is being viewed on publisher's site or being viewed on a third party app, is a huge and complex opportunity in itself.
An experience that matches the content
This is probably a designer's special request more than something truly broken with RSS. I feel the future of clutter free reading experience cannot simply be a visually stripped, almost un-styled blob of text that Readability, Instapaper and Pocket are pushing for. The experience of reading an article in the Economist magazine is different from the experience of reading a story on GQ. Can these intangible aspects of experience be syndicated with the help of typography, color, font styles and maybe even a few templates for different content types? Can our content API be the channel for this syndication?
There are a ton of other aspects of problems with RSS that I may have missed. Some that I might not even be aware of. I will keep updating this entry as I think of more. If you feel there is something that can push the craziness of this idea further and in the right direction, let me know. If you are thinking of working on this and want to chat more, I would love to brainstorm more.
Who knows, maybe the person who creates the next syndication platform is reading this in some news app via RSS! That would be mildly ironic now, wouldn't it?