Embeds, content and context

As a publisher you have 2 choices. You can either bring the people to your content or you can find ways for your content to flow towards the people. Historically that has meant using syndication technologies like RSS but in these days of #PeakRSS that's no longer sufficient. The audience are no longer just sitting in front of their aggregators. They're sitting in front of activity streams watching reshares and hitting reload on their favourite websites every morning.

To maximise the reach of your content you have to reduce the accidental friction (see Brooks on the difference between essential and accidental properties) involved in sharing to those activity streams. That means making it easy to share (hence the sharing buttons all over the web), making it clear why they should share (hence the various experiments encouraging you to share or tweet specific quotes from an article) and finally making the shareable unit something that can travel easily around the web.

This is where embeds come in. An embed is a card that contains a chunk of a site's functionality that can be ripped out of that site and reused elsewhere.

http://parochialaesthetics.tumblr.com/post/148169494570/eliel-saarinen-always-design-things-by-context

This can range from music players (like Soundcloud) to video players (like YouTube) to quotes (like Twitter) to whole discussion threads (like Google+). What distinguishes them from glorified screenshots or Xanadu's transclusions is their interactivity. Visitors to your site can interact with this foreign content without abandoning your site.

But isn't this what links are supposed to do? Unfortunately inline links have various problems:

• they take the user away from your site
• they break silently
• the content at the destination has to be consumed without the context provided by your site
• the destination can't provide guarantees about the experience your audience will receive and thus you can't set reliably expectations for anyone who clicks on the link

Embeds don't have these problems. They:

• keep the user on your site
• break in ways that are immediately visible
• are consumed in the context provided by your site
• can be constrained to a tiny card with a predictable UX within your site 

Embeds also represent a chance for publishers to change social media from something where your campaigns/integrations send traffic to someone else's site to something that delivers measurable value (traffic and revenue) to you. The most valuable embeds:

• convert your social efforts into traffic on your site 
• help you keep people engaged with your site
• help you increase the reach of your content
• help you use other people's content to enrich your site

Ultimately publishers will realise that embeds are just the first generation of portable content unit and they have their own limits. There will be other generations and they can offer different trade-offs.

Minimum-viable identity provider

What's required in a minimum-viable IDP (Identity Provider) in 2013?

When I talk about viability I really mean "competitiveness" and I suppose what I'm really asking is what does it take to get RPs (Relying Parties) to integrate and users to authenticate with an IDP?

The list of requirements below was first published in a presentation I gave at Over The Air 2013. It's the result of hundreds of conversations with RPs and user over the last few years.


Valuable accounts. Are the accounts attached to real people who have been SMS verified? Does the IDP fight off attempts to create fake and spammy accounts?

Security. Are the accounts stored using salting and hashing? Do users authenticate using multiple factors? Are precautions being taken to ensure that user accounts are protected?

Rich profiles. Does the IDP offer data that you can use to personalise your service such as profile data, photos and social/interest graphs?

Ubiquitous APIs. Does the IDP offer ReSTful APIs, native SDKs, client libraries in various languages and support for RTL languages?

Escape hatches. Does the IDP lock-in RPs and/or users? Can the RP obtain the user's verified email address so that the user has the option of using a different IDP with the same RP account? Is the RP forced to build their own post-registration flow?

Business model. Does the IDP make money or otherwise benefit from providing this service? Do they have a compelling incentive to stay in this business?

The final and most controversial ingredient is scale. Most people would say that all other things being equal an IDP with more accounts is better than an IDP with fewer accounts. I'd suggest that it's better to have accounts that are appropriate to the service the RP is trying to provide. For instance for Statigram the best IDP is Instagram but for Favstar.fm the best IDP is Twitter and, of course, for any service that uses Google services (like Youtube, Android, Drive, etc) the best IDP is Google+.

The items listed above are just the necessary but not sufficient features of a viable IDP. Successful IDPs will still have to identify and provide additional value in order to get widespread adoption by users and RPs.

The other side of creating more value than you capture

+Tim O'Reilly likes to talk about "creating more value than you capture." The obvious logical alternative to this is "capture more value than you create."

However I suspect that this is a false dichotomy.  I think we've missed something. It's possible for a vendor to create more value than they capture and yet, by building a new network, ensure that the surplus value eventually flows back to them. This ends up primarily magnifying the value of their network rather than the wider web. 

For instance a post on Tumblr is easier to reblog, if you have a Tumblr account, than to re-post elsewhere. It's easier to 'follow' a tumblr than to subscribe to the RSS/Atom feed for that same tumblr. Tumblr's bookmarklet makes sharing to your tumblr easier than cutting and pasting it elsewhere.  By building proprietary solutions that have a better user experience than the open solutions, Tumblr created a situation where sensible people act in ways that keep them inside the Tumblr network. This is more like a gated community than a walled garden precisely because the members of this network made an informed choice and are happy with the consequences of being inside it.

The hidden assumption in Tim O'Reilly's thinking was that the network that would primarily benefit from all this surplus value was the web. But it turns out that large social networks and large blogging networks and other sites that host large numbers of activity streams are the primary beneficiaries. We can see this in Tim O'Reilly's examples from his original presentation which primarily focusses on Twitter and the benefits for Twitter users. At the time making a distinction between Twitter and the wider web would have seemed nonsensical. 

Today we realise that creators go where they can reap value and that's increasingly in networks (like Twitter, Tumblr, LinkedIn's Influencer platform, Google+, Medium, Instagram, etc) which can help them easily discover a community that cares deeply about their creations. We also realise that the necessary walls (which take the form of privacy controls and API restrictions) between these networks and the wider web means the networks can benefit from Reed's Law and grow their value in proportion to the number of such communities that are formed rather than just the number of users. 

Every creator and their audience forms a new community where value can be created and captured. Some of these communities may even be generative. They may be creating more value than they capture. So where is that value flowing?

If you own a network where people create more value than they capture then most of that surplus value flows to you rather than to the wider web. The challenge for the owners of these networks is to invest that surplus value back into the wider web in the hope that they'll reap even more surplus value in the future. The challenge for those who believe in the virtues of the wider web is to show these network owners how they can contribute to and benefit from the wider web.