Why Twitter is not an RSS replacement
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
We are all familiar with feed aggregators like Google Reader, or Netvibes, or Pageflakes or NewsFire. These applications, hosted or native to the operating system, regularly check the updates from blogs RSS or Atom feeds. In some cases, like with the PubSubHubbub protocol, the aggregator can be instantly pushed an update when it is made.
Sometimes, we jump to the next step and start using Twitter as our primary mechanism of information. The argument here is that everyone is on Twitter and by simply following the people you like, you'll get all the news you're gonna need. RSS is dying and all the cool kids have a Twitter client.
But Twitter, as a feed aggregator for an RSS user, is not viable. Really. From a user experience point of view, the features Twitter or any social media (pick Facebook) can support in its timeline model are different from the classic blog subscriptions. They're a catalyst for sharing: you will be reached by the important news seconds after they have been published. But they are far less useful for recall, for example, or for citations.
I will use twitter.com as the example, since it is the lowest common denominator for the various clients we may use. I'm more interested in discussing the model differences: a set of persistent feeds with uniquely identifiable, interoperable elements, versus a single (or multiple in the case of lists) timeline we should filter and work with.
Recall is a term used in information retrieval (the science of search engines, for example) which measures the fraction of the relevant documents which are retrieved by a query.
Two notes. First, recall hould be balanced by precision: a system which shows you every single page on the web has perfect recall, as it presents all the relevant elements. But it's not very useful. Second, an example of how recall is important to some people: when I dive into a topic, and I subscribe for example to Greg Young's feed to hear more about the evolution of Domain-Driven Design, I do not want to miss a single post. I don't care how cool NoSQL databases, I want my articles on DDD and CQRS. All of them. I want to select the topics, not being submerged by the topics that the people that tweet the most like.
Transposing this for the problem of reading news and blog posts, our query is getting the relevant articles and web pages recently published, which topic falls into our interests. We try to do so by following people we like, but Twitter has very little recall anyway. It's easy to miss an article simply because you weren't on Twitter or your twitter client at the right time: the timeline is simply not meant for being read completely (and the user interface proves it: you can't easily jump to a timestamp in the past.) The model promoted here is that you should keep Twitter open all day, or setup some smart client to keep track of what.
But how such a client should filter? The volume of tweets is enormous, as if you follow some hundred people like me, it's easy to get thousands of tweets a day. Producing a tweet is easy: just 140 characters. and the signal/noise ratio becomes lower and lower. The problem of losing interesting information in the sea of tweets brings us to the next issue. Even if you have the most cool client on the planet, you'll spend time marking thousands of elements as read.
The lifetime of tweets: according to several researches, more than the 90% of replies or of retweets happen in the first hour after a tweet is published. In practice, the tweet gets lost after new tweets pile up over it. If it's not linked from a web page, it will simply vanish in the bottomless sea.
At the same time, a tweet can be individually cited via a unique URL, but citing conversations is almost impossible. Either you take a screenshot, or I'm not sure how to link to it. Conversations in blog comments are here to stay, while Twitter conversations are like real life ones: either you take notes, or you will have to rely on your memory.
Being forced to have an account with a particular service in order to post updates is a debacle for open standards, no matter which service. Feeds have standards such as RSS and Atom, and you simply publish your own copy: every client can subscribe to any subset of the feeds available on the web directly, without a single bottleneck or, worse, single point of failure or, worse, single point of censorship. Today, the worst single point is failure: Twitter is famous for its downtime.
There is no navigation by category for tweets (although you can use lists to divide people? It seems not very diffused: at the time of writing, I have 570 followers but only 79 listed me.). This is a frackin' lack of granularity: I've read enough of Uncle Bob opinions on politics in a country where I do not live, or how PHP community leaders are good at brewing beer.
I do not blame Uncle Bob himself: I follow a person, not a content channel strictly focused on software development. Yet, I found uncomfortable sometimes to tweet about unrelated topics like sports, thinking what my followers would get out of it.
Cal Evans says he follows 5 Twitter accounts which keeps all the news. Either he follows only them, and check the list every two hours, or I bet something will be missed. I subscribed to 242 feeds in Google Reader: how many list should I make? I'm more worried in the scaling of Twitter in the user experience than in its performance.
I have an High Volume category in Google Reader that I can scan with less attention than the other ones, and once I marked all from that category as read or finished scanning, other categories are not polluted by what americans think of their political leaders or British Petroleum (I don't care) or my friends have had for breakfast (I don't care) or someone is ranting about editors I do not use (hint: I don't care). There is no Mark all as read button or Keep unread for tweets. One day I found Cory Doctorow polluting the timeline with one hundred retweets: in Google Reader a single button would fix this and make all his noise vanish, in Twitter I just waited for the end of the DoS attack.
The result is that I can look at my Google Reader only at Saturday and still read all that I'm interested in. If I take a look at Twitter on Saturday, I got a mix of breakfast photos and weekend plans, not the best of the week. In this case, if you remember that someone posts really cool tweets, such as Kent Beck, you can go to his page to see everything he (and only he) tweeted, filtering out all the rest; but trying doing that with 200 different people. So much for a single aggregation tool.
The bottom line
Twitter is good for following promptly updates, but also for instant communication between people: I've been able to reach important people like the Supreme Allied Commander of Zend Framework on Twitter. I still post all my articles to Twitter for who prefers being notified there, but I know that in some hours from publishing that tweet will be worthless.
Feed aggregators instead list all the articles I want to read, at the time of my choosing, and with simple tools like categorizations and feeds of tags to filter out the noise.