Tuesday, December 04, 2012

Beyond App Stores: Weaving Apps into the Web

The most annoying thing about the mobile web today are the interstitial pages that ask you to download an app instead of visiting a website. They look like this:


Publishers today need to build 4 different versions of the same content: Desktop, mobile browser, iOS, and Android.

On your phone you can read the same content in the mobile browser, and through the publisher's app. Here’s an example with a piece in the New York Times:


The web version of the content allows you to freely navigate and explore in your browser, and visit external links without losing your history. But the mobile app is still superior to the mobile web experience. Apps cache content for flaky mobile connections, and reformat content to be more enjoyable to read on phone and tablet form factors.

No man is an island, but every app is. The New York Times app is completely disconnected from the New York Times site. You can’t just open the app and pick up where you left off in the browser. As a subscriber, you need to log in once in the app and once in the browser. You can’t find an article on Google and have it open in the app: You’d need to manually open the app and type its title into the search bar.

Proposal

What if we married the best of browsing the web - the fact that you can freely move around - with the best of native apps - the fact that native controls, native caching, and scrolling are better on each platform?

My proposal would be to let mobile browsers download small apps and execute them within the browser window. [1] If the browser encounters a specific <meta> in the HTML page, it would download an .apk or .ipa up to a certain size, maybe a few hundred kilobytes, and display the content inside that app. If the user liked what she saw, she could bookmark the app, which would make it show up on the home screen, and optionally download a larger app package with more functionality.

The app could access browser cookies from the affiliated webpage. [2] This would allow zero-step login on mobile apps - something that is painfully lacking today.

Let’s imagine you found the article above with a Google search on your Android device. Below is what the result would look like:


Benefits

Weaving apps into the web would have significant advantages over the status quo. 

For one, every major website already has a corresponding iPhone and Android app. This would free publishers from having to make a mobile-optimized website in addition to their desktop website.

Users would get to try out an app without the heavy cost of installation. Today, installing an app on iPhone today involves finding it in the app store, clicking a button, entering your password, and waiting for the download and install to complete - a process that can easily take a minute or more. Users would be more likely to install apps, and more likely to use them.

Allowing the app to access browser cookies would solve onboarding problems: If you’ve already signed into the website, you don’t need to do so again. Making users type in an email address and a password on a mobile device causes user flow breakage rates of 20% or more. If the app was already installed (which is most often the case), you’d only have to download the pure content.

Allowing apps to be accessible via URLs makes app discovery more like the familiar pattern of browsing sites on the web. All the apps you install today end up cluttering up your home screen. What you get is endless screens of apps, once downloaded, never discarded. 

Apps today are pretty disposable and yet they get backed up and restored as if they were priceless childhood memories. They should be more like websites: If you like it, you better put a bookmark on it. (Apologies for the terrible pun.) Giving an app a permanent spot on the home screen should work like bookmarking a site.

Lastly, a nice side effect of this scheme is that content in apps is connected with the web. A lot of great content is locked away in apps like Instagram. Imagine that you could find content on Google or Reddit or Digg, and clicking on the link would navigate you to a high-definition native experience inside the Instagram app, rather than showing you a degraded web page.

Summary


Many apps you have on your phone today display content from the web in a mobile-optimized way. But apps are isolated and not reachable from the web - they live on their own separate islands. Allowing the browser to download and display small apps from the web would get rid of the tall hurdles of heavyweight app store-based installs, and make app discovery more like browsing the web. This would benefit publishers and consumers alike.

---

Check out the Hacker News thread on this article and enjoy the controversy around this proposal.

---

This post is the latest in a series of posts about the shortcomings of today's app store model. Read more:
  1. Every Step Costs you 20% of Users
  2. The Biggest Problem in App Discovery
  3. Rethinking the App Model
  4. The Two Hurdles of App Adoption
  5. Getting People to Use Your App
---

Notes
[1] User webXL on Hacker News makes a good observation: "Take out that automatic nonsense and I think he makes a good proposal. A URL can currently load a local app rather than a page in webkit. Only in this case, there would be some markup that would tell the browser to check for the installed app, perhaps the browser would present some unobtrusive indicator that a hybrid app was available to download. Just keep the address bar and the rest of the browser chrome there, swap the webkit frame out with the app's window, let the app access some of the history APIs, and you'd have a good portion of this figured out."

[2] There are various DNS and cryptography based ways to prove that both the app and the site are from the same publisher, but I'll leave it to the experts to figure out the details.

4 comments:

Joey Simhon said...

I get where you're going, but I think that "embedding" native apps within web pages and having users wait to get their content is the wrong way to attack the problem, it would just be another web-bypass mechanism. Mark Zuckerberg himself admitted that fb's mobile web app (touch.facebook.com) has x2 traffic than all their native apps combined, meaning smartphone users are already there, publishers need to be part of the mobile web / HTML5 ecosystem.

We @ everything.me are attacking the same problem from a different angle, allowing users to launch both native apps and web apps from the same unified experience, so a user always gets mobile optimized apps either installed or from the cloud.

Gabor said...

Joey - I think you're essentially making the same argument as me. I'm not sure what you mean by "web-bypass mechanism" - can you elaborate on that?

Kenneth said...

I have been working on this exact problem on Android for the past two years. I have developed a library that allows apps to run without being installed. I have been focused on bringing an A/B testing, and App Discovery product to market but in the back of my head has always been the idea of linkifying apps.

I have thought a lot about the problem of onboarding and I think I have come to the same conclusion as you. Installing an app is a commitment. Current AppDiscovery is all focused on getting people motivated enough to commit to something. It is the wrong approach.

Links have no commitment. Links are intuitive. Click a link and get what you want. More importantly links enable sharing, they enable virality.

I have been reading your past articles in this series and think we may be working towards the same goals. I would like to talk to you.

Kenneth Lewelling
kenneth@appprevue.com

Paul Stamatiou said...

"This would free publishers from having to make a mobile-optimized website"

Am I the only one that thinks creating a mobile-optimized site is just 10% of the effort of the desktop version. Some media queries, some larger buttons, different header and footer nav, good to go. And it lets their site work in non-mobile settings too. Smaller screened netbooks (< 800px wide that will trigger your tablet media queries), etc -- places where you wouldn't expect to see one of these embedded native app pages.

I actually think you should make the mobile browser more robust -- give pages access to native OS components. Camera, notifications, etc. Then if a page warrants having its own "app" it can just be like a bookmarked site (whatever iOS calls that) that builds a bunch upon the mobile browser. It's getting there with getUserMedia.