• Convenience
• Social
• Already #1 overall (PC)
• Tablets
• Mobile, TV next
• Wifi proliferation
• FB, Google, Amazon, Netflix, et al.
• Open, free, democratic
• Targeted traffic
• Cross-promotion is easy
• Direct cloud updates

The app stores have gained us a lot with respect to previous models in mobile. But they’re also a step backwards in many regards related to what we’ve become accustomed to when delivering to a browser.

Lots of people say things like “Why would you want to deliver something like Angry Birds through a browser anyway? That would always be a native app.” But I’m not convinced there. What if they didn’t have to stage updates in big releases and just put out a level at a time? What if you could challenge a friend to get 3 stars in a level, and they could play that level right in the browser without installing an app? Stuff on the web is a lot more malleable. Even if the technology side didn’t make sense, many of the secondary benefits stack up into a pretty strong driver.

The README has info about how to output bookmarks in a form that the shim will understand. This is just initial hackery, not a real project yet. I just figured I would share it cause, well, taking some JSON and syncing it to the default browser bookmarks just seemed like the kind of thing other people might want to play with. If you turn on install from unknown sources you can download my prebuilt binary if you’re not into the whole Android development thing. Who knows, once I clean it up some I might even upload it to the market. There’s more hackery to be done first. Firefox Sync, I’m looking at you.

It’s too bad bookmarklets don’t work too well in the default Android browser otherwise there would be some much more obvious fun to be had.

So what does that theory have to do with the mobile web? I think it helps summarize one of the primary failure modes for doing mobile web work. There’s a natural tendency to look at the desktop web when thinking about how to address mobile. However, many things that we’re doing on the desktop web just aren’t adjacent to the existing practice on the mobile side. We might make it there eventually, but we can’t make it there now. We assume we know where the mobile web is eventually going TO because we know all the awesome things that grew out of the desktop web, but it’s more important to think about what the mobile web is going THROUGH in order to up the chance of being successful.

For instance it’s pretty natural to assume that because more capable devices are ending up in the hands of a wider audience now would be the time to start working on mobile media properties. However I don’t think the advertising environment is really at the right stage of evolution on the mobile web to make that style of property the same slam dunk as it would be on the desktop web. I think what we really need are a few direct monetization services to kick things off. We need the Amazon and eBay of the mobile web. Those two shifted perceptions on the desktop side, one with direct sales and the other as a sales platform. The media models formed around the commerce that started flowing. I’m starting to think that until the mobile web has something to sell it’s premature to start trying to run media models.

Not that media properties won’t work, I just don’t think they’re what we need to significantly shift development toward the web. And of course, I’m planning to test some of this out cause I might be completely insane. Hat tip to Jay Jamison and Eric Ries for the recent discussions at Founders Labs and Bluerun that have kicked off some interesting ideas.

The state of the mobile web presentation that Dion Almaer and Ben Galbraith from Ajaxian did at the start was a fantastic summary for someone like me. I frequently say “I’m not a web developer” so that no one would confuse me with the folks who live and breathe JS and CSS3. However I’m also not a “native guy” either. I try to use the right tool for the job, so I’m not really in any technology camp at all.

I have a long history of working on the mobile web actually. Sitting in the sessions yesterday I was blown away by how different of an environment we have over quite a short time. In particular during the talk from Alex Russell about browser support and during the state of the mobile web talk it reminded me of a set of discussions we had in June of 2007 about applying the AJAX model to mobile. The points that Dion and Ben made summarized the set of issues way better than I ever have. There are three important components to making a development platform work:

• Platform Distribution
• Platform Capabilities
• Merchandising

The first two points echo the discussion we were having in 2007, with the difference being that now mobile browsers don’t crash if you throw standard desktop JS libs at them. Because we have a nice meaty set of high capability devices in a relatively large number of hands, its finally possible to tune the platform capability vs platform distribution tradeoffs in a way that makes business sense. I think we’re just now edging over a tipping point actually, but that discussion is for another time.

