Google still has the best feed reader

Yes, we all know Google Reader was shut down for good on July 2 of last year.   It's creators went on to do great things, and are still at it.  Users had an emotional attachment to Google Reader; it was the best for those that understood RSS. Many were upset at its sunsetting.  That's well known.

What's less well known is that Google is rebuilding a smarter newsreader, from the consumer point of view.   What I don't understand is where it is hidden: inside the Google Play Library under "My News".  For the last year, I thought this was a place for Google to sell magazines to compete with the quite weak iOS Newstand, so I never ventured into Play News.

But yesterday, I actually wanted to buy a digital copy of a magazine (hard to believe I know) - and discovered that Play News is so much more than a digital magazine stand.   It's a news reader with a feed reader underneath.

In fact, they do a pretty good job of mixing both together.  But just as a basic newsreader it's pretty damn good.

You can navigate to the publications you like, and this part is genius, it will auto promote the publisher's mobile app if it appears in the Play store.    Little golf claps for the PM at Google who created this feature.

And underneath, yes there is a feed reader.   In fact, here's how this blog looks inside of My News:

So yes, RIP Google Reader, but let's hope Play News combined with the news that appears in Google Now can fill the void.    Google has always been good at creating relevant news products, they've just been really poor at marketing them.  Let's hope this incarnation stays alive.

Update:  This app is actually called "Play Newstand" and does have it's own icon in Android if you dig into all your apps.

I didn't correct my flawed name uses above to underscore Google's lack of branding.   Getting the name to dsiplay without an ellipsis as "Play News..." isn't easy.

Engaging your users with email

I forgot to mention in my quick thoughts on Summify, but was reminded by a user comment, that one of the things I liked about Summify is that they send you an email digest every day of some of the more interesting items in your stream.  I'm secretly glad I forgot, as it's worth another mentioning in a separate post.

I think in the past, too many newsreaders made the mistake of thinking "my users don't want this via email, that's why this application exists" and although that might be true for a subset of users, it certainly isn't true for everyone.

To make an obvious statement, people use different media differently.   That is, the frequency in which someone checks email is different than the frequency in which they read their Twitter stream  ( I certainly know people who check Twitter more than they check email, and I've had DM or Facebook message conversations that have replaced email - but that's not really the point).  I think generally users need to be able to decide which media alerts are interrupt driven, and which ones are meant for background occasional browsing.

For certain applications that are vying for your attention, I think engaging your users via email to spur a return to your application on an clear opt-out basis has become totally acceptable, and for me anyway, is generally preferred.   Twitter and Facebook have largely paved the way for making this the de-facto method, by alerting you via email when there are new followers or friends, or Direct Messages, and allowing you to opt-out if you don't want them. I probably wouldn't know about any of this activity if it weren't delivered by email.  I certainly wouldn't want this info delivered as a tweet itself for the Twitter examples, anyway.

Twitter notification by email

I don't think it was always this way.  It used to be considered a bit spammy to make an application email it's users without consent, but I think it's become somewhat accepted, again, as long as there is a clear opt-out of "I don't ever want to get this email again" right in the first email.

Many applications have taken the same tack with iPhone push notifications, and that's something I don't like.   I really don't want my phone beeping every time someone writes on my Facebook wall, but if I remember correctly, this is the default behavior.

The general point here is, think carefully about how to drive continued engagement with your users, and although with any notification medium you will always walk a thin line between engagement and being spammy, don't be afraid of email.  It's still the primary way most people communicate.

Quick thoughts on Summify, a simple and fast social news aggregator

Continuing the thread here of next generation of content readers, I wanted to give some brief thoughts on Summify, and browser-based newsreader that promises to algorithmically "cure your unread item guilt" by presenting you stories posted by your social networks in Twitter and Facebook, as well as meshing in your subscriptions from Google Reader.

Now, "unread item guilt" is something I never had.  I was always happy consuming feeds on the come, never being the least bit anxious about the bold black type on the left of my browser window.  But I can assure you this is not the norm.  At FeedBurner, we spent a whole lotta time making sure in the course of processing billions of feed items that we never mistakenly changed an item in a way that would mark it "unread" again in the thousands of different feed readers that calculated what made an item changed in various different ways.

