Why feed reading is an open web problem, and what browsers could do about it

Posted on by Luis Villa

I’ve long privately thought that Firefox should treat feed reading as a first-class citizen of the open web, and integrate feed subscribing and reading more deeply into the browser (rather than the lame, useless live bookmarks.) The impending demise of Reader has finally forced me to spit out my thoughts on the issue. They’re less polished than I like when I blog these days, but here you go – may they inspire someone to resuscitate this important part of the open web.

What? Why is this an open web problem?

When I mentioned this on twitter, an ex-mozillian asked me why I think this is the browser’s responsibility, and particularly Mozilla’s. In other words – why is RSS an open web problem? why is it different from, say, email? It’s a fair question, with two main parts.

First, despite what some perceive as the “failure” of RSS, there is obviously  a demand by readers to consume web content as an automatically updated stream, rather than as traditional pages.1 Google Reader users are extreme examples of this, but Facebook users are examples too: they’re no longer just following friends, but companies, celebrities, etc. In other words, once people have identified a news source they are interested in, we know many of them like doing something to “follow” that source, and get updated in some sort of stream of updates. And we know they’re doing this en masse! They’re just not doing it in RSS – they’re doing it in Twitter and Facebook. The fact that people like the reading model pioneered by RSS – of following a company/news source, rather than repeatedly visiting their web site – suggests to me that the widely perceived failure of RSS is not really a failure of RSS, but rather a failure of the user experience of discovering and subscribing to RSS.

Of course, lots of things are broadly felt desires, and aren’t integrated into browsers – take email for example. So why are feeds different? Why should browsers treat RSS as a first-class web citizen in a way they don’t treat other things? I think that the difference is that if closed platforms (not just web sites, but platforms) begins to the only (or even best) way to experience “reading streams of web content”, that is a problem for the web. If my browser doesn’t tightly integrate email, the open web doesn’t suffer. If my browser doesn’t tightly integrate feed discovery and subscription, well, we get exactly what is happening: a mass migration away from consuming (and publishing!) news through the open web, and instead it being channeled into closed, integrated publishing and subscribing stacks like FB and Twitter that give users a good subscribing and reading experience.

To put it another way: Tantek’s definition of the open web (if I may grotesquely simplify it) is a web where publishing content, implementing software that consumes that content, and accessing the content is all open/decentralized. RSS2 is the only existing way to do stream-based reading that meets these requirements. So if you believe (as I do) that reading content delivered in a stream is a central part of the modern web experience, then defending RSS is an important part of defending the open web.

So that’s, roughly, my why. Here’s a bunch of random thoughts on what the how might look like:

Discovery

When you go to CNN on Facebook, “like” – in plain english, with a nice icon – is right up there, front and center. RSS? Not so much. You have to know what the orange icon means (good luck with that!) and find it (either in the website or, back in the day, in the browser toolbar). No wonder no one uses it, when there is no good way to figure out what it means. Again, the failure is not the idea of feeds- the failure is in the way it was presented to users. A browser could do this the brute-force way (is there an RSS feed? do a notice bar to subscribe) but that would probably get irritating fast. It would be better to be smart about it. Have I visited nytimes.com five times today? Or five days in a row? Then give me a notice bar: “hey, we’ve noticed you visit this site an awful lot. Would you like to get updates from it automatically?” (As a bonus, implementing this makes your browser the browser that encourages efficiency. ;)

Subscription

Once you’ve figured out you can subscribe, then what? As it currently stands, someone tells you to click on the orange icon, and you do, and you’re presented with the NASCAR problem, made worse because once you click, you have to create an account. Again, more fail; again, not a problem inherent in RSS, but a problem caused by the browser’s failure to provide an opinionated, useful default.

This is not an easy problem to solve, obviously. My hunch is that the right thing to do is provide a minimum viable product for light web users – possibly by supplementing the current “here are your favorite sites” links with a clean, light reader focused on only the current top headlines. Even without a syncing service behind it, that would still be helpful for those users, and would also encourage publishers to continue treating their feeds as first-class publishing formats (an important goal!).

Obviously solving the NASCAR problem is still hard (as is building a more serious built-in app), but perhaps the rise of browser “app stores” and web intents/web activities might ease it this time around.

Other aspects

There are other aspects to this – reading, social, and provision of reading as a service. I’m not going to get into them here, because, well, I’ve got a day job, and this post is a month late as-is ;) And because the point is primarily (1) improving the RSS experience in the browser needs to be done and (2) some minimum-viable products would go a long way towards making that happen. Less-than-MVPs can be for another day :)

  1. By “RSS” and “feeds” in this post, I really mean the subscribing+reading experience; whether the underlying tech is RSS, Atom, Activity Streams, or whatever is really an implementation detail, as long as anyone can publish to, and read from them, in distributed fashion. [↩]
  2. again, in the very broad sense of the word, including more modern open specifications that do basically the same thing [↩]

Published by Luis Villa

