Tag Archives: RSS

Don’t forget the feed

Google killed Reader just over five years ago. This week, Digg decided to mark this Wood Anniversary by taking a club to its own Reader. Yet again, we oldsters find ourselves shaking our fists at Kids Today. See, for example, Bryan Alexander's thoughtful post on finding a way forward for RSS readers and RSS in general.

I celebrated this turn of events by struggling to set up an instance of Tiny Tiny RSS on my web server. Having finally figured it out, I'm pretty pleased with the functionality. One nice bit is the notice regarding "update errors":

Oh noes!

TT-RSS then has a tool for viewing a list of broken feeds. Looking through this list has been an interesting experience. For one thing, it's given me the opportunity to think about a few dozen people who have not otherwise entered my consciousness in a number of years.

More importantly, it's convinced me that the real threat to RSS is not the lack of reader software; you only need a couple of good ones to support an ecosystem. The bigger issue is that RSS content is disappearing.

The more mundane kind of problem is link rot and broken redirects. Many domains have gone away, some have moved in such a way that RSS links no longer work, some are now hidden behind password protection (Blogspot seems to be a particular offender). Web sites come and web sites go, so some of this is to be expected.

The more worrisome trend is content that's not available through RSS simply because there's no feed mechanism. A shamefully large number of my geekier aquantainces have moved their blogs to Jekyll and other static-site-generation tools, which don't appear to have feed support out of the box; and – this is the "shameful" part – since these folks, geeky as they may be, think so little of RSS, they don't bother setting up the secondary plugins or whatever necessary to serve feeds. I expect that kind of behavior from lock-up-my-content companies and technically-clueless organizations that rely heavily on proprietary and bespoke software, but not from people who ought to know better.

For all of its lumbering bloatedness, one of the truly wonderful things about CMSes like WordPress is that they give you things like RSS – along with a pile of other boring-but-critical-to-the-future-of-the-open-web tools – by default. You don't need to make the decision to support RSS readers (or responsive images, or markup that is accessible to assistive technologies, etc) – the system provides them for you, and you have to go out of your way to turn them off.

Those who build their own systems for old-school things like bloggish content distribution, or who rely on teh new hotness to do these tasks in ways that are slicker than the old-school tools, should beware the dangers of discarding the automated systems that are the result of many years and many minds and many mistakes. If you must reinvent the wheel, then do your due diligence. RSS feeds, like other assistive technologies, should not be an afterthought.

Doom and gloom upon the offing of Google Reader

This week, Google announced that it’s shutting down Reader. This is the first of Google’s “sunsets” that hits me personally – Reader has been a crucial part of my internet use for the better part of a decade. I happen to think, like Marco Arment, that in the long run the loss of Google Reader will probably be good for innovation in RSS readers and for RSS in general. Google’s hamstrung app has been just good enough for people like me, but non-approachable for non-geeks. A year from now, I’m hoping that there’ll be many more quality players. So, in the long run, I’m reasonably optimistic.

More immediately, though, a couple of causes for concern:

  1. Finding an alternative to Reader. My RSS reading habits are too ingrained for me to abandon them, even for a short time. More than that: following RSS feeds is beyond mere habit, but is check on my intellectual honesty. I follow many blogs whose authors I frequently disagree with, or even dislike. (Contrast this with Twitter, where I’m pretty fickle about whom I follow, and how many tweets/links I pay attention to.) So RSS is, for me, a partial antidote to the echo chamber tendency. That means that I’ve got to find a new app, and migrate over, and I’ve got to do it quickly.

    There have been a number of posts over the last couple days listing Reader alternatives. A number of them are cloud/service based, and for practical reasons (such as, um, Google Reader) as well as philosophical reasons (see below), I’m only considering alternative tools that I can run either locally or on my own server. A couple that spring to mind:

    • Fever. I’m interested in this one because (a) the screenshots make it look nice, and (b) it comes highly recommended by people I respect, like D’Arcy Norman. I like that it’s self-hosted. I don’t like the fact that its sustainability model is to charge for downloads. It’s not that I don’t think the author shouldn’t be paid – I would be happy to pay $30 or $300 for a great RSS reader app. It’s that the success of the single-developer model is contingent on the willingness of that developer to keep working on the project (paid or otherwise). I’m far more comfortable with software that is community developed under a free license, ideally using a set of technologies that would allow me to modify or even adopt the project if the main devs were to abandon it.
    • Tiny Tiny RSS. tt-rss also comes recommended by someone I respect (Mika Epstein, in this case). And it’s community-developed, which I like. It doesn’t look as pretty as Fever, but aesthetics are about fourth or fifth on my list of requirements.
    • PressForward. As Aram describes, the PF team (of which I’m pleased to be a member) is working on a WordPress-based tool that, among other things, does RSS aggregation and provides some feed-reading capabilities. PressForward is really designed for a different kind of use case – where groups of editors work together to pare down large amounts of feed data into smaller publications – but it could be finagled to be a simple feed reader. Mobile support is a particular pain point, as 50% or more of my RSS intake is done on my phone, and PF has nothing in place to make this possible at the present time. So, PressForward may not be quite ready for primetime, but I do think that it has promise.
  2. Get the hell off of Google. We all know that Google is a company with shareholders and profit goals to meet. Yet we often act like Google is some sort of ambient benevolent force on the web. Since I started Project Reclaim, I’ve been working on extricating myself and my data from the clutches of Google (among other corporate entities). Reader’s demise is a wake-up call that the time for dilly-dallying is over.

    For my own part, I still use a few Google services besides Reader:

    • Gmail. I don’t use Gmail primarily anymore, though many people do still email me at my gmail.com address, so obviously I have it open and I check it frequently.
    • Picasa. I use the Picasa desktop app on OSX to export photos from my cameras and organize/tag them. I also use Picasa Web Albums as one of my many photo backup services. (Seriously – I back up my photos to no fewer than six different local and cloud services. Nothing is more important or irreplaceable than my family photos.)
    • Drive/Docs. Aside from the occasional one-off collaborations, I use Drive to maintain a number of spreadsheets and other documents that I share with members of my family, etc.
    • Calendar. I’m not a heavy calendar user, but when I do use a calendar, I like Google because of its integration with my Android phone.
    • Chromium. Not Chrome, but still largely Google-reliant, Chromium is not my main browser, but I use it daily for doing various sorts of development testing.
    • Android. This is maybe the one that steams me the most, because at the moment there are no truly free alternatives. (Firefox OS, please hurry up.)

    In some of these cases, there are easy ways to get off of the Google services. In others, it’ll be a challenge to find alternatives that provide the same functionality. In any case, the Reader slaughter is a harsh reminder that Project Reclaim has stagnated too long with respect to Google services.

    More than myself, I’m worried about others – those who aren’t as technically inclined as I am, or those who simply don’t care as much as I do. Google’s made it pretty clear (as is their right, I guess) that they’re not an ambient benevolence. Those who rely on Google then, especially for critical services like email, should take this warning very seriously. Please consider carefully what you’re doing when you make yourself wholly dependent on the whim’s of Google’s product managers, and consider options that are either free-as-in-speech, or services that you pay for in a traditional way.

