Collected thoughts on Google Reader 08 Oct 2005

Having already a Gmail account, it was no trouble to fire up Google Reader, so I thought I’d give it a try. It’s not really worthy of an entire essay, but here are my thoughts for improvement:

Speed

Yes. It’s slow. Lets get that out of the way, assume Google are working it, and analyse the actual potential of the software.

Experiences

I imported flawlessly my feeds from Bloglines, and had a go at labelling them. By the way, if you’re doing any serious feed editing, you want to check out the button with the little downward arrow, just to the left of the filter box. It expands the subscriptions box so that all the feeds fit in them.

Naturally, Google are sticking with their ‘persistent tags’ (labels) metaphor that Gmail pioneered. Good. They’re great. They give the spoteneity of tags a bit of permanence and rigour, while still overcoming the limitations of the file/folder paradigm.

Why can’t OPML be extended to mark up which items I’ve read and which ones I haven’t? I know it’s a generic outline language rather than a specific feed reader format, but that’s what it’s mostly used for. It’s extremely frustrating having to wait for people to publish before i can start using Reader.

Starring

Another feature imported from Gmail are Stars: if you like an entry by someone, you can give it a star. It then stays in your starred list. (Aside: I guess when you star an entry the text is copied to Google’s servers for permanence, otherwise when you star an entry it would just disappear when it drops off the end of that feed).

Stars at the post level are nice, but I’d like to add stars to specific feeds as well. They’re my priority, must-read-when-a-new-item-appears feeds. I’m making do with a ‘favs’ label, but stars should just be extended.

Secondly, this starring feature is a bit like del.icio.us but without the social side (I’ll come to that later). Why not just integrate with del.icio.us, and instead of internally starring an item, share it with the world?

Sociality

Social software is red-hot at the moment and yet I see nothing of it in Reader. I want lots of features here: how many people are subscribed to feed X, what people are labelling it, how many other people starred that entry I just starred, and so on. So much potential here, but Google seem to be turning a complete blind eye. We’ll see.

To centralise or not to centralise 02 Oct 2005

There seems to be a simultaneous movement toward both centralising services and decentralising services.

Web apps like Gmail, Flickr and del.icio.us, ever more popular, are inherently centralised: everyone’s email and access to that email is kept on one network. In a similar vein, the rise of things like REST and the Google/Yahoo APIs mean that we’re relying on centralised ‘web services’ for our data.

Centralisation makes it easier for the centralised web service to provide statistics on everyone’s data. If the service provides an API, it makes it easier for anyone to get access to said statistics, which has some extremely expansive possibilities.

On the flip side we have microformats. The microformat principle is to make it easy to publish data, but do so in a standard way. In an ideal, microformat-filled world, anyone wanting to aggregate everyone’s data can just build a crawler and parser. Compare that to querying one centralised service’s API, and you have the essential difference between centralisation and decentralisation.

Initially, it seems that the microformat guys have got things the wrong way round. Querying one service is a lot easier than writing a crawler. The justification for the decentralised model is that there are a lot of people writing content less people writing parsers. Thus they’ve made microformats easier to write than to parse.

However, they’ve missed something here. Even though only a minority of people are writing parsers, the reading audience is generally much larger than the producers. Therefore we should make it as easy as possible for people to get access to as much data as possible. Centralised websites like Odeo do this: put the content in one place, then it’s easier for people to get at it.

But then the web wasn’t built that way. Imagine if all the web’s content was centralised into one giant index. Creating a new page wouldn’t be as easy as write-upload, it would be write-inform the index-wait-wait a bit longer-upload. Hmm. I don’t think so. The model the web has followed is a decentralised network. To find anything, you use a crawler. We could use this model for podcasts as well: write a microformat for saying ‘this is a podcast’, then Google writes a ‘Podcast search’ and that becomes everyone’s front door.

I mentioned in the last paragraph that centralising all content in an index makes it slower and more difficult to publish. This isn’t necessarily true: Flickr thrives because it’s easier to upload your photos to Flickr than it is to set up your own website and publish them there. It’s just the fact that the web wasn’t designed for sharing photos, so you’d need to write software if you wanted to share photos on your site. Flickr happens to be a very good system already in place.

So, it seems that centralisation and decentralisation both have their advantages. It seems that for sharing bookmarks and photos, a centralised system is generally easier and more natural. For just generic informational content, the decentralised system that is the web is the way forward.

Let me just finish by mentioning that I avoided using blogging as an example thus far because it’s an interesting case-in-point. Blogging has traditionally been available in two flavours, centralised systems like blogger (and now wordpress.com), or decentralised software like Movable Type and, of course, WordPress. Who knows where this will end up?

Future of this blog 14 Sep 2005

I’d just like to say what a great tool the ‘Top Posts from around WordPress.com’ and ‘Latest Posts’ sections are. They’re simply fantastic when you’re looking for something interesting to read. As an example, I just came across a post detailing the exact same problem I’m facing: now I have two blogs, how do I divide up the content between them?

To begin with, I’d like to point out that if it does nothing else, david.wordpress.com has spurred me into writing again. I’m getting into the frame of mind where whenever I read anything, I’m thinking in the back of my mind, ‘Can I blog that?’. Although my reasons for not doing this previously have been a decrease in my signal to noise ratio, I now realise that it’s important to Keep Blogigng or you’ll Stop Blogging.

I’m still keeping my options open for david.wordpress.com. You may notice that there are as of yet no categories here: that’s deliberate, as I want to keep the spectrum of what I consider ‘valid’ content as wide as possible. That means not shoehorning everything into a list of certain categories. Of course, I’ll eventually set up some form of categorisation here. Ideally, Matt would let us enable plugins and I’d get a tagging plugin set up

Hmm, actually, having a sample set of plugins isn’t a bad idea. I’ll send that off as feedback

Anyway, here’s a list of what david.wordpress.com might eventually turn out to be:

• A notepad
• Inspiration for xmouse articles
• Simply a platform for keeping up with the latest and greatest WordPress version
• A second publishing platform, perhaps just for my asides

And so on.