TBTO Preparatory Commission/Flickr
We’ve all been in the position of looking for fun places to go and good things to eat with friends, family, or colleagues. And we’ve all used our smartphones to find the hidden gems that will make us look like we’re in the know. But are our smartphones really doing everything they can to connect us with the information we need?
In the past year, and especially recently, a host of companies have set about answering that question. Whether positioned as in-app search or cracking open content, the phenomenon is real and important — not to mention well-funded. More recently, a couple of companies you may have heard of announced that they’re getting into the game in a big way.
Say you’re looking for an awesome karaoke bar, and use Yelp for a quick search. What’s wrong with this picture? Your friend goes on Yelp’s website and searches for nearby karaoke places, then texts you: “Check out all these karaoke places! Here’s a link.” The text comes with a link to a Web page full of karaoke search results. That’s convenient, and exactly what you need. But if your friend is using the Yelp app, the text has to read: “Check out all these karaoke places I found! Open Yelp and search for ‘karaoke.'” The app can’t offer a direct link to the right content, putting you and your friend one step farther from your signature rendition of “Lights.”
Apps and websites play a similar role in our lives, yet apps have traditionally lacked support for deep linking. But deep linking could have huge benefits to the whole ecosystem:
- Sharing: You can text your friend a URL, and they’ll be able to access the same in-app function as you.
- Advertising: Advertisers can target users better by promoting a deep link to the most relevant part of their app.
- Search: Users don’t have to launch apps by name; their search engine can take them directly to relevant functions inside apps.
We can confidently expect that 2014 will go down in history as the year of the deep link. Because it’s not a fad — it’s the tipping point of an inevitable trend on the Web. To explain that trend, let’s reexamine our preconceptions about what “the Web” is.
Understanding the Web
Try accessing your favorite website on your desktop, then on your mobile device. Chances are, it looks very different — each device sees an optimized version of the website. But despite the different appearances, you know that both of your devices are accessing “the same page.”
The Web browser on your desktop and the mobile browser on your phone or tablet are called “clients.” They’re pieces of software that run on your devices, and their job is to request Web pages from the Internet on your behalf. The Web has always assumed that users will visit websites using an unlimited variety of clients. Websites have always been expected to adapt the implementation of each page to optimize for each client.
Just like you can access the same Web page on desktop and mobile, you can also access the same product function through a browser or through an app.
- Your desktop browser can access Yelp to find nearby karaoke places.
- Your mobile browser can access Yelp to find nearby karaoke places.
- Your mobile Yelp app can find nearby karaoke places.
Here’s a diagram of this state of affairs:
In the diagram above, you can think of the Yelp app as a type of client, just like a browser. The Yelp app “accesses” a function of Yelp on your behalf, just like a browser accesses a web page. Notice how the Yelp karaoke-search function isn’t exclusive to your desktop browser, your mobile browser, or the Yelp mobile app. The Yelp karaoke-search function is accessible through all three clients. But there’s not necessarily a way to link to it through every client.
Connecting apps to the Web
We’re used to thinking of the Web as being made out of HTML pages. This traditional view treats apps as a separate world, completely outside the Web. But the time has come to broaden our concept of the Web to include apps.
Modern software products often have multiple editions — a Web edition, a mobile Web edition, and one or more native app editions. A software product’s editions are all designed to perform the same set of functions, and that set of functions is actually what defines the product.
Each edition of a software product is a client that accesses the software product, as shown in the diagram above. In that sense, it’s useful to think of each app as being connected to the Web. This requires us to broaden our concept of “Web” to include apps. The explosion of deep linking efforts in the app ecosystem is actually the Web’s evolution to include apps.
The future of deep linking
Once we understand that apps are connected to the Web, we expect them to support all the conveniences we have on the Web, including sharing, advertising and search. That’s why this is the year of the deep link.
In the coming years, deep linking will change the way you use your mobile devices. Today, it often takes you a few steps to get to the part of an app that you’re interested in. You have to enter through the “front door” by tapping an icon on your device’s home screen, and then navigate within the app. With deep linking, you can go straight to the part of an app you care about.
And today, if you want to use an app that you haven’t installed on your device yet, it takes you even more steps. You have to go to the app store, download the app, open it, and then navigate within it. But on the Web, it doesn’t matter if you’ve ever been to a site before — you can seamlessly follow a deep link.
The future of deep linking is to get the app ecosystem to that same point — letting you access any part of any app, whether it’s on your device or in the app store.
Liron Shapira is the co-founder and chief science officer of Quixey, and created Functional Search, Quixey’s all-platform natural-language app search technology. He is an advisor to both the Machine Intelligence Research Institute (MIRI) and Center for Applied Rationality (CFAR). Before Quixey, Shapira worked at Slide, where he was the second developer on the successful SuperPoke Pets product. Reach him @Liron.