New BuddyPress plugin: BP Lotsa Feeds

I’ve been working on a project recently with Kevin Prentiss and the other fine folks at Red Rover. Kevin is a big believer in the power of feeds, and I’m a big believer in the power of BuddyPress’s activity component, and together we realized that BuddyPress’s RSS support for its rich activity content is a bit lacking.

This new plugin, BP Lotsa Feeds, is meant to address the issue. It activates RSS feeds for just about everything in BuddyPress, from an individual member’s sitewide comments, to new group memberships for specific groups, to individual forum topics.

Read more about the plugin on its home page, and follow its development on Github. Thanks to Red Rover for sponsoring a cool plugin.

Getting Read It Later items to the Kindle

Lately I’ve been using Read It Later as a sort of temporary-bookmarking system. Between my RSS feeds and my Twitter stream, I come across much more text than I can stop to read in the middle of the day, and Read It Later provides a pretty elegant combination of tools of saving these pages for later – a Firefox extension for marking pages and an iPhone app for reading them. An especially great feature of the RIL iPhone app is the way it handles offline reading. When I sync my list, it stores a copy of the source web page, which I can then either read in its original HTML form or after RIL applies its remarkably reliable text-extracting algorithm. In this way I get a lot of reading done while on the subway and away from internet access.

Read It Later on my Kindle

Read It Later on my Kindle

When I got a Kindle recently, I thought that it would be ideal to shift some of this long-form reading from the iPhone to the Kindle’s larger and easier-on-the-eyes screen. A bit of searching turned up Kindlefeeder, a website that will collate RSS feeds and send them as a single document either directly to your Kindle (incurring a $0.15 charge from Amazon) or to your email address, whence you can then transfer to the Kindle via USB. RIL provides feeds for a user’s reading list (here’s mine http://readitlaterlist.com/users/kachooney/feed/unread – you may have to edit your RIL privacy controls to make sure that your items feed is not password-protected). I plugged this feed into Kindlefeeder, but immediately ran up against a wall: RIL’s feed contained titles only. Since my goal was to make my reading list available offline, I needed full feeds.

This seemed like a job for Yahoo Pipes. (Bonus for me: I had never given YP more than a cursory glance in the past, so this was a good chance for me to learn the ropes, er, pipes.) The strategy: hand my RIL titles-only feed to YP, and tell YP to fetch the full text of each item and store it in item>description of a new RSS feed. Then, subscribe to the YP RSS feed with Kindlefeeder. Here’s a sample: http://pipes.yahoo.com/pipes/pipe.edit?_id=3a0be51021240c9eda3541ce5041a29f.

You’ll notice that I’ve filtered out feed items pointing back to http://nytimes.com. That’s because the NYT (1) breaks up most articles into multiple pages, and (2) publishes pages that are uniform to submit to a single parse. NYT feeds are thus handled by a different pipe, one with a few extra steps. First, instead of calling up the item>link from the RIL feed, I get the printer-friendly version (so that it contains the entire article text on a single page). Second, I filter out the header and footer material (advertisements, navigation, etc.) with “cut content” under “Fetch Page”. If, in the future, I find myself sending a lot of items to RIL from another source with similarly uniform markup, I might create yet another filter to strip the extraneous content off.

The final snag in this setup: free Kindlefeeder accounts will not fetch RSS feeds created by Yahoo Pipes, because these feeds take so long to create and therefore put undue stress on Kindlefeeder’s servers. At $20/year, the ability to transport my reading list to the Kindle seemed worth it to buy a Kindlefeeder premium account. So congrats, Kindlefeeder – you got a customer out of me. (Another cost justification – it’s possible to use a similar process to fetch the entire contents of various magazines from the partial feeds they publish on their websites. $20/year is pretty cheap for unlimited magazine subscriptions on the Kindle.)

So go make some computer technologies of your own. Get out of the house and go do it!