There really are two types of people in the world, those who care about the unread count in their newsreaders and sane people, and although I'm kidding, anyone who subscribes to more than 100 feeds or follows more than 100 accounts on Twitter just is not going to get to read all the items that come in from that stream.

Summify tries to solve this by looking at both your items and your contacts (or friends) and presenting you a river of news, ranking on thinks like number of retweets, facebook likes and shares, and direct shares from your contact list.

It's still in private beta, so I'm guessing they haven't hit any scaling walls yet, but as of right now, the UI is very snappy and useable in a way that many ajax-heavy UIs are not, which is encouraging.

Where I've recently talked a lot about how twitter is protocol with a payload, and that we're going to start seeing a new crop of news readers that unpack this payload, Summify falls squarely into this category.   Much like Twitter for iPad, Summify unpacks short URLs in Twitter and displays a parsed version of the destination web page (or perhaps matches the content from the feed, I can't really tell) right inside Summify application.

In fact, if you only connect Summify to your Twitter account, I find it slightly more useful than #newtwitter for browsing content.

Although you can connect Summify to Google Reader and have it pull in your subscriptions from Google Reader, I don't recommend doing this right now, simply because there currently is no way to undo this.  There's a pane that clearly says this is coming soon, but if you have hundreds of feeds in Google Reader like I do, these feeds will soon overrun your Twitter stream, and frankly doesn't add a lot over using Google Reader by itself in the "Recommended Items" view.

In short though, I really like the direction Summify is going here, mostly because it's simple, useful, and fast. I think they should keep it that way and spend a lot of time keeping it fast as they scale. If it stays simple, stays useful, and stays fast, I can see this being a go to browser UI for news reading.

Why Flipboard and Twitter for iPad are profoundly significant

I think Flipboard is absolutely fantastic. Every day when I pick up my iPad, it's continually the application I always look at first. Previously, and before the release of Flipboard, I wrote about how news on the iPad was innovating on presentation and Flipboard does this and more at a personalized level.

Yesterday, Twitter released the newest rev of their iOS client, Twitter for iPad, which also does a lot of innovative things, while still keeping the feel of a "traditional" Twitter client.  I doubt I'll be picking up my iPad much without spending a few minutes inside the app.

But Flipboard and Twitter have done something else more profound that may not be obvious to the average user:

1. The apps reinforce something that I've thought for a long time, that Twitter is really just a protocol; a 140 character packet with a payload.  It will eventually get pushed down the stack just like RSS has been, becoming the infrastructure that exists for publishers to connect with subscribers .
2. These apps highlight some of the differences between the Twitter/Social ecosystem and the RSS/feed reading ecosystem, the largest one being that in the RSS ecosystem, the publisher was king, but in the Twitter ecosystem, the user is king.  

Let me explain a little more what I mean by these statements.

To the large majority of Twitter's users, the platform is an ego based application that allows them to broadcast to the world what they are thinking right now.  The interact directly in the bounds of the medium which is a 140 character text message.  For a large number of users, they interact directly with this 140 character message at one level above the protocol level, that is, an application that reads and displays those 140 characters.

Now, this isn't that much difference than how RSS was traditionally used, except this 140 character limit doesn't exist in RSS.  You can put as much content as you want in an RSS message.  However,  users of RSS rarely interacted directly with the protocol at on the publishing side, though they certainly did on the subscriber side, that is an RSS reader that pretty much displayed the content of the RSS description field. On the publishing side, users usually use a blogging platform to create content, and this is reformatted as RSS usually through some type of software adaptor in the blogging platform.

Now, because of this 140 character limit in Twitter, developers quickly figured out how to encode the same types of content that they might have with a blogging platform, that is in a URL, and more specifically a shortened URL to allow for as much text metadata along with that message as possible.  This made it possible for "publishers" - those sites like New York Times and  mega-bloggers like Techcrunch to also distribute stories using Twitter, again, encoded in a shortened URL.

The Twitter web client, with encoded URLs

However, for users acting directly at the protocol level, this is a bit of messy experience.  You essentially have to leave the application by clicking on the embedded URL, and let your browser go somewhere else to decode the content of the message.  If I learned anything from working with millions of RSS users over the last few years:  they will leave their reading application if they have to, but they generally don't like to. 

Brizzly Twitter client, showing destination URLs

Brizzly, pictured above, was one of the first clients to start to "unpack" these shortened URLs and show the user where they might go by displaying destination URLs, and in cases of photos, even go fetch and embed those photos.  [disclosure: I am an investor in ThingLabs, which makes Brizzly]

Flipboard

Twitter for iPad

Flipboard and Twitter for iPad take this a bit further, by actually fetching and displaying the encoded content encoded in the shortened URL in the large majority of the cases.

Suddenly, as a user, you aren't interacting at the protocol level at all, but interacting with the content that the original publisher wanted you to interact with, all without leaving the application in which the user is consuming the content.  These applications, though the presentation is certainly prettier, are starting to have a lot in common with popular RSS readers, but are also doing a lot more just as a function of the application platforms that allow some richer experiences.

But there's something more profound going on here - and why the Twitter ecosystem is different from the RSS ecosystem is that we've seen a fundamental shift from the publisher being in control to the user and the delivery platform being in control.

In the RSS ecosystem, if a publisher wanted their content to be displayed in 140 character chunks (and many did and still do through partial feeds) that was the way it had to be displayed.  There were feed readers that tried to go fetch and essentially "unpack" this content, but when they did, publishers screamed bloody murder that these feed readers were "stealing" their content.   If a feed reader tried to monetize themselves without giving the publisher a cut, again, publishers generally tried to make sure these feed readers failed.   You wouldn't believe the number of publishers that constantly asked FeedBurner to provide a way for them to block their content from being delivered to specific feed readers, because they didn't like the way it displayed their content.  The publisher was king and the ecosystem generally listened.

In the Twitter ecosystem, this type of sentiment has never really been allowed to exist, possibly because usage reached the tipping point before publishers realized they absolutely had to distribute via Twitter to even continue to be viable.  Twitter is going to monetize the timeline, the publishers aren't going to share that revenue, and I don't think that is going to change.  Twitter apps and clients are going to monetize outside and around the timeline and I don't think that is going to change. Twitter is going to start encoding all your URLs so that they have the data on all your distribution, and I don't think that is going to change.  They'll be in the position to provide this data to publishers, but have no obligation to do so.  

Now, Twitter for iPad bringing in the entire page of publisher content, so the publisher is going to get ad impressions (see the ads in the FourFourTwo page above) in addition to distribution in that case.  Publishers are still getting the distribution they were hoping for, even if it is no longer a "click" back to their site from the timeline.

But for sure, Flipboard is not just displaying the content that exists in the the Twitter 140 character format, and is "scraping" the content and redisplaying it.  They're still showing the protocol level message, but then the content (though not always full) and the conversation around it.  I think publishers will see that applications like this are scraping their content and using it, but I don't think in this ecosystem there's a damn thing they can do about it.  Sure, they can stop publishing via Twitter.  Good luck with that.  

All the smart publishers will realize it's actually better for them to have more users engaging with their content, wherever it may be, than not engaging at all.

For the user, this is fantastic.  When you marry this with a similar view of content from Facebook, arbitrary feeds, and other aggregated content sources - it's exactly what I want as a user.  I can, for the most part, stay in my aggregator application and experience the real time stream in a way that totally makes sense.

If I've learned one thing from working at Google from combing through mounds of data that my job entails - when the user is king on a popular platform, the platform on which those users operate wins.  The scale of internet users is always greater than the number of publishers, so when you can start adding users at exponentially high numbers you can never extract the underlying platform, for myriad reasons too long to list here.

My prediction is that while Flipboard was certainly one of the first to take this step of scraping and stitching together content, they certainly will not be the last.  I think you are going to see a whole crop of innovative clients sprout up here that take advantage of what the Twitter (and other social media) ecosystem allows for.  It will reach a tipping point before the traditional publishers are able to object, even though I can tell you that from all the data I have seen in the last five years, they shouldn't.  More distribution means more net page views which means more revenue.

In fact, as I push the "Publish" button here in Blogger, this content is going to go within seconds to PubsubHubub to FeedBurner to FeedBurner Socialize to Twitter  (and Google Reader and thousands of other places) and then guess where - right back to the page on where this content is hosted.  It won't all come back here, but my analytics tools will show me that's okay, especially for a small fry publisher like myself.