I believe that part of the problem is that links do not work so well for that initial intent; and that is (IMHO) because of the coarse granularity of that that can be linked; while theoretically you can link to anything with a URI, effectively they usually just point to documents and anchors of some of their parts. And that capability must be provided by the author, so, as the problems with the semantic web, most of the authors do not have incentives. So you are precluded from slicing and dicing content from others and, as Ted Nelson wanted, transcluding that part of another person's train of thought into your own document.
So we repurposed the "link" tool to just navigation.
Perhaps if we could add linkable annotations on pages of other people then we could play easier with other people's ideas...
That idea went out the door with all the things that Web 2.0 brought. Even news articles, one of the most stable page sources I can think of, periodically receive updates that would render such a concept invalid. The concept of "slicing and dicing" with static links is simply not compatible with an Internet where pages can change content at any time. And I personally think that what we gained is worth a lot more.
Partially unrelated to both meanings of "deep link" the author identifies, the term is very much used today in the world of affilliate marketing.
If you have a blog and want to send your reader directly to a specific product on a ecommerce store, you create a "deeplink". A link, directly to a product page, containing your affiliate id and all the stuff that the Affiliate Network tracks.
That is the standard meaning, and is identified in the article: "bypass a site’s home page, whisking you straight to some specific location or product"
(It would still be a deep link without the affiliate tracking info.)
The narrative in this post doesn't jive with my experience. Deep links on the web have been deep links on the web for a long time, nobody ever forgot about them. "Mobile deep linking" is the phrase that belongs in quotation marks, as it is a new and confusing appropriation of the phrase "deep link" to extend beyond the web into native (non-web) mobile apps. To anyone paying attention to trends in the web and in non-web apps, the conclusion that "mobile deep links" (perhaps "app links" is more descriptive, but it seems to have been taken by a specific implementation [0]) will never deliver on the promise of the web is obvious.
Unfortunately, gatekeepers make rich content impossible on the mobile web. For example, when will Apple support WebRTC in mobile Safari? Until then, certain interactive content requires an app, yet we still may want to address this content with these links.
Fucking Apple hasn't announced support for HTTP/2 yet either. Considering the biggest bonus is decreased latency which is huge for mobile, they are clearly just pushing developers to apps because that's their business.
Unfortunately mobile web pages can't run background processes, can't launch AJAX requests to arbitrary domains, speak UDP, do file I/O, and numerous other things, which is why people end up writing apps.
Also mobile web browsers still suck, unfortunately. Safari still hasn't gotten its act together with simple stings like scrolling, and is riddled with CSS bugs of sorts if you try to do anything advanced with HTML5 (e.g. pull to refresh, swipe gestures). It's almost like Apple is deliberately refusing.
Unfortunately mobile web pages can't run background processes, can't launch AJAX requests to arbitrary domains, speak UDP, do file I/O
Background processes, cross-domain AJAX and file I/O actually are possible now, at least to certain extents. It's getting a lot better, but as you say, Apple drag their feet at every opportunity.
I'm far from an Apple fan, but this statement is so intellectually lazy I have to counter it. The honest fact is that 30% of zero is zero. If having a webpage would be an option, it's overwhelmingly likely that the webpage would be free to access. And if an app is simply a more enabled replacement for the webpage, then the app is also overwhelmingly likely to be free.
To some extent, sure, but not enough. With an app I can open a TCP connection to any address and fake any referrer I want, and I can use a WebView to open any page regardless of the X-Frame-Options header which iframes cannot do. Hence, I have to write an app instead of a webpage for a lot of these requirements.
Also, HTML5 location tracking is severely broken on iOS. In most cases the user ends up inadvertently blocking permissions for Safari rather than on a per-website basis. The result then is that all future websites get blocked from location access automatically, without even prompting the user.
If HTML5 apps are to take off, the web browser needs to be treated as a basic component of the OS and automatically given full access to location tracking and sensors; it should then be the web browsers' responsibility to ask and confirm with each website and manage those permissions (perhaps even seamlessly integrated with the OS permission system itself).
IMHO the restrictions on HTML5 apps like cross-domain requests and iframes are quite silly. At least there should be a one-click way to "trust" websites in the same way you'd install an app.
Deep linking between apps on Android almost works for the kind of apps that are really just specialized browsers. For example if I am in a Reddit app and click a link to an HN comment thread, it can open the thread in the HN app. In practice it may fail for various reasons:
* The HN app has no registered to be opened for HN URLs.
* The HN app opens, but ignores the URL and just shows the front page.
* The Reddit app is using a built-in browser that does not (or cannot) check URL hooks for other apps.
For app developers, deep linking works perfectly in Android. It doesn't work 100% for end users because of the problems you listed, but reading this article is hilarious because Android has had this functionality.. forever?
It didn't but there is a very clear industry conspiracy to keep it from happening, so it's no wonder it "failed" I'm sure it's somehow the fault of developers and small businesses and not some overarching theme as enforced by industry standards bodies and a few very very large IT companies.
Astonishingly, OpenID seems to be workign just find despite being an absolute clusterfuck of bullshit standards and insecure practices.
I don't understand what the article is actually criticising. Today's "deep links" aren't really about the links at all - after all they're just URLs, nothing special there. No, today's deep links are about publishing those links in a way that allows 3rd parties to find them easily. So, if you're working in television for example, you might be interested in having a standardised way of publishing URLs in your program guide data, such that someone can access your catchup service directly from their television's program guide application, without having to first load your catchup application.
Or in another domain, Yelp might publish an "API" describing how to construct a URL for a restaurant, using eg the restaurant's name plus post code plus street name. It might look something like this: http://yelp.com/The_Olive_Tree/92100/Canal_St (I haven't looked, maybe Yelp really does do something like this....)
Knowing this, a mapping application can now open the Yelp page for a restaurant directly from inside the mapping app. Great! Or maybe you're a serious foodie - enough that you use a restaurant journal app. This app can automatically extract the Yelp data to round out your entry, or alternatively, post your thoughts on the restaurant. If there is a backend to this journalling app, it could even automatically insert deep links to your other journal entries so that other users can see what you thought about other restaurants. There is power in this idea, and it joins up with other ideas such as the semantic web. At any rate I personally see deep links as a positive development.
22 comments
[ 3.8 ms ] story [ 56.7 ms ] threadI believe that part of the problem is that links do not work so well for that initial intent; and that is (IMHO) because of the coarse granularity of that that can be linked; while theoretically you can link to anything with a URI, effectively they usually just point to documents and anchors of some of their parts. And that capability must be provided by the author, so, as the problems with the semantic web, most of the authors do not have incentives. So you are precluded from slicing and dicing content from others and, as Ted Nelson wanted, transcluding that part of another person's train of thought into your own document.
So we repurposed the "link" tool to just navigation.
Perhaps if we could add linkable annotations on pages of other people then we could play easier with other people's ideas...
Although you then gain problem of people changing layout of content. Still a lot of content is pretty static.
If you have a blog and want to send your reader directly to a specific product on a ecommerce store, you create a "deeplink". A link, directly to a product page, containing your affiliate id and all the stuff that the Affiliate Network tracks.
(It would still be a deep link without the affiliate tracking info.)
[0] http://applinks.org/
Unfortunately mobile web pages can't run background processes, can't launch AJAX requests to arbitrary domains, speak UDP, do file I/O, and numerous other things, which is why people end up writing apps.
Also mobile web browsers still suck, unfortunately. Safari still hasn't gotten its act together with simple stings like scrolling, and is riddled with CSS bugs of sorts if you try to do anything advanced with HTML5 (e.g. pull to refresh, swipe gestures). It's almost like Apple is deliberately refusing.
Background processes, cross-domain AJAX and file I/O actually are possible now, at least to certain extents. It's getting a lot better, but as you say, Apple drag their feet at every opportunity.
Also, HTML5 location tracking is severely broken on iOS. In most cases the user ends up inadvertently blocking permissions for Safari rather than on a per-website basis. The result then is that all future websites get blocked from location access automatically, without even prompting the user.
If HTML5 apps are to take off, the web browser needs to be treated as a basic component of the OS and automatically given full access to location tracking and sensors; it should then be the web browsers' responsibility to ask and confirm with each website and manage those permissions (perhaps even seamlessly integrated with the OS permission system itself).
IMHO the restrictions on HTML5 apps like cross-domain requests and iframes are quite silly. At least there should be a one-click way to "trust" websites in the same way you'd install an app.
* The HN app has no registered to be opened for HN URLs.
* The HN app opens, but ignores the URL and just shows the front page.
* The Reddit app is using a built-in browser that does not (or cannot) check URL hooks for other apps.
Astonishingly, OpenID seems to be workign just find despite being an absolute clusterfuck of bullshit standards and insecure practices.
Or in another domain, Yelp might publish an "API" describing how to construct a URL for a restaurant, using eg the restaurant's name plus post code plus street name. It might look something like this: http://yelp.com/The_Olive_Tree/92100/Canal_St (I haven't looked, maybe Yelp really does do something like this....)
Knowing this, a mapping application can now open the Yelp page for a restaurant directly from inside the mapping app. Great! Or maybe you're a serious foodie - enough that you use a restaurant journal app. This app can automatically extract the Yelp data to round out your entry, or alternatively, post your thoughts on the restaurant. If there is a backend to this journalling app, it could even automatically insert deep links to your other journal entries so that other users can see what you thought about other restaurants. There is power in this idea, and it joins up with other ideas such as the semantic web. At any rate I personally see deep links as a positive development.
https://medium.com/@AustinHay/hi-scott-8fd0e4584347