43 thoughts on “Why feed reading is an open web problem, and what browsers could do about it”

  3. Hear hear. I actually use live bookmarks – my main problem with them is that they’re all *separate* – that is there’s no way (in the browser at least) to aggregate them into a single stream. As a result, I’m always checking 2-3 of my feeds and forgetting the other 30.

    What I would love to have is either
    1) a sidebar that I could open and close at the click of a button, containing a simple stream of messages (with enough spacing between messages that I can easily identify where I was, and coloring to indicate which I’ve read and which I haven’t)
    2) a tab like about:home that contains all the feeds I care about, which I could pin like a regular tab. This way it could also contain things like my twitter feed. Perhaps about:home itself could optionally be used for this.

  4. You make a pretty convincing point here. I’m resistant to the idea of moving RSS reading into the browser, but I can’t really tell if that’s because of ingrained years of online RSS reader usage or if there’s a genuine reason at the back of my mind. I think it’s just for the practical reasons — I like that I can use an online feed reader from any browser in the world and my session is maintained. And once you have a web-based feed reader it seems superfluous to have a local implementation of one as well. The user experience you describe might even be better implemented as a thin plugin that sheparded users towards a free web-based feed reader and provided browser implementation

    Even if Firefox had the best feed support in the world, Facebook would still exist because the reading is less than half the battle, too, because people have to want to publish in the open, and that is more difficult to set up than a Facebook account.

  5. I think it could be a good idea to ditch up the live bookmarks and replace it with more advanced feed reader, capable of showing items in folders as well as merging streams, and using the notification system to let the users know that there are new additions to their feeds. I think it worth having it in the default browser bundle, even more important than having the SocialAPI and the decent developer tools which are used by people who know to install an addon or two to customize their development environment.

    Having a tightly–integrated feed reader in Firefox can use the browser internals to make the user in control; Starred items could become starred bookmarked items (including tagging!), available items could just pop up in the awesomebar even if the user have not visited the site yet, the notifications are already implemented in the browser, etc.

    In fact, I think that websites will need an easy way to push content to users, and will start developing HTML5 applications for serving new content notification to the users. If we will have something like SocialAPI (FeedAPI? ContentAPI?), not only we will require them to code less, but we will have instantly an easy way to consume content from more than one site, so we won’t need to have 5 background HTML5 apps, one for every major site we visit often, but a centralized place for publishers to instantly notify users in new content.

    We already have most of it implemented, we just need to connect few pieces and replace the aging live bookmarks with a fully-featured RSS Reader of our own.

  6. There is a problem with moving feed reading into the browser proper: It’s not a desktop-centric world anymore. Today’s computing experience is looking more and more like a cloud. I have a cloud of devices (desktop, laptop, tablet, phone) that coordinate through a cloud of servers (amazon, google, my own, etc)

    I did play around a bit with building a feed reader directly into Firefox as an addon called Fireriver.

    It used the Live Bookmarks engine and Places store to build a “river of news” view from the resulting virtual bookmarks. It also made feed subscription more front-and-center, by summoning up a button bar at the top of the browser whenever a site offered a feed (ala geolocation). It worked pretty well, though it did stress the browser on my laptop with my load-out of 800+ feeds.

    But, even if it worked perfectly, I lost contact with all of that as soon as I walked out the door with my phone. And I never, ever want to try getting my phone to poll 800+ feeds, let alone a few dozen.

    So, I definitely agree feeds need to find their way back into the browser as first-class citizens. But, the whole story can’t be told just in the browser. We need always-on cloud servers that do the work of fetching feeds, managing read state and annotations, etc.

    As it happens, I’m playing around with building this sort of thing right now, so I’m hoping I have something practical to say about this in the future.

  7. But, that said, I 100% agree with you. I was sad when the decision for the RSS discovery icon was to bury it, not to review & improve it. I really do believe that this is a failure for the open web and browsers.

    I think a huge driver for the success of services like Twitter and Facebook is that we never solved the UI problems of publishing / subscription / reading for a read-write web in a way that anyone sane could actually use.

  8. I agree about “feed reading” but I think future systems will look a lot more like social network interfaces (single inbox, complex posts) than like Google Reader (inbox per feed, simple posts). I also think they’ll be more likely to support activitystrea.ms with RSS and Atom as a fallback.

    I think that syndication of content has come a long way from 1999; we need to be thinking ahead, not backwards.

  10. I’m not sure I agree with your contention that feed reading should be part of the browser; it feels more like email to me than to web browsing.

    That said, you may not be aware that Firefox at least has hooks in it to integrate feed reading into the browser. There are several extensions which have done this (to varying degrees of success), and I’m currently working on a feed-reading extension that will try to emulate Google Reader as faithfully as possible (given that it is implemented in a browser).

  11. […] Why feed reading is an open web problem, and what browsers could do about it [Planet GNOME] […]

  12. Well, Firefox already considers RSS (push content) a part of the browsing experience in Live Bookmarks. It’s just clear from low usage that this has not made for a sufficiently compelling experience. Is this design alone? As you indicate, poor discoverability probably also helped.

    We already once said “push content matters” enough to include it as a part of the browser. And, as you point out, it may be failing in the browser, but clearly not in other places on the net.
    I guess I’m saying that I agree, but also a call back to the fact that we put it in there for a reason, and the usage of pushed content has *grown* not lessened.
    To extend your argument, if Google had been less kind with Reader, they could have prevented users from exporting their data as well as just pulling the plug immediately. Freedom and data ownership is one of our rallying cries. (Yes, I suppose I’m preaching to the choir.)

    To distill and extend some of the ideas in the comments: Content feeds could be a part of a user’s browsing profile, just like bookmarks and passwords. They could be synced and backed up (via PICL). They could be implemented with a common API so the built-in light interface accesses them, then so could a more feature-ful addon. If a user builds up a list of feeds/sources, they can switch from one interface to another without (much) penalty. (Some customizations in an addon might not be transferable.)

    I think the idea of seeing that a user frequents a page and then offering to subscribe to its feed bears exploring. I’ve seen the same suggestion for adding a site’s search to Firefox (GSOC project I think). Perhaps there is warranted a standardized process for such an I’ve-been-here function.

    The other big question is then what exactly these content feeds really ought to be. Is RSS sufficient? Does it fail for our potential future of content consumption? Can we build a framework that is inclusive, but leaves room for more? If RSS or the current situation is insufficient, shall we explore and propose standards that better serve users today and in the future?

    Would this project not fit nicely within the Hatchery?
    https://mozillalabs.com/en-US/hatchery/

  17. […] Here's an interesting article by Luis Villa, Why feed reading is an open web problem, and what browsers could do about it. […]

  20. I’ve been a heavy RSS user for years. The demise of Reader will have zero impact on me. In a rational world, it would have zero impact on RSS.

    I’ve always read RSS feeds in a standalone application. The current stable release of Liferea is good on Linux (wasn’t always the case). I still use NetNewsWire on OS X. What both have in common is simple unclutter display of feeds, headlines, and items. The best part: I get just the text of an item body, minus the detritus elements of the web page. If I do want to see the original web content, that’s available at a click. Otherwise, I can move through my approx. 450 feeds much more easily and quickly than I could in a browser.

    Social media is OK for finding new sources that might be suggested by other people. But, I never want to be tied to a commercial social media product to provide the tool I use to read them.

    Plus, as the recent Reddit witch hunt amply demonstrates, so-called social media crowdsourcing is no more reliable that 2am bar chatter. (And yesterday’s compromise of AP’s Twitter makes matters worse.)

    Give me a good RSS reading application, let me find and assess the feeds I read on my own by my own standards, and I’ll be happy.

  21. Evan P.: As I noted in the footnotes (you read them, right? :) when I say “RSS”, I mean “open standards for publishing/subscribing/notification of updates”. I’m sure there are newer, shinier standards with the same basic goal of allowing open publishing and consuming of streams, and hooray for them- the browser should support them too.

  22. lmorchard: I think the “mobile-centric world” thing is overstated, for a few reasons. First, tons of reading still goes on in the desktop browser – at work, for example. But more importantly, most people aren’t subscribed to a million different things. They’re subscribed to a handful of things, and they don’t actually care about syncing or “marking read” in the same way you or I do when we’re reading hundreds of sites. They just want to see the newest stuff. Again, we can learn from FB and twitter here – it’s OK to show people the same stuff again without a fancy backend for it. (And of course, putting discovery and subscribing in the browser doesn’t prevent creation of a decent server-side solution for reading/syncing for the rare power user.)

  23. Scott T.: I’ve explained why I think feed reading isn’t like email. To put it another way: the primary purpose of email isn’t to share the web, and a primary mechanism of consuming the web isn’t email. In contrast, RSS+RSS-like streams are now a primary mechanism of consuming the web.

    I’m glad to hear about the hooks, but they aren’t enough: if it isn’t baked into the core browser, it’ll continue to wither on the vine, because the discovery of RSS will continue to be impossible for most users.

  24. “Give me a good RSS reading application, let me find and assess the feeds I read on my own by my own standards, and I’ll be happy.”

    No, you won’t, because over time people will stop providing RSS feeds. It’s already happening (look for the RSS feed on the uber-trendy evening-edition.com, for example). And then we’ll have completed the abandonment of stream publication and consumption to proprietary silos. Hooray. :/

  25. […] It would be nice to create a new system and include the HTML5 web standards guys, so that any new specs that are defined have standard visual results, rather than being left up to chance or worse the browser makers themselves. I highly doubt this will ever happen, but that'd be the ideal in my opinion. Update: You can find very similar thoughts from Wikimedia's Luis Villa here: Why feed reading is an open web problem, and what browsers could do about it. […]

  27. This is a very awesome and welcome post!
    We (Superfeedr) have been trying to find a solution to ease subscription in a decentralized world. That’s https://www.subtome.com/
    It uses a combination of localtsorage and redirects thru regsitration to transaparently allow you to subscribe to pages (using feeds, but hding them) with the readers that you use and love.

    We would love your feedback on it!

  33. I think the right solution is for someone to build a really good Chrome extension that stores its feed metadata in Google Drive. We need to be able to forget about hoping someone will keep a server and a business running so we can read the news we care about.

Comments are closed.