I would actually call their third point “monetization” instead of merchandising, but that’s a nit really. The way they were discussing it, advertising and promotional programs are lumped into merchandising. But this is the area that I think is most in need of help currently. Most folks working on the mobile web are rolling their own when it comes to merchandising. And I don’t really know of many services to point to who are monetizing effectively outside of the app store systems. So if anyone else out there knows of good examples please pass them along. Ben and Dion did make the point that for anyone who has tried to sell software on their own either independently or through other channels, the 30% cut that Apple takes for selling your app on the app store doesn’t seem overbearing. Good point.

Another fantastic point for the day came from Yehuda Katz. He came and presented at the last Mobile 2.0 developer day, but was just settling into the new role. This time around he said something along the lines of (and I’m paraphrasing, so forgive me if I misquote) “people used to have 0 or 1 main computing device they used, now we have 2 or 3″, and addressing that shift is that “mobile strategy” should be about. It should be about delivering the right experience at the right time across different devices. Echoes of the service avatars presentation Mike K did at Mobilize. I think Yehuda really hit the nail on the head in calling out that point as the base of the discussion.

I had already been poking around with JQuery Mobile, Sencha Touch, and SproutCore. Now I’m thinking it’s time to pull together some of the hackery into a project and see if I can make one of them work at scale. Seems like all the ducks are finally starting to line up.

First of all, I’m going to assume that we’re all in agreement that asynchronous messaging is an interesting thing and a unique value of mobile, as well as being an invaluable hook for the business end allowing us to keep users engaged and active? All in agreement? Yes. Great! Second we have to agree that SMS sucks. I’m going to assume that all the major platform providers having dreamt up their own endrun around SMS to deliver asynchronous notfications is evidence enough without having to delve into the details of the cost structure, granularity of control over who can contact you and when they can contact you, and ability to modify those setting on the fly without having to change your phone number. This, also, I’m assuming is not a huge leap of faith.

Today I was fooling around with Boxcar to send asynchronous notifications out of a web based iPad app. Hat tip to Rob for pointing it out. Boxcar is able to serve effectively as a shim app allowing you to send iOS notifications to opted-in users on behalf of any general web app, and drive the user back into your web app if they choose to follow the notification. Just sign up as a Boxcar provider and you can send iOS style popup notifications via their REST service API. Nice job Boxcar folks, slick service! There are a few clunky aspects related to user experience on the whole, like Boxcar launching into a framed browser to pop up the content and losing the redirect location if Boxcar is already open when the alert comes in (just make sure you always set source_url). It’s good enough for some prototyping however, so I’m pretty happy actually.

But then that got me thinking “Hey, wouldn’t it be nice if Apple just provided some OAuth style interface to allow iTunes accounts to opt into getting push notifications from web sites.” That one is actually pretty simple, and would be a fantastic boost for web apps. And potentially could also give us a way to get update badges updates for webclip icons, how slick would that be huh?

Then I went over to thinking “Damnit, why don’t the carriers provide some mechanism like this to allow for internet-to-mobile messaging without requiring us to go through all sorts of custom APIs?” I mean, should SMS aggregation really be a business? I don’t think so. For all the talk of evolving carriers so that they’re relevant for the next generation of mobile, I would think that figuring out how to API a base service of your network would be on the list of things to do. There’s work to be done to get it going, obviously. You need to tie in number lookup databases to find out which provider to contact, layer in an opt-in for users (just handle that via SMS too – “Reply to this message with ‘ok’ to allow rowehl.com to text you”), and some kind of messaging dashboard to allow users to tune or adjust setting on a site by site basis (at least if we’re going to bring things to some degree of parity with state of the art).

It’s certainly nothing new that I complain about messaging to devices needing a cleanup. But this time I think the folks with control over the system might have some interest in fixing it all well. Carriers/operators, I’m looking at you. Concerned that increasingly development is moving to proprietary platforms with opaque APIs and inaccessible payment methods? Hoping that now that we’ve got what increasingly looks like at least a two horse race the mobile web might start to come around? Us too. So please, help us out just a little bit, and fix at least one part of your environment so that it doesn’t “suck at the Internet”. Giving us a workable asynchronous notification mechanism for mobile devices would go a tremendous way toward helping folks trying to build businesses based on audience volume. KTHXBAI!

