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.

Guide to implementing App Linking on Android 6.0 Marshmallow

Android Marshmallow has a feature that can make life better for developers who feel that their app experience is better than their web experience. It's called App Linking and it ensures that your app always handles links for your domain without the disambiguation dialog you would normally see. 
The feature is called App Linking but the connection between the app and the web site is called an App Link. And, in case you're wondering, it's unrelated to Facebook's AppLinks.org initiative.

This is a short guide to implementing and testing the feature. Let's start.

1. Go through your manifest and identify the domains (and subdomains) your app claims to be able to support.
2. Add an assetlinks.json file pointing to your app (or apps) to each of these domains or subdomains. If there's a domain or subdomain that you don't control then the verification process will fail. You can either remove that host from your manifest or you can remove the CATEGORY_BROWSABLE category from the manifest as this will have the same effect: your app won't intercept request for other people's domains or subdomains.
3. Make sure you serve the assetlinks.json file over HTTPS on every domain or subdomain that you support. Your entire site doesn't have to support HTTPS. Serving just the assetlinks.json file over HTTPS will suffice.
4. Make sure the assetlinks.json file is served with content-type “application/json” since it won’t work with any other content type.
5. As documented here you should use our debugging tool to verify that each domain or subdomain has a valid assetlinks.json file. Here's an example for one of my sites.

If everything works you should see a message like this:
Add an autoVerify attribute to the intents in your manifest for each of these domains.
Be aware that the verifier doesn't follow redirects so it won't work if you try to shortcut this by having one canonical file that all the other URLs redirect towards. You can find more details about the install-time verification process by reading this excellent but now outdated guide from Christopher Orr.

Don't forget that all of these files must match exactly so if you update one of them you must update all of them. Fortunately the SHA256 in the assetlinks.json is based on your app's private keys so once you've added your release and debug keys you should never need to change it.

Between this guide and the official documentation you now know everything you need to make App Linking work on Android Marshmallow. If you still have any questions then ask on Stack Overflow using the tag: android-app-linking.