Bridging the web-native gap

20 September 2015 Web
Photo by [Simon Bleasdale](https://flic.kr/p/9BZ2ey).

Native apps should use the strengths of the web to deliver better experiences for everyone.

Photo by Simon Bleasdale.

The line between websites and apps is becoming blurrier every day. What with entire operating systems being made with HTML5, and the recent influx of native adblockers on mobile platforms, there’s all kinds of cross-pollination that is absolutely good for the industry and good for the web in general.

Despite this, there’s still quite a gap between native apps and the web. One glaring example that Twitter users have had to deal with for nearly three years: Instagram’s decision to remove photo previews from tweets. This political decision has caused a truly horrible user experience for all of us.

Yeah, nobody’s going to click that Instagram link. Not only is the preview missing, but this link will open up in your phone’s browser instead of the Instagram app. Even though you may be logged in to the Instagram app on your phone, you’ll likely have to log in again through the browser.

So let’s recap. If you want to fav an Instagram photo you found on Twitter, just follow these simple steps:

  1. Click an obscure photo link that has no preview
  2. Get directed to your browser, which is probably a second-rate experience compared to the native app you already have
  3. Log in with the browser, even though you’re already logged in on your app
  4. Get redirected to your home page feed. Now you’ve lost the photo you wanted to see.
  5. Switch back to the Twitter app
  6. Follow the same link you already clicked in step 1
  7. Double-tap to fav

Here’s our problem: the browser doesn’t know your apps exist. Your apps don’t know that other apps exist. Your default browser gobbles up every link that comes across its path and the experience is terrible.

A better vision

This week, I’ve been musing about what a standards-based, backwards-compatible way to bridge the web-native gap. The more I thought about it, the more simple the solution seemed. We have the necessary tools at our disposal, but nobody seems to be using them to solve this problem.

There some truly mind-boggling proprietary URL schemes and workarounds out there. Relying on a new URL format or third-party app are not long-term solutions. These over-complicate the problem and drive a wedge further between the web and native.

What if all links to facebook.com were opened by your Facebook app by default? Any link to twitter.com would get intercepted by your Twitter client instead of opening in the browser. Same deal with Instagram.

This concept could be expended further. Let’s say you’re browsing Project Gutenberg to find a sweet ebook to read. You have an ereader app that listens for .epub links, and adds them to your library with one click. This saves you the steps of downloading the file, opening the app, and importing it manually.

Sounds nice. How do we get there?

The chokepoint here is the operating system itself. Right now, you can download alternative browsers and set them as your default. We need OSes to mash-up this functionality with a little regex and let any app be the “default browser” for certain kinds of links.

This preserves backwards-compatibility by opening links in the default browser if the user doesn’t have the app, or if they’re browsing on some other kind of device that doesn’t have apps. It’s the best of both worlds.

I’m not sure what the next step is: petition the smartphone OS makers? Build support in the developer community? Rally users on a per-app basis?

This solution really has benefits for all three groups of people. OS makers can save the time and energy they’re wasting on duplication of the HTTP protocol — no need to reinvent the wheel. Developers can offer deep integration with the web while offering first-rate native user experience. Users don’t have to feel shuffled around like sheep and get a smoother user experience.

Let’s talk about this. What do you think?

Update (1 Nov 2015): It looks like the newest versions of iOS and Android will support app-to-app links, also called deep linking. This is a good step forward, but unfortunately could also mean a step back. Both OSes will require apps to prove they own the URL, thereby crippling functionality for third-party clients and limiting the creative potential of the native mobile experience.

Sam Nabi

Comments

Ian Davis 4 December 2015, 15:49

Sam, I’m teaching CS446 “Software Architecture and Design” at UofW starting 8:30-9:50am Wed/Fri January 2016 to 4th year engineering and computer science students, as well as probably some graduate students. The above post is precisely the sort of high level “Architectural issue” I’d love to see presented to my 75 students. I suspect that your own generation would have no difficulty relating to your frustrations. But I’m not sure if I have the technical background to present the material above, since I don’t own a smart phone or have any knowledge of the apps described. Would you like to present the above issue and possibly other pet peeves to my class regarding mobile technology for subsequent collective discussion and exploration. Coincidentally their course project will be to develop a mobile app of their choosing in teams of 4 that runs on a smart phone. Ian Davis. <a href=”http://textserver.com"; rel=”nofollow”>textserver.com</a>@gmail.com

Ian Davis 4 December 2015, 16:40

P.S. Really sensible simple idea.. easily implemented. Only issue might be getting apps to run on URL as input.

Post a comment