Making stuff as a founder of Avocado. Former music-maker. Tuna melt advocate. Started Google Reader. (But smarter people made it great.)

Four Firsts for Feeds

Other posts about Reader
For the last few years or so, I've been fortunate enough to have my day job involve thinking critically about reading feeds. As a result, I've been musing about first principles.

When Google Reader was first pitched, we had only one guiding principle for building software that would deal with feed reading and that's mostly worked well. But after years of development I think it'd be nice to have a more developed set of principles to help understand feed reading. I've had some in my head and while they're not perfect (not even close) our live experiment gathers a lot of supporting data so I've become more comfortable with sharing these thoughts. Maybe they're correct? Maybe they'll even be useful to someone? Dunno.

So here's my current Four Firsts for Feeds...
  1. Feed reading is inherently polymorphic.
  2. Attention data changes attention.
  3. Reading styles for feeds are pre-established and generally inflexible.
  4. Content that is perceived to be most valuable is not currently available in feeds.
And here's a little more detail about each one...

1. Feed reading is inherently polymorphic.

This is the half-baked line I used in the first meeting about Reader. I believed a feed reader's interface might have to be athletically flexible to match a wide variety of reading styles. At first I was thinking mainly about data types (e.g. calendars, photos, videos, news headlines, essays, polls, games) whose best presentations might have differing experiences. But obviously feed use is broader than content differences. For example, Reader's "frontend" currently delivers the following views of your data: an expanded view, a list view, a search results view, an all items view, an "only new items" view, an offline view, a "no-left-pane" view, Mobile-classic, Mobile-scrolling, Clips, Atom, JSON, Wii, Shared pages, an iGoogle Gadget, and rendering of video and audio. (Whew. Probably missing some.)

Based only partly on user growth after each view launched it's my opinion that Reader's frontend flexibility has been crucial to its success.

On Reader's launch I told a friend to "look at the URL" with the ridiculous hope that I could imply our forethought about delivering different views. (It was "" and the specificity of the last word implied that there were other kinds of designs in the wings.) The point being is that we began Reader by thinking this flexibility was central to building it. If asked, I suppose I'd encourage feed reader developers to think about whether or not their own applications need to be as flexible.

2. Attention data changes attention.

This is already obvious to technologists interested in feeds. So for those who don't know... the kind of data that tracks what we pay attention to and how and why we paid attention to it is currently used by all kinds of media consumption but seems fundamental to feed reading. This information often changes how people read so what's important is that the person reading feeds can see this stuff to help refine their experience. Currently Reader shows unread counts, trends, and annotations but we still have a long way to go in getting all of this kind of information into your hands.

One of the most important developments for Reader has clearly been marking items as read when scrolling, most notably by using the scrollwheel of a mouse. (Dragging is imprecise.) Starring items has been a crucial part of the Reader experience as well. I'm noting this because having flexible and fast means to alter attention data has been crucial to many, many people.

Side note: One of Reader's usage growth spikes occurred after its Trends feature was released. Other little-known fact: Mihai Parparita engineered the entire feature himself in his spare time and we got design help from the wonderful people at MeasureMap that Google had recently acquired/conscripted/enslaved.

3. Reading styles for feeds are pre-established and generally inflexible.

On this point I'm relying on data that is attainable at Google because of size and market dominance as well as having routine user studies and follow-up. So because of this data I'm making an assertion that there is something inherently different about the inflexibility of feed reading styles than compared with other software. It's something borne out in every user test we've ever had and by Reader's development and seems worth academic inquiry at some point.*

People of all stripes including those who've used feed readers, those who haven't, as well as those who understand the underlying architecture and those who don't all seem to have a pre-determined reading style that they find incredibly difficult to change.

The persistence of inflexibility is a little strange. There are many times when people can adapt to software experiences that don't match their expectation so long as they're still strongly identified as useful. You can probably imagine some personal examples.

However, in Reader changing a reading style is often very difficult. People can see the usefulness of opposing views ("Oh, I can see how a list view makes sense") and not change whatsoever ("Yeah, I could NEVER EVER use that") Generally, I've come to believe that people will not use a feed reader if it does not exactly accommodate their reading style. I readily concede that inflexibility in reading styles may only be a problem local to Reader though I suspect a new feed reader may encounter the same behavior. This is possibly due to the ease of switching to services which highlight the specific style the user prefers. Subscription data is portable and there are many simple instructions on how to move from service to service.

Additionally, it's my suspicion that secondary markets for re-feeding may not encounter this limitation. If the emphasis is on communication or collaboration in a re-feeder then what's normative for consumption might (very happily) be unrelated to a person's feed reading style. Dunno yet. It's an exciting time to find out, though.

I'm really hoping that someday an ethnographer studies feed reading styles. There's something very interesting happening here.

4. Content that is perceived to be most valuable is not currently available in feeds.

