Massless

Four Firsts for Feeds

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 "google.com/reader/lens" 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