HTML5 App Stores don't go too far enough

tl;dr - HTML5 app stores don't leverage the web as much as we should.

Futurama Political Debate

 I'm convinced that packaging HTML5 apps for stores is emulating failure. There are lots of reactions. Among the comments here, Les made the opposite assertion of mine - "where app stores win over plain old URLs is discoverability. ... URLs are precise, but they’re sharp and pokey for most people to handle."

HTML5 App search engine > Pokey URLs

Les made his own counter-point that we fixed pokey URL's with search engines. So, do we need "a special case search engine where the results are constrained [to HTML5 apps]"?

Maybe.

The "webby" approach is to crawl the web to build an index of all app manifests. But how can we discover the manifests? None of the HTML5 app stores document a way to hyperlink manifests.

But maybe we can use schema.org SoftwareApplication type, with its convenient installUrl property. We can even use the WebApplication sub-type's 'browserRequirements' property to designate a Firefox, Chrome, or W3C manifest. So Incredible Pizza could expose their HTML5 app like so:

<div itemscope itemtype="http://schema.org/WebApplication">
  <a itemprop="installUrl" href="http://app.incrediblepizza.com/incrediblepizza.webapp"><span itemprop="name">Incredible Pizza</span> for <span itemprop="browserRequirements">Firefox</span></a>
  <a itemprop="installUrl" href="http://app.incrediblepizza.com/incrediblepizza.crx"><span itemprop="name">Incredible Pizza</span> for <span itemprop="browserRequirements">Chrome</span></a>
  <a itemprop="installUrl" href="http://app.incrediblepizza.com/incrediblepizza.wgt"><span itemprop="name">Incredible Pizza</span> for <span itemprop="browserRequirements">Opera, Windows Phone</span></a>
</div>

Voilà. We have web technology to make an HTML5 App search engine. But why are HTML5 app stores making developers manually submit manifest URLs to directories when we could leverage hyperlinks - the central nervous system of the web? As a bonus, a hyperlink-fueled HTML5 app search engine is complimentary to existing mobile platforms. This could be nice:

iOS App Search mockup

Apps contextualize content

Still, an HTML5 app search engine doesn't leverage the web as much as we could. Ambrose Little suggests "discoverability is worse [on the web] because it’s not just apps, it is all kinds of content, much of which is not pertinent nor optimized for your device." This gets to the crux of the issue: outside of pure experience apps like games, when we say we want apps, what we really want is relevant, contextual, optimized content on our mobile devices. Can we deliver relevant, contextual, optimized content to mobile devices without apps?

In Programming the Mobile Web, Maximiliano Firtman touches on this in his chapter about geolocation:

One of the great features of mobile devices is that they can go everywhere with us. That is why the where is very important context to be considered by our websites. Knowing the user's location can help us to show useful contextual information -Firtman

Geolocation is a great place to start, since it's so widely supported on existing mobile browsers. I suggested that incrediblepizza.com could return location-specific content using a captive wifi portal or geolocation. But fuzzy search can also deliver location-specific content, as Google Maps does; though it could be improved to deep-link into a domains' pages with something like GeoURL or a geofenced sitemap.

I.e., if incrediblepizza.com added:

<meta name="geo.position" content="36.05877;-95.8831" />
<meta name="ICBM" content="36.05877, -95.8831" />

to their Tulsa store location page, and maybe add a geo point and radius to their sitemap:

<url xmlns:geo="http://geositemaps.org">
   <loc>http://www.incrediblepizza.com/locations/tulsa</loc>
   <lastmod>2013-01-01</lastmod>
   <changefreq>daily</changefreq>
   <priority>0.8</priority>
   <geo-radius>36.05877;-95.8831;30</geo-radius>
</url>

mobile search could do something like this:

iOS Search for Pizza

Search already works

We can search for a pizza place nearby. So what? Foursquare already does that.

But do we have to search for it? As predicted by Mike Masnick back during Yahoo's misguided deal with Microsoft in 2009, "People are discovering that information finds them, rather than them going in search of information. Search already works. The next interesting challenge is in improving the way information finds you, rather than the way you find information."

Improving the way information finds you is how social competes with search, and it's the way mobile web should compete with app stores. Location, time, personal information, preferences, friends, actions - all of these create the context in which information should find us. Chris Cox from Facebook summed it up:

[Mobile phones] should be contextually aware. Check-in to flights, find deals at grocery stores, etc. These things take a bunch of clicks now — it’s all wasting time. The phone should know what we want.

My phone should know:

  1. I have 2 kids under the age of 4
  2. We're near south Tulsa
  3. We typically eat out on Tuesday nights
  4. It's almost dinner-time

It should query the web. To which incrediblepizza.com replies:

  1. Kids 3 and under eat free
  2. We're located in south Tulsa
  3. We have double-play-points specials on Tuesdays

incrediblepizza.com and my phone inform me automatically. This touches semantic web stuff; and maybe that's something we mobile web developers should be touching. Because ...

The only group who can contextualize everything is everyone

The web will obsolete app stores ... again. In Scott Jenson's "Why Mobile Apps Must Die" talk at BDConf 2011, he longs for a web-based phone, and a discovery service that helps us find the right needles in the needle-stack of connected things. He calls it "a baby step towards this idea of doing just-in-time interaction" and says "I can guarantee you this will not happen thru apps."

Why not?

Christian reminds us of Yahoo's first (failed) attempt at re-creating a categorized directory of the web. If you don't have time to read Clay Shirky's classic perspective on ontology at least watch this great related 5-minute video:

Even if you skipped both, here's the crux of the matter (emphasis mine):

Yahoo ... added the shelf back. ... The charitable explanation for this is that they thought of this ... as their job, and as something their users would value. The uncharitable explanation is that they thought there was business value in determining the view the user would have to adopt to use the system. Both of those explanations may have been true at different times and in different measures, but the effect was to override the users' sense of where things ought to be, and to insist on the Yahoo view instead.

You can replace "Yahoo" with "Apple" in the preceding statement and it mirrors the current situation of Apps. The web out-grew Yahoo's shelf; it will out-grow Apple's, Google's, Microsoft's, and Mozilla's shelves. Our sense of where things ought to be and how things ought to find us is better than any vendor's. "The web is going to win again. The web always wins." as Johnath says.

The web will win sooner if we spend less time on the shelves and more time delivering relevant, contextual, optimized content to mobile devices.

Question or comment about this post? Tell me on GitHub.

HTML5 App Stores don't go too far enough / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA
  1. I replied to your comment on my blog with some more rationale for choosing apps. I just don't see it, unless the platform vendors do work to make the Web app experience better, and it's not really in their best interests to do that. I like your idea of integrated Web app search. I do think Web app dominance will be dependent on, to put it simply, user experience of the apps (regardless of how you find them). Right now things are still tilted in favor of native from an experience perspective, but it doesn't have to stay that way. Again, it will require the platforms continued investment, but they have a chunk of change to lose, so I just don't see it happening. I also don't think your analogy of the shelf works because devices are much more of a closed system than generic Web. I will say that the thing I don't care for about the phone gap approach is that it is somewhat deceptive to users. It sorta puts on this facade of being native while it's not, and often times it is obvious that it is not. That's a frustrating experience for people.
  2. That's why Firefox OS - or something like it - is so important. The entrenched devices and platforms won't embrace an open (i.e., web) approach to mobile unless or until we - designers, developers, and our users - make it awesome. Emulating and copying their closed systems is a waste. Curious - you like integrated web app search? What if that search could deep-link into the web apps' content that is most relevant? Because that's basically what the web is. :)
  3. Have you seen or used Google Now on Android? It kind of works the way you want, contextually speaking. It's early days yet, but it often delightfully surprises me by offering up directions on my phone to a place I looked for on my desktop 20 minutes ago. It knows what restaurants are nearby and often shows them when it's mealtime. There's no technical reason why, given the kind of metadata you've laid out, that something like Google Now couldn't spider it and tell you about "pages and apps for places near you" and just automatically surface the pizza place's site and its app. (Which, really, could be the same thing) I know we (mozilla) are building a nice though rather bog standard marketplace right now, but I wonder if 2.0 or 3.0 of that product could be something more webby and extend the whole OWA JSON manifest concept in exactly the way you say?
  4. You mean Google Now only on Android 4.1+ ? ;) That's part of the problem!! But yeah - I really hope we push thru and past the whole app/store model and into contextual data delivered via the open web.
HTML5 App Stores don't go too far enough / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA