A lot has been written already about Google’s announcement that it will shutter its Google Reader product on 1 July. It’s a decision that has infuriated many, partly because when the company launched Google Reader in 2005, its free price tag undercut and then virtually destroyed the market for competitive products.
Soon enough, Google Reader had become a de facto industry standard, even as it became more and more apparent over the years that the company cared little for the market that it had come to own. As its hegemony endured, an ecosystem of Google Reader-based feed reading clients came into being, like a city that builds itself on an earthquake fault line. If you were in the market for an RSS client at any time in the past three or four years, you’d have been hard-pressed to find one that wasn’t based on Google Reader. So once it passes into the next world, Google Reader will leave in its wake few if any robust alternatives for consumers to choose from.
There are some important takeaways from this unfortunate history. First in my mind is the fact that Google Reader didn’t beat every other feed reader purely because it was free. Google Reader won because it was an extremely well-executed example of interaction design.
Features Don’t Add Up to Products
I’m choosing my words somewhat carefully here because I look back on Google Reader now as an example of a very particular type of design solution. To me it was something short of what we think of today as product design because its designers focused purely on optimizing for tasks, but not for the bigger picture.
Google Reader has always been good at the mechanics of adding new subscriptions, scanning read versus unread items, negotiating between folders, sharing items with other Google Reader users, favoriting items for later, switching views on the fly, and most of all letting the user zip through dozens of posts in short order. This was perfect for its core audience of extremely tech savvy feed consumers. If you were one of these folks, and you had an inventory of everything mechanical you might want from a mid-2000s feed reader, Google Reader was a wonderful solution. This intricate match of specialized needs and a specialized toolset, combined with the mighty weight of Google’s computing infrastructure, and sweetened with the low, low price of free, made for a winning combination.
Learning to Read
But it was never easy to learn how to use Google Reader. Personally, it took me many attempts to finally acclimate myself to Google Reader’s very peculiar way of thinking about organizing feeds. I always found its conception of folders to be bizarre, for example; you couldn’t drag items between them and you couldn’t rename them.
The app seemed content with presenting one of the steepest learning curves of any browser-based software I can recall outside of the enterprise space. It did virtually nothing (or nothing effective, anyway) to help new users build a workable understanding of how RSS works and why they should use it. And it did almost even less to help those users build a mental model of how Google Reader itself worked.
This is exactly where I think Google Reader was a great example of interaction design but a very poor example of product design. The app shrank from the responsibilities that great products have to prioritize features for users and, most importantly, to omit what isn’t necessary. I mentioned earlier an imaginary inventory of feed reader features that a technophile might want circa 2005; Google Reader said yes to almost all of them. Just as importantly, it said no to not enough of them.
Meanwhile it never seriously accounted for the whole dimension of affordances that make a product attractive and visually intuitive, that imbue a product with humanity. It resigned itself to a presentation layer that was impenetrable for the lay user, and monstrously dense for every user. It called itself a reader but just to look at it was to see that it was curiously unreadable.
In many ways Google Reader was to me only the most evolved, Web-based evolution of the kind of design that Microsoft practiced for years: design that predicates itself on a high bar of user expertise. In the case of Microsoft’s Office products, they virtually demanded that new users read the accompanying manuals before it was possible to do the work you set out to do. In the case of Google Reader, it was virtually expected that you read all of the blogs that were then engaged in the then-current meta-narrative about blogging and syndication and all that nonsense before you could read the feeds you were actually interested in.
All that said, I eventually did learn to master Google Reader’s many peculiar ins and outs, and I came to rely and even become quite attached to the product. It’s still one of the apps I turn to most often on my computer and, through the excellent Reeder app, on my iPhone too. My biggest complaint is not that it was imperfect, but rather that it never evolved. As incomplete as it was as a product, I can’t reiterate enough how I really believe that many of its low-level interactions were executed with aplomb. Had its parent company deigned to invest a bit of care into it, it could have turned into something truly wonderful.
I think they’d continue with the product if people used the web app rather than third party applications. I’ve worked in this industry for five years and, during this time, have only met one person who used the web interface.
They were monetising the web application through adverts and such but they can’t do the same through Reeder and such.
I’m looking forward to seeing how Reeder, Feedly etc produce a stable environment for feeds without charging for it (I’d happily pay ~$15 per year to host my feeds with someone).
I use Google Reader (Desktop) and Byline (iOS), and am now also floundering around for alternative. None seem to fit.
Here in is the rub. When the experience of a process (reading rss feeds) becomes enmeshed with an application, looking for a creditable alternative becomes hard. The alternatives are being measured against an imperfect bar to which you have grown accustomed.
Is the best strategy to choose the one that looks to have the most long-term chance of survival, and adapt behaviour to suit the product?
I… always used the Google Reader web interface, especially in iOS Safari. The thing I’ll miss most about it is that most of the [free] alternatives I’ve seen (Feedly and others) are standalone iOS apps, which to me are awkward:
Many of my RSS subscriptions are to sites that only give you the lede of each article (i.e. via FeedBurner).
On a mobile device, I mainly want the ability to open any article I’m interested in reading completely in that device’s web browser, without having to pop between apps.
I’m trying out this site now, but there are 40,000+ people ahead of me in the queue to import my Google Reader subscriptions: http://theoldreader.com/
This is exactly what happens when your end-user isn’t your customer. If Reader was generating ad revenue, or even good data for “The Algorithm”, you can be damn sure Google would be continuing the product, but it’s clearly not. The moral of the story is to make sure that the Google product you use is serving up lucrative ads before you come to depend on it.
I didn’t even realize I had become as acclimated to it as I am. I’m trying to switch to feedly but it doesn’t feel as intuitive, somehow. At this point in 2013 I feel ready to start paying nominal fees for these services instead of seeing them bought or retired. And yes, it would be nice to see them improved here and there! I will say that the oddity of GR’s design is probably the reason many of my female blogging peers don’t use RSS readers at all, much less GR.
And I still miss the causal way one could “share” an article on GR, before google+ came along.
I don’t quite understand why Google isn’t able to monetize this. If there’s one way to make an acurate profile of my interests, it’s through my feeds, actual reads, stars, shares and exports.
Google is pretty clearly trying to kill RSS as a technology, not simply Reader as a product:
“I always found its conception of folders to be bizarre, for example; you couldn’t drag items between them and you couldn’t rename them.”
Ummm…you can do both of these things.
Thank you! Your remarks have been sent to Khoi.