Tag: RSS

Posted On

Google announced last night that they are sunsetting Google Reader on July 1:

There are two simple reasons for this: usage of Google Reader has declined, and as a company we’re pouring all of our energy into fewer products. We think that kind of focus will make for a better user experience.

By which they mean “we started cutting features from Google Reader, so fewer people enjoyed using it and ended up stopping,” and “no one was developing it anymore.” I’m also curious to see where this “better user experience” will appear. Certainly not for Google Reader. :)

Anyone who has been paying attention has seen this coming; Reader has been neglected for some time and in some cases has had features removed from it over the last couple of years. It was clearly not receiving much love. I haven’t used it in well over a year, which was sad because I lost the use of Reeder across all my devices, which I have gladly purchased three times over on all my devices.

A lot of the chatter has been about available alternatives. The big ones that I’ve seen kicked around are NewsBlur, The Old Reader, Feedly, and Fever. I’ll tell you why I use Fever and why I think that—for now—it’s the best alternative.

When it comes to the content I create, I’m really big on ownership. I have my own domain, I run on open source solution for blogging that relies on a deeper open source stack to run, and I act as my own gatekeeper. I have argued in the past that you should do the same and that the blog is still the atomic nucleus of individually-generated content on the internet.

That’s why I’m using Fever. If there were an open source alternative that were just as easy to set up and configure, offered a robust API, had at least some of the same features, and ran on the same stack as my WordPress installations, I would switch in a heartbeat. But for now, Fever is it. Here’s the bulleted list of things I like about it, for those of you who are in to that sort of thing:

  • Easy to set up (LAMP stack).
  • Includes a bookmarklet that leverages autodiscovery to help me add feeds without fuss.
  • Has an API that now works with Reeder for iPhone to sync subscriptions (wish the iPad and iOS apps would catch up to this).
  • Has great keyboard shortcuts, including one that sends the selected article to Instapaper (my primary information flow relies on this).
  • Can be cron’d so subscriptions get updated on a schedule I like (I prefer hourly and will turn that down if I feel like it’s ruining my life).
  • Has the “What’s Hot” list, which I don’t use as often as I should, but aggregates the links that appear in all my feeds to show me what they are linking to—and helps me discover new things in the process.
  • Allows me to hide read/unread counts.
  • Allows me to add feeds just for the purpose of the aggregation feature so I can add news sources without feeling that I need to read everything they post (I prefer to aggregate things friends are talking about, anyway).
  • Includes a referrer anonymizing solution for when I go to stories that are in my reader.

And here’s the list of things I don’t like about it, in case you want to know that:

  • Not open source. (Though I don’t mind giving Shaun money. He’s a pretty cool dude.)
  • Non-cron syncing takes a long time, but that’s probably more to do with my feeds addiction.
  • Mobile browser view sucks, and it’s awful on iPad (this is the main thing that would get me to switch away). Reeder’s API syncing is what brought me back to Fever after I tried it once and dropped it to go back to Google Reader for a time.

All of the other alternatives I have listed above are hosted services. They aren’t under my control. Out of all of them, I find NewsBlur the most compelling and the option that appears to have the greatest chance of success as a Google Reader alternative.

NewsBlur is available as an open source DIY project, but the instructions for it are more work than most humans are willing to undertake to set up something on their own, and I’ll bet that a lot of hosts wouldn’t support it based on its requirements. I’d love for someone to tell me there’s an easy way to set it up on Webfaction, because my wife is now looking for a Reader alternative and something that supports more than one of us at a time would be great.

The most important thing I can say is that if you are/were a Google Reader user, please take a look at the alternatives that are available and use one. RSS is still out there, and you should use it: it’s a robust, open solution to aggregating content. If everyone stops using it, there’s always the danger that it will stop being supported by even more services and eventually disappear completely.

If that happens, then the alternatives won’t matter.

Posted On

Twitter published the overview of version 1.1 of the API yesterday. Lots of space and many words have been devoted to why their changes are hostile to developers of Twitter-based applications (and they certainly are). For background on the changes and how they affect developers, the best opinion posts I have seen are this one by Daniel Jalkut on the OAuth token restrictions, and this one from Ben Brooks on what the changes indicate about Twitter on a corporate level.

(For additional reading, see Marco Arment’s exposition of the changes and Tapbots’ initial reaction juxtaposed against their pulling the Tweetbot beta.)

I think what’s been overlooked in all this is how some of the changes—maybe the most influential and important ones—are actively hostile towards users of the service. They place burden and unnecessary restriction on the very users that Twitter is looking to court and retain to turn the wheels of their business model.

