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