Search

Custom Search

Thursday, September 02, 2010

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.

8 comments:

jvaleski said...

great post!

one could argue though that row-based readers (RSS/Twitter) were simply too lazy to do what was obvious from the start (reveal the layers of underlying content), and it's, sadly, taken this long for things to come back ground to graphical UI/display.

no matter how you slice it, I'm glad the layered graphical experience is coming back. reading RSS/Twitter is fun again with this "new" metaphor.

flipboard motivated me to buy another iPad. I thought that was interesting.

Srikar D said...

This is great post! I really liked reading this and your analysis is absolutely amazing.

chatnsearch said...

There are also web based twitter readers that upack and show a preview of URL's. See http://www.rollingtweets.com/

Chris Myles said...

Just to clarify Blogger does NOT use PSHB to get to feedburner, it is a special cased solution for Blogger (other Google employees have made the same mistake). I use posterous (which is PSHB enabled) but feedburner is delayed because of it's lack of PSHB support on input (it still polls).

AND currently Google Buzz makes it impossible to track analytics within gmail/Buzz as https isn't supported and Buzz posts (via profile tab) stats aren't propagated to the original source. The only tracking solution is to use Feedburner's summary burner to force a click through (in Buzz) which defeats the purpose/advantage of full feeds for the user.

A successful tool should benefit both the user and the publisher.

Unknown said...

Actually, @SV Billabong, FeedBurner does fully support Pubsubhubub as both a publisher and a subscriber, and in this case, it is the fact that the hub (and blogsearch) is being pinged by Blogger that causes an immediate fetch by FeedBurner.

Your analysis of why Buzz activity doesn't show up in analtyics products, is correct, however.

Chris Myles said...

Steve,

Check out this posts comments (including Rick Klau and Dewitt Clinton).

Did something change recently (since June)? I'm still seeing delays between posterous post and feedburner pickup (over 10 minutes now) that I didn't see with Blogger. Other people have similar (non-posterous but PSHB) complaints.

Unknown said...

Yes, I'll let DeWitt know, but FeedBurner is definitely both a subscriber and a publisher. He mentioned that in February and the work was done some time right after that.

As far as posterous, I'm trying it out, but I'm guessing they are pinging with the wrong feed address.

Chris Myles said...

Steve,

Thanks for checking (didn't mean to steal the comments).

I am a HUGE fan of full content but a better product balance is achieved when both the user and publisher are happy. The trend you describe is sure to continue. I've never played directly with the iPad but did hack together something similar for my own use.

Now if only we could integrate Salmon to keep the comments/conversation flowing.. it would be perfect :)

Thanks again

-Chris

LinkWithin

Related Posts with Thumbnails