Roger Binns — Sat 08 June 2013

I switched from Google Reader to tt-rss two weeks ago. It works well and is my permanent solution. That also means I don't have a page permanently open at Google any more, which means far more conscious effort is needed to hit Google Plus which still remains unreadable. The screenshot shows just how many of the two million pixels on my screen are devoted to actual content in yellow. Compare to Reader or tt-rss which come in at close to 100%. I'll probably give up on Plus completely.

On the topic of a Reader replacement, tt-rss pluses are that I can run it on my own server, there are two Android clients (I like the non- official one), feeds are automatically sorted into alphabetical order, the mobile web view is good, there is a well engineered and extensive plugin mechanism, updates are easy, and you can import your Reader feeds and starred articles. There are lots of little pleasant touches here and there. It is fully open source.

On the minus side the UI lags when showing articles are read. The developer says this is because the Javascript rate limits hits to the server, and they don't update the UI until the server has been told. This means it takes up to 15 seconds from when an article is read until the UI updates to show that. They also grey the text instead of a border like Reader. The Reader approach is better UI especially if you are part way through reading the article. The main developer can be quite abrasive, but anyone can fork the project if that turns out to be too much of a problem.

Category: gplus – Tags: google reader, tt-rss

Roger Binns — Thu 14 March 2013

Several people have asked me what I am going to use instead of Google #Reader . I know what I definitely won't use - the majority of the alternatives out there, because they are obsessed with with showing items as rectangles with as much of the rectangle taken up with pictures as possible. (That is also why I gave up on G+ on Android.) My RSS feeds do not constitute a pretty magazine. For example look at http://feedly.com and notice how the screenshot of the mac is showing 6 articles - all that space for 6 articles! Pulse's home page has way more articles but all as images. 99% of my RSS articles have no images.

Reader has three important parts. One is the backend which means you can read from any number of computers and devices and a centralised location keeps track of your feeds and which articles have been read. There is no open standard protocol for this and I'm hoping that in the next few months one is born. (Reader was used by many but as far as I can tell the API was not official, arbitrary and reverse engineered.)

The second was updating the feeds (a background task). Having worked on consuming RSS feeds before, it turns out that many only have the most recent few articles which could turn out to be a few hours worth or at most a day. If you don't regularly poll the feeds then you will miss out on articles. This rules out pure clients like Liferea.

The final part is the presentation which worked well with a hierarchy of folders, feeds, articles and article, making it very easy to jump around hierarchy. UI that blends it all together into a single stream does not work (eg G+) because that only works with a low volume of articles. (I do not follow many people on G+ due to their posting volume. I would happily follow them via RSS feed but G+ doesn't export the data so I don't. Google loses by being a closed island.) So far only http://tt-rss.org shows that hierarchical context and navigation UI. Others like http://theoldreader.com/pages/tour seem obsessed with the whole social side, and note there is no screenshot showing the actual reading experience!

Oh, and the presentation part needs to work in disconnected mode on mobile too.

My plan is to punt for a few months hoping that someone comes up with the sweet spot of openness and readability. If not I'll just write my own. The database side of things can be solved in a home grown manner, but a toolkit like https://www.parse.com could be used instead to solve the data problem keeping web (Javascript) and mobile clients all synced up with state.

However I realised that it would be even easier to use +Dropbox as the state and synchronization mechanism. Each article becomes a file, and gets deleted by a reader when done. The poller just keeps adding the files from feeds. (Yes, that is the same principle as Maildir.) Dropbox released https://www.dropbox.com/developers/sync recently so that solves the offline mobile clients sync problem. I just wonder how well they will cope with hundreds of little files being created and deleted every hour.

Category: gplus – Tags: google reader, tt-rss