Lots of folks have been pining for a system that mashes together the best parts of the app store model with the good parts of the web. There’s lots of stuff that doesn’t work so well with the app stores (someone else telling you what you can release, having to filter all your releases through someone else in order to get them out to market, a lack of crosslinking and organic discovery). But the app stores have managed to provide a level of success in mobile that’s also pushed the boundary quite a bit. They provide payment mechanisms that seem to work much better for developers than previous attempts have, and they’ve gathered together a critical mass of users so that the folks who do see success see it at a significant level. We’ve gone through the native apps vs web apps argument in the past and touched on the app store vs web distribution issues as part of that.

So as far as putting a stake in the ground and trying to move us toward that model of app development, fantastic! Happy to see the effort. There are some parts I need to poke around with a bit to understand better. There’s a section about mobile usage that touches on offline applications, which I think is going to be one of the most major issues. It’s not immediately obvious to me if we could get apps installed via this mechanism to appear as icons on the iOS homescreen. Folks like OpenAppMkt have their method, which seems to be detecting the launch type and asking the user to install the app by walking them through the web clip process. I’m assuming the same process would need to happen for offline use of apps installed in the dashboard? So far I haven’t seen how the AppCache handling would be triggered by the manifest install, though maybe that’s just my ignorance of the AppCache. If there is some magic that happens there it would be great to see in the demo. An offline friendly dashboard and example app or two would go a long way to exemplifying the utility of the system from the mobile end at least.

I’m struggling to understand what’s going on in the AppClient code, there’s stuff going on in there I’m just not familiar with yet. I think it’s cross-document messaging, but I need to do some more studying before I’m sure. The distinction between authorization URL and the web app URL is kinda bugging me. It means I’m not necessarily buying an app when I perform a paid download, I’m licensing right to an app from a particular store. Not exactly the model I think we want to end up with. But then again, we don’t really have an alternative to compare it to that works in a distributed fashion like this.

So, awesome start, looking forward to seeing this evolve. Now I definitely need to step up updating myself on web tech, horribly behind.

Having devices, browsers, and networks good enough that users could at least access the full web version was the first part of the equation. It made it possible to at least use the web from a mobile device. But still, there’s wasn’t significant traffic flowing. Not enough to shift the behavior of publishers at least. That’s changed pretty drastically over the last six months. I’ve spoken to a lot of folks who say things like “I took a look at our analytics and realized we had a ton of mobile devices hitting the site, and when I dug in a bit it seemed many of them were coming in off Twitter and Facebook shares.”

That’s fantastic! It used to be that us mobile folks like myself had to convince someone with a website to build a mobile version in the hope that they could then tempt some traffic their way. However, it’s a much easier discussion to have when the publisher is ALREADY seeing significant mobile traffic, and they just need to make the decision about how to serve it better.

The role of these applications as bridges between social sharing services and the web is finally getting links in front of people on their handsets, links people are clicking on. Its something that was missing for a long time. Google has done a good job of bridging search over to mobile, and they’re a decent driver of traffic as well. But based on the stats I directly have access to and the folks I speak to, Facebook and Twitter are much more serious sources of traffic. Granted, most of those folks have explicitly put something together to get distribution via Twitter and Facebook. But for the last 5 years I’ve also had discussions with folks attempting to tune explicitly for getting mobile search traffic, and that didn’t happen. So I think it’s a fair comparison.

So thank you Twitter and Facebook, you’ve helped to open up an environment that was sitting locked up for the last decade. I made my own efforts to get the system flowing and didn’t make it anywhere I would have liked to, so tip of the hat on a job well done. There are still plenty of examples of places where we need to get better at serving mobile users, but we’ve at least started. And the mobile web a whole is in a much healthier place (it finally doesn’t feel like hype!!!).

I think the native apps vs. web apps debate is going to rage on. As I’ve attempted to lay down, it’s not a black and white discussion. And again, Twitter and Facebook are fantastic examples of services that don’t need to make that binary decision. In some places an app version works best for them, but they leverage and enable the mobile web. The big decisions for any business should really be around building a fantastic service, and the tactical decisions of native app or mobile web are secondary, and are going to shift as the technology progresses and morph over time. Twitter and Facebook have built great services. I’m looking forward to having more examples over the coming years, and less looking forward to the continued debate over web vs. native.

