Last active

Embed URL

HTTPS clone URL

SSH clone URL

You can clone with HTTPS or SSH.

Download Gist

Open content linking proposal

View contents.markdown

On linking content across varying media

A brief history of hypertext documents

Many of the technologies being built today are based on the ideas initially conceived by post-World War II scientists. In fact, it was in July of 1945, when Dr. Vannevar Bush described the "memex" device, a device with an uncanny resemblance to the Internet:

A memex is a device in which an individual stores all his books, records, and communications, and which is mechanized so that it may be consulted with exceeding speed and flexibility.

Only twenty years later in 1965, Ted Nelson, inspired by the same Dr. Bush, would conceive of the idea that content and documents should be "hyperlinked". And finally in 1990, Tim Berners-Lee along with some of his colleagues, would tie the concept of the hyperlink together with the idea of an inter-connected world to develop what we know now today as the Internet, allowing humankind to access and link information across vast distances almost instantly.

The disconnected webs

In the past few decades, a new medium has emerged thanks to this incredibly rapid evolution: the portable Internet-connected device. Now, not only can you access the entirety of the Internet from a handheld device, but the very nature of the device has further manifested itself in how we consume and interact with the available content. Locality-aware social networks, augmented reality, GPS navigation, and plenty of other forms of interaction would have had little to no place in our lives without this technology. In short, this further proliferation of Internet-connectivity has not only shaped the the medium through which content is consumed but also has changed the nature of the content itself.

However, despite (or perhaps because of) the rapid spread of Internet-connected mobile devices, today, we have no appropriate means of accessing and sharing the world's content across devices.

Surely, on a desktop computer or a portable device, a URL will allow access to content through a web browser, but this is can in many cases be inappropriate for a mobile device (due to insufficient mobile bandwidth, lack of viewport optimization, etc). Conversely, a deeplink will allow access to content in a mobile application, but this is inappropriate both for desktop users and for mobile users without the application installed. This greatly reduces the usability of a URL or deeplink to identify and resolve the location of content being requested by a user agent.

Only to exacerbate the problem, a user with multiple connected devices arguably will be using a different device at different times. This gives rise to some unfortunate consequences:

  • A friend who posts a link to a news article cannot guarantee that friends will be able to read the content of the article
  • A marketer cannot guarantee that sending and email with a link to a product or sale will be fully accessible by a list of users
  • I cannot guarantee that my partner will be able to open the Yelp link to our favorite restaurant.

Furthermore, for plain-old websites, there are plenty of web crawlers out there that crawl links and index the resulting content for efficient and relevant retrieval by search engines (think Google's Googlebot or Microsoft's Bingbot). But, the lack of accessibility of the content in mobile applications artificially forms barriers between related content: you can no longer link from one piece of content to another reliably. As a result, the content surfaced in mobile applications are almost entirely invisible to these such crawlers, and thus the web users or mobile users without the application cannot search or view the requested content.

A proposal to bridge the gap

The key to reconciling this division between the content available on the web and the content available in mobile applications is simple: place a <link> tag on your web pages for designating an alternate location to the appropriate content for a specific device type. We have chosen this HTML tag for this purpose because the W3's very own definition of the <link> element states quite clearly that it has particular use for search engines, such as for providing the location of an alternate version of a document which may be made specifically for different kinds of media. So to start out, we will use a tag to define an alternate location for our content:

<link rel="alternate"/>

To further refine the scope of our tag to target a particular device, content authors may also make use of the media attribute to limit the relation of an external resource to only those user-agents under which the media query applies. Additionally, we will define a new media feature, namely os, with the possible values ios or android to target more precisely those user-agents which run on the Android OS vs. iOS, respectively:

<link rel="alternate" media="only screen and (os: android)"/>

And in fact, we see similarly targeted uses of the <link> tag today for representing alternate content for mobile devices, such as on eBay's website:

<link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.ebay.com/itm/Authentic-Samsung-Gear-Fit-Fitness-Tracker-Black-Watch-for-Galaxy-S5-SV-New-/331172291638" >

So how do we make our tag work for native mobile applications? Quite simply by using a special form of a mobile deeplink in the href attribute. This form of the deeplink also aligns precisely with Google’s suggestions for its app indexing initiative, with a small modification to include iOS:

android-app://{package_id}/{scheme}/{host_path}

OR

ios-app://{app_id}/{scheme}/{host_path}

So now our tag should look something like:

<!-- Android user-agents should find this content at the deeplink location: my-app://page/12345 -->
<link rel="alternate" media="only screen and (os: android)" href="android-app://com.my.app/my-app/page/12345"/>
<!-- iOS user-agents should find this content at the deeplink location: my-app://page/12345 -->
<link rel="alternate" media="only screen and (os: ios)" href="ios-app://com.my.app/my-app/page/12345"/>

Standardizing around the above approach, you can be both backward-compatible with Google's app indexing in addition to being forward-compatible with future technologies and devices.

Roadmap to adoption

In order to harbor enough support and adoption for this proposed standard the engineering team at URX has built a free service to turn normal hyperlinks into "omnilinks" for those sites which have implemented this standard. This effectively means that your website and mobile application can benefit from being accessible and linkable across various devices today by simply adding urx.io/ in front of an existing link. For example, urx.io/open.spotify.com/artist/7Jdjjb3kJWyPmV5MbdVdTv, allows Spotify's content to be accessible from a desktop PC, an iPhone/iPad, or an Android device.

It is our intention to gain traction for this proposal by:

  • Opening up our omnilinks service for everyone and anyone to use freely
  • Get early implementations included in major browsers
  • Get backing from search engines such as Google and Bing

We hope that someday soon, both the simplicity of this proposal combined with the forward-compatibility offered by omnilinks will harbor enough adoption for this proposal to become part of a broader standard for linking open content across various media.

We’re open for discussion and collaboration

First off, we would love to hear what you think about our proposal! Please feel free to post your question/comments/suggestions/criticisms using the public comments section below.

For a more in-depth conversation with the URX team regarding our efforts with this proposed standard, please send us an email at omnilinks-wg@urx.com.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.