is a blog about design, technology and culture written by Khoi Vinh, and has been more or less continuously published since December 2000 in New York City. Khoi is currently Principal Designer at Adobe, Design Chair at Wildcard and co-founder of Kidpost. Previously, Khoi was co-founder and CEO of Mixel (acquired by Etsy, Inc.), Design Director of The New York Times Online, and co-founder of the design studio Behavior, LLC. He is the author of “Ordering Disorder: Grid Principles for Web Design,” and was named one of Fast Company’s “fifty most influential designers in America.” Khoi lives in Crown Heights, Brooklyn with his wife and three children. Refer to the advertising and sponsorship page for inquiries.+
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.+