This problem keeps me awake at nights.

In every user study involving people who've never used a feed reader the lack of full information for the feed they attempted to look at first was a big turnoff for them using a feed reader.

What concerns me is this: people often want the results of well-known media but much of this is still either firewalled or put behind partial feeds which make the feed reading experience less compelling generally. I can understand why publishers feel they should do this since the expenses for a lot of journalism and media creation aren't small and they can't perceive how this would help them make money. They need a solution to this right now - their industry is facing tough challenges.

I don't want the enterprise of efficient, elegant syndication on the web to sit on the sidelines while good resources in investigative journalism bleed out. (Seriously, it looks like they're bleeding out.) And the feed reading space is growing rapidly. There has to be a way for all of us in the feed community to help.

One view of Reader user growth from inception, anonymized. You shouldn't draw too much from this other than "oh, that space is still growing a lot."

5. Just one more thing

Just wanted to mention that none of the above principles explicitly mention using a social network to help filter feed information. It's obviously important. We've always thought so - Shellen especially - and so our earliest demos of Reader years ago all included sharing with friends. Maybe that should graduate to be a core principle of making feed-consumptive software. Five firsts?

* All of the following seem true generally but have been especially true for Google Reader:
- Many people need to see all of an item's content to determine whether to read it in a feed reader. If they can't they won't use it.

- Many people need to only be shown an item's title to determine whether to read it in a feed reader. If they can't they won't use it.

- Many people require being able to see unread counts by source when using a feed reader. If they can't they won't use it.

- Many people require sorting items by newest when using a feed reader. If they can't they won't use it.

- Many people require sorting items by oldest when using a feed reader. If they can't they won't use it.

- Many people require tagging of items when using a feed reader. If they can't they won't use it.

- Many people require offline access when using a feed reader. If they can't they won't use it.

- Many people require keyboard shortcuts when using a feed reader. If they can't they won't use it.

- Many people require excellent mouse targets for common tasks when using a feed reader. If they can't they won't use it.

- Many people require content available on their phone via their feed reader. If they can't have it they won't use it.
posted at June 11, 2008, 10:02 AM


  • At 1:24 PM, Blogger Mark said…

    Hi Chris,

    First - congrats. Reader is a very pleasant feed-reading experience.

    However, it always struck me that it has one glaring omission. It's in the "If I can't I won't use it" catagory, except that no other feed reader offers it either.
    Reader really needs to do item recommendations! Instead of me having to scan the thousands of unread items that inevitably build up in order to find the interesting ones, Reader should do it for me. There are loads of signals you could use:

    Other Reader users. How many people:
    -Read it
    -Starred it
    -Shared it / emailed it
    -Clicked through to the post

    -my reading history
    -my Google search history.

    Post itself:
    -How many links does it have?
    -How many comments?

    Kind of like an implicit Digg, but with better data, and only for the things I'm interested in.

    The number of hours this would save me and other heavy feed users is uncountable. I have thought about building it myself several times, but I always figured you guys must be just about to do it. You have such lovely data. Come on - Do a little magic with it!

  • At 3:02 PM, Anonymous Edwin Khodabakchian said…

    Awesome post!

  • At 11:08 PM, OpenID The Insomniac said…

    Thanks for all the insights. Google Reader is my favorite webapp.

    Im going to go thru and read all the 'birth of' posts

    I did not realise how many feeds/items I was reading till I noticed the Trends feature.

    I was well over 2000items/day at one point, But I have been slowly weeding it down to a more manageable 500-700 using AideRSS and the like

  • At 7:58 AM, Anonymous Anonymous said…

    This is one of the most interesting and potentially useful things I've read on communications bottlenecks in some time. Thanks for doing this.

    Alan Metrick Communications
    New York

  • At 4:22 PM, Anonymous Mr. Gunn said…

    You're dead on regarding the inflexibility in reading styles. I tried every piece of desktop software and every webapp out there before settling on the one I use, and I just can't stand the others. This is probably due to the purpose of a feed reader - to collect a whole bunch of information in one spot and allow you to rapidly scan through it. Small changes that slow you down make a big difference.

    I particularly don't like Google Reader, but no offense, I just don't like web apps for this. Although sharing is easier, I feel like they slow me down too much.

  • At 12:06 PM, OpenID MattK said…

    Hi Chris - thanks a million for google reader. I found your post from your comment on Marginal Revolution, which I found through my google reader.

    I wish there was more support of exposing and exchanging attention data or using OPML. Currently you support importing OPML, or exporting a file. One thing I really liked about bloglines is that it had a URL where I could publicly expose my OPML for use by other gadgets and whatnot. And when folks have publicly exposed OPML, it would be nice if I could delegate a subsection of their public opml url as a subsection of my opml.

    That way when a trusted expert begins tracking more blogs on a subject I could automatically see that and get the same information.


Post a Comment