I’ll preface this by saying that I am very much a layman, so my understanding here may be flawed. If you can correct me and convince me that it’s really not all that bad, please leave me a comment and let me know.

Abandoning Open and Accessible Standards

Once upon a time, Twitter supported the use of RSS as a method for grabbing information from your timeline and even updates from one or more users. In fact, when I first started using Twitter myself and third-party clients didn’t exist yet, RSS was how I consumed timeline information.

For some time now, RSS has been pretty well hidden, but you could still access it and use it if you wanted to even though it was unsupported.

No more:

We’ve chosen to throw our support behind the JSON format shared across the platform. Consequently, we’ve decided to discontinue support for XML, Atom, and RSS, which are infrequently used today.

This is a page out of Facebook’s strategy, where I would love to be able to grab RSS feeds or groups and friends who basically use it for blogging, but I can’t—or at least I can’t figure out how. JSON is still a standard and it’s still open, but your data is getting less and less accessible all the time.

In version 1.1, we’re requiring applications to authenticate all of their requests with OAuth 1.0a. Not only will this visibility allow us to prevent abusive behavior, but it will also help us to further understand how categories of applications are using the API. We’ll apply that understanding to better meet the needs of developers as we continue to evolve the platform.

Let’s be clear; by “further understand” they mean “tightly control.”

On Twitter, your updates are “public,” but they are “public” only insofar as Twitter wants you to be able to display them. By curtailing methods of pulling data that can be used without authentication, and controlling tightly who can and cannot authenticate to the service and how many times, it allows Twitter to eventually trap your data.

I believe that even with these changes, public timeline data can be queried without authentication via JSON, but JSON tends to be less end-user-accessible than at least Atom and RSS. I can still access my timeline RSS now, but I will assume that this will change when Twitter deprecates API 1.0.

Token Limits

This is what a lot of the hubbub has been about from a developer standpoint, and to be fair, developers do end up with it being their problem. But users are the eventual target of this restriction.

All applications replicating the core Twitter experience, usually called “clients”, will have some new restrictions placed on them, including a 100,000 user token limit.

So when an application has hit its limit, how is that supposed to be communicated to the user who requests token 100,001?

Do you—

  • Wait until your token counter hits a certain limit pre-100k, then pull your app from distribution (thus alienating users who want to evangelize your app to friends and others who want to try it)?
  • Display an error message to users 100,001 and beyond (who will probably blame you anyway and not use your app even if you get more tokens)?
  • Furiously blame Twitter for the limit in either a status message or page on your app’s website (potentially confusing users even more)?

The point I am trying to make here is that even though the developer is the one who is hamstrung by the token limit, the users of the app are the ones who face the messaging and confusion. The users are the people who are told that their choice to use a client that isn’t the core Twitter experience is the wrong choice and isn’t permitted.

I am sure this is intentional on Twitter’s part as a nudge to get as many users as possible to use the “official” clients. (Which, let’s remember, started as third-party apps in most cases.) But from the users’ standpoint, something will just appear to be broken. Whether the user decides to blame the developer of the client in question or the Twitter service as a whole, it’s limiting choice—and worse than that, it’s limiting choice in a way that wasn’t limited previously.

A lot of users probably won’t care or notice, and I seem to recall seeing stats recently that indicate that the number of Twitter users who consume the information on Twitter via non-official clients is actually quite small. But for those savvy enough, it’s going to be annoying.

In the end, I think it’s the wrong move for Twitter, and it’s the wrong move for Twitter’s users. Personally, I am using Twitter less and less as the crazy around it increases. And I’m pretty sure I won’t be the only one.

Posted On

Recently, I switched back to using Google Reader from a short experiment with FeverÂş. As part of the switch back, I decided I would wipe my list of subs and start over to make sure I was prioritizing and categorizing appropriately.

In doing so, I stumbled across this post on the Google Reader blog from back in 2005. It contains a small bookmarklet labeled “Show all feeds” that I now use all the time as it simplifies the process of subscribing to feeds from just about any site, as long as they are announcing their feeds.

Just drag the bookmarklet up to your bookmarks bar on whatever browser you prefer to use. When you visit a site you’d like to add to your subscriptions list, click it. You’ll see something like this:

Then, click on the link that corresponds to the feed you’d like to add. It will open in Google Reader, where you can click the little Subscribe button.

Posted On

(Photo credit: Thermometer by flickr user slayer23.)