Rethinking Mobile First

[Update: Bing is working on solving this very issue with their “auto app discovery” feature”. Read about it here: http://www.bing.com/community/site_blogs/b/search/archive/2011/06/09/iphone-mobile-app-discovery-with-bing.aspx]

I’m on my way back from Amsterdam where I was at the Mobilism conference. The opening talk was by done by LukeW on “Mobile First”. If you haven’t heard Luke speak or you haven’t seen his slides, I strongly encourage you to do so. Luke presents the state of the mobile industry and trends in a very real here-and-now sorta way. His content is very complimentary to Mary Meeker’s very forward looking slides.

I know that the mobile industry is buzzing. This industry is exploding really fast and obviously the growth rate of mobile devices is tremendous. But I think it’s too soon to be saying that all developers out there who are hatching an idea should think of doing mobile, or specifically, a mobile app only first.

There is a huge issue with AppStores today – discoverability. Let’s look at usage patterns on the desktop – the notion of searching for something (Googling for something) is very commonplace. You can’t find something – Google it. A lot of times the struggle is with phrasing your query correctly so that Google knows what set of results to give you, not necessarily that Google doesn’t know content out there exists on the web. But for the most part, it’s not so bad. And Google knows what content to serve you because they’ve done their jobs in indexing the world wide web. Easy. But you can’t compare Google, as we know it, to the search functionality in the (an?) AppStore. An AppStore search will show you results based on other things people have been searching for, or gross sales of an app, or keyword/tag matches with the app’s name and description. But that is not good enough.

Here are some examples specifically in the travel vertical:

 

See the problem? Content within apps (like within TripAdvisor) is not being indexed. More importantly even if it were, Google’s way of identifying which results to show first, PageRank, cannot be easily applied to mobile because the notion of (deep) linking to content within an app doesn’t exist. Sure, I can use the Google app or search in Safari to search for this, which would lead me to TripAdvisor’s website. But that defeats the purpose doesn’t it? BTW, Spotlight on the iPhone doesn’t index in-app content either.

I’m not against apps per se. I think the utility model of apps is awesome. But the content within an app is still limited to the app itself. Say what you want about HTML, but it had structure to it, which made it possible for Google, Yahoo and Bing to index the world’s content. When you look at the matrix of development platforms across the major mobile OSs, you’ll see that there is no such structure for the way data is represented on these mobile platforms.

And this leads me to think that Palm’s WebOS really got it right. It was a really forward thinking developer platform. It’s brought the notion of a “light weight web” dev platform to mobile.

So unless I’m missing something and there is a way to programmatically send your mobile exclusive app content to the a search engine, thinking mobile first for your app may not be the right thing to do. Building a game? Absolutely do mobile first (I mean, what else would you target?) Building a location based service or an app that relies heavily on the camera? I think you need to co-launch a web and a mobile app, if you can afford it. Anything else, especially an app heavy on content, you ought to be thinking hard about going mobile first. Because with 300K apps on iOS and growing, your app may never get discovered. Till a “Google for mobile app content” arises, mobile devices are going to continue to be an extension of what our desktops and laptops are today.

@ai

PS: A lot of apps use a 3rd party analytics provider, like Flurry for example. If one of these 3rd party providers can figure out a clever way to standardize indexing in-app content and then overlay that with an algorithm to surface results (I can’t think of how they’d do that), I think they will have solved the discoverability problem for content-heavy apps on mobile in a massive way.

 

5 thoughts on “Rethinking Mobile First

  1. I think this misses the point a bit.  You are assuming that the search engine is the front-door for any task.  This is the way the web works today for a lot of things, but I wouldn’t say it’s the most effecient.  
    Devices work by enhancing their capabilities by adding applications.  If you want to find a hotel near a specific location, go to your map application (or even better, go to your location hub, which can have multiple associated services).  This is task oriented versus content oriented way of working.  I think what we’re seeing is a move back to the task oriented model – maybe at the cost of discoverability.

    1. I would totally agree with you provided that the task-oriented model of doing things became a norm on mobile devices. I don’t think it is, I think search still rules (much like on the desktop). The task oriented model also makes perfect sense AFTER you’ve got the app you need. How do you get the app you need?

    2. I completely agree with @joewood72.

      Furthermore, although the post provides some astute observations (including one on the WebOS platform), with the right promotional strategy a mobile application could be an ideal first foray into the consumer marketplace.

      That said, in most cases the unfortunate truth is advertisers are not willing to invest in supporting a mobile initiative as they would for a traditional product launch.

  2. I agree with a lot of the points you’ve made about HTML vs. App, as well as thinking Web Product vs. Mobile Product.  That said, discoverability is a problem, but it’s not unsolvable, it just requires a different form of acquisition strategy (including a marketing approach that’s more brand focused than direct response). 

    A quick point though, Luke’s Mobile First framework actually works really well in Web/HTML Products too. The concept is really focusing on stripping away the excess, and building a simpler experience. Designing a product for “mobile” helps you do this, even if you’re only doing it as a head fake to pare down features or options on a traditional web product.

  3. Somebody much wiser than myself once said “I don’t think the world is ready for an honest conversation about the SEO of rich HTML5 apps”. I agree with them. No matter how you slice it, a lot of work still needs to be done in order to enable discoverability of data in either case. BUT, the work we’re doing at Sencha goes exactly in that direction, and we are making (in my opinion) enormous progress in de-balkanizing the mobile internet (notice how I didn’t say web…).

    Now it’s the turn of browser makers and analytics vendors to step up to the plate, almost every tool out there only supports the concept of “web pages” which is moot in a single page application. The content can still be easily indexed, and can have a perfectly semantic structure, but we need to work on adapting those tools to the new reality.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>