However, I’m struggling with a big disjoin between what’s possible and whats practical and productive. We’ve gone through the discussions plenty of times before regarding the economics of developing for lower end capability devices (users of those devices segment into different demographic buckets, finding ways to address them is more difficult, etc). So lets just assume that folks using lower capability devices make good users and they’re people you want to address as users.

I talk to a pretty decent set of web developers on a pretty regular basis. Some of them have started to get excited about developing for the mobile web. I hear them say things like they’re happy they don’t have to pick up a whole additional set of markup to make things work on mobile devices, that they’re happy lots of the base functionality is showing up directly in javascript API, and that the layout engines have gotten good enough that they can make pleasing web experiences. Generally I don’t hear too much from the web developers about being able to hit wide swaths of devices with the same set of markup and styles. And I can’t recall any of them saying they’re anxious to supplant the programming models they’ve come to develop with different architecture for web design. Actually, I hear things like “it works on the iPhone, that’s what I have anyway, I don’t care about Android” more often than I’ve heard people discuss how to make things work consistently on both platforms.

Whenever the discussion starts to revolve around hitting multiple handsets, it’s always driven by people already in mobile. It was my impression that the next generation of mobile web technologies was supposed to cater to the existing set of web developers and make mobile an attractive option for them. I’m not seeing that happen however.

So my question is for what group of folks is this going to be the right tool? I’m certainly not a web developer, but I understand the stuff that goes on there. But you don’t even really need to be familiar with the technology, all you have to do is take a look at Twitter on any given day at the discussion going on with web developers. Quite a bit of it revolves around bitching about “cross-platform” issues, which normally means getting the stuff to work on different browsers even when we’re dealing with full desktop layout. Now we’re talking about supporting different device resolutions and orientations all using different browsers (or at least different versions)? I can’t see the web devs I know jumping out of their seats to volunteer for that.

The technique that I see most folks using is segmenting their traffic and swapping things out on the web server. They design for desktop, high capability mobile, and low capability mobile. They detect what device they’re serving to normally based on the user-agent, and then serve up the correct version directly. Both techniques have issues, granted. Lots of issues. It seems like the “new new” of progressive enhancement laid out in the slides would work best when you’ve got:

• Folks working on the implementation who are at the deep end of HTML/JS/CSS
• An environment where the pages need to be static and server side switching isn’t available
• There’s a minimal amount of application logic.. trying to interleave dynamic content updates and event responses with the complexity of adaption seems problematic

Or am I missing the boat here? Is there a way to apply this stuff that significantly lowers the bar for implementers? Or plasters over a bunch of these complexities? Or merges together the different models and techniques? Cause it’s hard enough to convince the web folks I know to even play around with iPhone, we’re just starting to make some inroads there. If I laid something like this in front of them they would probably kick me. So, please, educate me. How do we put things together so that doing web development this way is compelling to someone who isn’t already a mobile devotee?

UPDATES:

PPK is rising to the challenge and trying to lay out how things should be working. Here are his responses:

• State of Mobile Web Development 1/3
• State of Mobile Web Development 2/3
• State of Mobile Web Development 3/3

Daniel Hunt has also followed up, with a different take than PPK, saying that device detection is an essential element of being able to deliver a great mobile web experience.

In my opinion there are two major factors from the mobile web side that are pulling “web apps” into the broader discussion of applications. The first is offline web applications, which provides a way to specify a set of files that should be downloaded and cached locally so that the browser can continue to serve up the application even if the underlying system is offline. Besides the obvious benefit of being able to operate when the system is disconnected this also commonly means that the web application is given some kind of “desktop presence”. On iPhone I’m seeing more apps that lead the user through the process when they first connect to the app that results in an offline app with an icon in the launcher. This was one of the issues that most expected was hindering the mobile web, getting users to return to your app even if they liked it. I haven’t seen the same thing in practice as often on Android devices, but the common frameworks seem to be working on abstracting out this pattern across device types. I expect to see it a lot more. Having a manifest file that lists all the necessary resources also explicitly draws boundaries around your application. Sure, it’s still a web app built on HTML/CSS/JS, but it’s also in a very real sense also “shipped software”.

The other big factor is the single page web application pattern that seems to be gaining popularity. The entry point into the application is a static chunk of resources which dynamically loads the info necessary to present the app. It’s a shift from the content of the pages being the primary organizing principle the the functionality of the app being first and foremost. Organizing in this fashion actually complements the offline functionality quite well. However it presents a few issues too. It requires a few acrobatics to make sure the application functions in the absence of some of the functionality, and to ensure that users can bookmark pages sensibly and search engines have some kind of content to grab onto. I’m also not exactly sure yet how something like rearranging content around a simple layout and progressively enhancing would lie together with the single page app ideas. Seems like they would complement well, but we’re raising the bar pretty high at this point for web devs.

No matter how you slice it though, it’s pretty obvious to me at least that the conversation around applications isn’t just restricted to native dev. It isn’t even restricted to mobile. The granularity and structure of the resources being served up by all the web servers out there is starting to shift. Folks responsible for finding relevant info from the mass of data have started to pay attention to “the appiffication of the web” both on the desktop and mobile sides. I think right now we have a grab bag of techniques and some relatively new technologies that allow some of the bleeding edge folks to put together some really compelling apps on the mobile web. But I have no doubt that in short time all this stuff will be wrapped up and properly abstracted so that writing functional, fast, delightful web applications for mobile devices will be within the reach of most developers. And for the most part we’ll forget that we even passed through another era of native apps on the way to the mobile web.

One of the major themes for 2010 that became apparent as we were putting together the lineup for developer day was the increasing momentum behind the mobile web. A few months ago it was looking like a pretty strong trend, and the last few months have seen even more activity than I expected. The folks at Sencha pulled down a bunch of funding, a formal release of jQuery mobile was posted, and we’ve seen folks like OpenAppMkt take the first steps toward paid distribution of mobile web applications. So I’m happy to say that with the benefit of hindsight, including a lot of mobile web focused content seems even more relevant than it did a few months ago. W00t!

There are probably a few major factors driving the increased attention that the mobile web is getting. There are two that I hear probably most frequently, with about a 50-50 split between them depending who I happen to be talking to. The first is that folks really want to get back onto a release cycle that looks like the web release cycles they’re accustomed to and not the shipped software cycles they’re bound to when working through the app store. Even if they can’t necessarily get everything done exactly the way they want to on the web, having to make a few compromises in terms of functionality is worth it to be able to update your application at will. This seems to be particularly true with folks who are already accustomed to web development, and just assume that iPhone dev will work somewhat the same. What I’ve been surprised by are the number of folks who jump into native mobile dev and only start to realize the problems after they have apps out. Eventually they say something like “Hey, how am I supposed to do A/B testing in an iPhone app?” and the problems start to snowball from there. I’m seeing an increasing number of folks in this category.

The second major driver is the increasing attention folks are paying to Android as a platform. Although tales like Advanced Task Manager has to tell of great revenue number on Android are few and far between, the increasing number of handsets out in market and the evolution of the platform are drawing more and more attention. It’s been true for a while that free apps from major plays will have an Android version to ensure the app provider gets decent coverage of their user base. But recently folks that are shifting significant numbers on iPhone are starting to look at Android as an additional paid distribution channel. Angry Birds testing out the waters of Android with a recent beta release is an excellent example of something we’ll probably see a lot more of. On the paid distribution side a native port is pretty much a necessity. But for folks just coming to market now, especially those looking to monetize through in-app sales or advertising, the mobile web is looking increasingly tempting as a way to go cross platform without having to plan for porting.

If that’s the kind of conversation you’re looking to have, check out the lineup we have for Developer Day this year. If you factor in the “friends” discount it comes out to $88 for the day. I think we’ve served up a fantastic lineup for the cost.

There’s also a Best Practices for Mobile Design event we have going on the evening after the Developer Day. It’s just down the road at the Computer History Museum in Mountain View and the schedule starts after the developer day program ends. So if you’re planning to come for developer day, please also join us at Mobile Monday by RSVPing at Eventbrite.