A lot of the value that they’re delivering stems from contextual awareness, which is hardly a new concept. It’s just amazingly difficult to deliver. Most of the objections I’m seeing voiced in the press are related to security and privacy. Unfortunately that seems to be the bugaboo that gets thrown out there when they don’t have anything else to object to. That argument is boring and tired, I’m hoping we can move past it pretty quickly.

Me personally, I’m willing to share a whole lot of info to end up with a better mobile user experience. I just signed up for the beta. WANT! Aro Mobile folks, if you need data, I’m willing to share it. Contact lists, email, calendar, current GPS coordinates, retinal scans, bloodwork, whatever. If you can deliver on what you promise, I’m in.

3 2

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!

3 2

For the tracks that I was in, there seemed to be a strong preference from the judges for plays that take existing content and either get it up online and involved in interactions, or drive the interactions down to a more granular level. Some examples:

• Foodspotting won the pitch session in the morning with their tagline “find dishes instead of restaurants”. This is a good example of both driving down to a more granular level. Instead of reviewing the restaurant overall users review individual menu items. As well as ways to put additional granular information online. Food review sites or travel shows like No Reservations can use Foodspotting as a platform for featuring their content, getting a lot more usage out of that info than simply leaving it on the site for the show. Instead they get it in front of a user when they’re actually looking for something to eat.
• DataPop is another one that the judges loved, and is an example of making online interaction more granular and taking additional content online. Their example of typical engagement is taking a bunch of offers normally distributed offline and making them more effectively targeted for online use. Offers that normally go out through a circular or set of direct mailings frequently get put online as well. However the ads created to go along with the offers and the landing pages the offers drive to aren’t optimized for conversion. And for the folks who do try to customize the process is very time intensive and the humans in the loop frequently don’t have the right info to optimize. So DataPop combines automation and a base of info representing accumulated knowledge of search behavior and response rates to automate the generation of optimized ads and landing pages. Anyone who’s worked in online advertising or marketing knows the value there.
• Goodzer took away top honors from the show, everyone absolutely loved it. The main claim is that they have a crawler that can identify retailers online, locate them, identify the products they offer, and even pull inventory levels for those items. They claim they can do it completely generically for all product anywhere. That’s a bold claim. And even if we assume the technology itself is completely solid, we have to make some additional assumptions like the retailer keeping their product list up to date and their inventory levels current. However, if their claims are anywhere near accurate (and we can’t validate that cause they’re not publicly available yet) it would be a great win for local commerce. There are plenty of services that do online comparison shopping, but there doesn’t seem to be much out there that ties individual products to physical locations, useful if I want to go out and get whatever I’m looking for right now.

There were lots of social networking plays there too, marketing platforms aimed at collecting additional information about connections, ways to aggregate and drive fans with targeted offers, etc. Generally those didn’t really resonate with the judges. I think it’s because the judges generally came from large companies who have the resources necessary to build out their own platforms if they see value in collecting additional information or engaging with their users in new ways. Some of the platforms could be of real use to small and medium businesses, but then the questions generally swap over to how the business plans to reach all those businesses (it’s traditionally costly and time consuming).

Interesting trend to see in the judging. With the economy as a whole still in a questionable state, and online marketing doing okay after a period with some serious rough spots, I was wondering if the big marketers would be looking to be more conservative with their spends and trying to get more effectiveness out of their existing channels. Or if they’re looking for new channels and more inventory. My takeaway was that it’s very much the latter. Not that they don’t care about being efficient. There are just enough folks already providing optimization, that market is served. New avenues and approaches are what everyone seems to be focused on.

5 1

I think it’s probably worth digging a little bit at how numbers in these marketplaces break down. I’ve worked at a bunch of advertising related startups in the past, and there are some basics of market sizing that I don’t run across as often as I would expect to. Basic market sizing is important for anyone starting up a new venture. Especially if you’re looking to raise some money. Even if you don’t run these numbers the people who you’re talking to definitely will.

The first important point to recognize is that your income as an advertiser is someone else’s cost of doing business. With the relationship abstracted through advertising networks it’s often easy to forget the simple relationship that exists. Take the App Store for example. Just to use round numbers lets say that the App Store is generating a billion dollars in raw revenue. That’s the total market size, and you need to work backward from there to figure out how much value you can capture running advertising. First you need to take out Apples share, so you end up with $700M going to third party publishers.

This is where most folks stop, but that $700M number has nothing to do with how much money you can get out of running advertising on mobile. If $700M is the amount of raw revenue that app developers are making with both direct sales and in-app purchases, it’s some percentage of that which they should be willing to spend on advertising. Cause in a rational market people will spend less on advertising than they make in revenue. Otherwise the marketplace as a whole isn’t working.

Because of that I’m not surprised at all that virtual goods would outpace advertising as the major source of revenue. Currently most folks are making money off direct sales or in-app purchases, so they’re spending less to get users than they’re making off those users. That’s good news actually, pretty healthy. During the initial land grab for a new marketplace you might see more ad revenue coming out of a system than sales revenue, but that’s not a long term sustainable position. The way the ad marketplaces crashed in 2000 is a good example there.

The way to really open up the advertising marketplace in mobile is to get folks who aren’t selling mobile goods and services to advertise on mobile. It would be great if we could size the advertising market for mobile not based off the revenue numbers from the App Store, but based on other offline revenue streams. The numbers get a lot bigger a lot faster if the advertisers and the inventory providers aren’t the same people. If the only people spending money in mobile advertising are people making money directly off mobile you end up with an unsustainable marketplace. Literally the equations don’t balance. I make X off my mobile service, so I’m willing to spend 10% of X to market my service. If the only way I make money is advertising then the amount of money being put into the system needs to equal the amount of money coming out of the system (at a macro level). So X = X * 1/10. That equation only works out when X = 0, which is what folks mean when they say “the market is unsustainable”.

Right now we’re getting a decent amount of lift in the system as a whole because there are large numbers of new users coming online and a lot of speculative investment going into attempting to capture large user bases. At some point that won’t be the case however. And the smart money is looking to spread out the model some, looking for folks who have significant chunks of their revenue streams from something other than advertising. That way if the market in mobile crashes out the way the online advertising market did in 2000 you don’t have to fold up your business and go home.

I agree with the Flurry folks though that the streams on all ends should keep growing. I think the shift from direct sales to virtual goods is a good intermediate step to help mobile advertising through the real step it needs to take – which is getting offline commerce transacted through mobile devices. When you take a look at chunks of revenue like like the $1.5B that eBay is making through their mobile service you get to numbers that look like game changers pretty quickly. I think the long term potential of this shift is why there’s so much activity going on in mobile payments (even if just being a mobile payment system for online desktop offers, that still opens up a large pool of money relatively speaking) and local advertising (which is the one area of advertising where a large healthy mix of the spend comes from physical merchants looking to drive foot traffic). I’m happy to see things shifting pretty smoothly too. If the progress keeps up hopefully we won’t have to struggle through yet another painful “correction” in mobile as a whole.

6 1

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.

8 0

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.

8 3

• Paul Nerger shared some info about monetization and promotion efforts for the Hollywood Walk of Fame set of content they’ve been experimenting with. He said the desktop web version is generating a $1.83 ecpm, but they’ve gotten the mobile version only to $0.17. He also said they had tried out QR Codes to see if that would drive some traffic and help on the distribution side, but they haven’t seen good results at all so far.
• The folks from xAD pointed out that while 4 of the top 10 advertisers in the US are carriers, none of them are spending significantly on mobile advertising currently. Mobile ads is perhaps an industry that could use with a little more dogfood eating.
• There was some commentary, positioned as pure speculation so I won’t attribute it to anyone, that the uptake of iPads in the financial services industry is actually helping out Blackberry. Lots of financial services folks were replacing their BB devices wit iPhones to get access to the realtime finance apps. However now folks seem to be picking up iPads and keeping their Blackberry devices. Carlo said he heard from a panelist at another event that enterprises are buying up iPads by the thousands. There’s a lot of argument on both sides of the tablet debate, but justified or not it seems to be shifting dollars for at least some people.
• Discussions around distribution tended to say supporting multiple platforms is necessary. “Why would you bet on only one horse?” I think was the way the question was phrased. I called into question the value of that advice. There are some business models where it makes sense, there are others where statistically speaking the expected payout is far below the cost of porting. I think this remains one of the most fundamentally misrepresented set of discussions in our industry, cause everyone wants to shift attention away from Apple and try to frame their attempt to attack the iTunes platform as some kind of generic good business advice. It’s normally pretty transparent however.

From the set of presentations that I sat on the panel for, my favorite was Phone Halo. They have an application and service up and running where you can attach a small bluetooth dongle to something you don’t want to lose (your keys for example) and your phone will watch and alert you if the phone gets to far away from the dongle. They also have an online component where you can track a GPS snapshot of the instant where the two devices went out of range so that you can go back and check online if you miss the instant where the devices disconnect. I liked the idea not so much for just the set of things they’ve put together so far, but because the concepts lie very much inline with the service avatar principles that Mike Kuniavsky laid down at Mobilize. A simple single purpose device that fronts for a larger service up in the cloud. It’s the kind of idea that I suspect will have broadening instead of narrowing applications if technology keeps progressing in the direction it has been.

4 0

These are the three top points that people either tweeted or grabbed me after the event to express:

• There were a ton of points raised. Any single one of them would have been great for a deeper dive, but we breezed through them all without digging into enough of the details of any one to pull out some real meaty discussion.
• Apps were severely under-represented. Even the ‘native’ folks on the panel effectively do web development, just connected to native functionality. So there was no real conflict, and conflict tends to bring out the most interesting points of a panel conversation.
• The tone of the panel seemed to be that web development for mobile is great, but not a really viable path currently. Lots of the web folks took issue with that. The web on mobile devices is here now, and it’s a workable environment. It just takes significantly different tactics than app store models to make it work.

I want to try to lay down a high level overview of the issues I hear most frequently discussed, and that’ll probably help explain why we had some of the issues in trying to present the topic. Hopefully I can pull in some other folks very knowledgeable about the topics to follow up and fill in some specifics.

This topic as a whole is enormous, that’s the first problem with trying to cover it. It pulls together technical conversations, standards discussions, and business issues all into one. The first set of questions around using web technologies for mobile devices normally focuses on the computing power of the platform, are handhelds powerful enough to process the set of HTML, CSS, and JS to make a compelling user experience. Generally speaking it takes more computing to render a UI designed with web standards than it does to generate a native UI. Web standards have mostly been evolved with a full desktop as the target rendering platform, so the expected amount of power available has scaled as the average desktop has increased in speed and memory. Mobile devices don’t normally have the same level of resource available, and even when they do, rendering a web based UI could force them to draw so much power that secondary issues like battery life are negatively affected.

This doesn’t have to be the case of course. Web rendering engines are evolving and getting better at pulling in hardware optimizations in a way that makes the web UI as smooth and efficient as a natively coded version. But there’s also a design time solution, forming your UI in a way so that it’s compelling to the user but also not overly taxing on the rendering platform. It’s a set of design skills that are relatively hard to find currently, but as mobile grows so does the number of folks with the right skills. One of the benefits of developing for the web instead of native is that you can deploy updates at will. Just like with any web app, just push a new release to the server and it’s available to all users. Normally with native apps there’s an update process that users need to go through, and at any time you might have users on two, three, or four different versions of your software depending on how frequently you update and how quickly your users update.

The standards questions relates to the formalized spec that covers what HTML, CSS attributes, and JS APIs are available for a developer to work with. Currently much of the functionality that ties into controls specific to mobile devices isn’t presented in a standardized way. The first major chunk of functionality that got exposed in mobile browsers was access to GPS data. For years there were different ways to get to that data through different browsers and on different platforms. Just now it’s settling down to the point where that bit of functionality has been standardized enough so that a developer only needs to know one technique for getting the data. That’s just one bit of functionality however, there’s access to the camera, contacts on the phone, accelerometer and magnetometer data – all bit of functionality that many applications can do without, but would be necessary if we want the mobile web to replace native for all applications. The problem is the standards process is slow. Even the people doing the standards know they’re slow, there’s just no easy fix for that problem.

Some folks say we don’t really need the standards to evolve in order to make the mobile web work. All we need is a critical mass of devices that all use the same APIs, and developers can target the set of devices they care about and ignore the rest. That generally leads to lots of complaints about mobile web developers being lazy, some folks feel it’s the responsibility of the mobile web dev to understand and target the different platforms out there. Other folks feel that toolsets will evolve to plaster over differences in browser implementations. Even if the standards don’t pull together all the functionality you want to use as a web dev, as long as the mobile HTML/JS toolkit you use gives a consistent interface to the underlying functionality that should be good enough.

And finally there’s the business issues. To be honest, this shouldn’t be a web app vs native apps issue, this is really an Internet vs app store discussion. If Apple decided to distribute digest form HTML5 applications via the app store, you could develop with web technologies and still get the benefits of the app store model. However, Apple doesn’t allow that, and if you want to look at a world larger than just Apple you need to think about how you get onto additional handsets. For those of you who haven’t been part of the discussion for a long time, “the app store model” means a model where some third party takes your application, helps to distribute it to users, and normally provides a payment system to go along with that so that you can charge for downloading your application. This is true for most of the stores (App Store, Marketplace, App World, Ovi). However, some folks like GetJar provide distribution but leave the decision (and all the profit) related to payment with the developer. This is in stark contrast to the standard web model, where anyone can get to any website. There is no good system out there for providing “paid web apps” as folks normally call them. Part of the value that the app stores bring to the table is a billing relationship with users. It’s relatively easy to get someone to purchase a new app when they’re already given billing information to iTunes. If you want to get someone to pay you for your mobile web app you’ve got to implement your own payment system. Most folks who try this don’t see great results. There’s a lot of checkout dropoff, people not completing the transactions. The set of motivations going on here is too deep to dive into in detail, so I’ll leave it as monetization on an app store is simpler from the developer perspective than it is with a web app.

The flip side of this from the business perspective is that there’s less channel risk with the web. Generally, no one can keep you from releasing your web app because they feel that another equivalent web app exists out there, or because they object to your application. In the app store there are plenty of stories about developers who spent months developing some application, only to have it rejected by Apple without a solid reason for why it was rejected. And there’s no real way to eliminate that risk currently. The only way to find out if Apple will reject your app is to submit your app. There are also very thick margins on transacting through the app stores. Generally the split is 70% to the developer and 30% to the user both for app sales and for any sales transacted in the application. Some folks think that margin is just too high. Others say that it’s the tax for having a mobile payments system that actually works. There’s no equivalent mobile payments system out there that seems to work at the same scale, so who can really say if that 30% is too large of a cut.

Hopefully that’s helped to lay out the set of issues, all huge problems each and of themselves. And many of the leaf nodes in the decision tree (like tools for mobile web development), are a whole set of conversation in their own right.

This is the part where I weigh in with my own opinion. So where does that leave us? Is mobile web development a viable option for reaching a mobile audience today? I think it definitely is. There are certain applications (highly graphical, or which need access to local resources) which don’t work out very well on the web yet, and certain business models (if you just want to charge up front and forget about the details) that aren’t as well supported in the web environment. However the web as a runtime for mobile has evolved to the point where you can deliver compelling applications, and there are certainly advantages with respect to getting to market and being able to iterate quickly. I’m starting to see startups begin to develop for the mobile web, and then plan to go native if they feel they need to. Over time I suspect that line with shift further and further out, with the web being the preferred way to get to market – getting augmented with a native version later on. With the assumption that over time less and less folks will cross that line to needing a native version.

Updates:

For those who couldn’t make it to the event UStream has a video of it online: Mobile Monday Native vs. Web apps.

Also worth a read is PPK’s post Native iPhone apps vs. Web apps.

If you’re interested in the deep tech end check out WhiterApps, James Pearce rewriting some native mobile apps to show they can be done just as well or better using the web.

Ronan has a Mobile Apps vs Mobile Web post up on mobiForge that does a great job of laying down the overall landscape, in particular the evolution from single platform to multiplatform.

7 2

However, I interacted with Nokia because a few people had said “Oh, you should definitely have an N8, lets get you one.” So now that the time has been wasted, I’m attempting to draw at least a little bit of positive out of it by sharing back with those who care about such things.

First, the point of a developer device program is to lower the activation energy necessary for a developer to put something together for your platform. Meaning, if you’re offering a program to get me a $500 device to encourage me to make something of value on that platform, you can’t just replace that $500 with an equivalent amount of annoyance.

The kick in the crotch I suppose was that I fell for it. There was lots of talk about Nokia getting developers back up and running on their platform. When a few folks said I should be able to get a device, for a minute, it sounded good. Then I filled out a bunch of forms, got up to the section with an NDA, and realize this was a loaner program. Doh! Well played Nokia! You almost got me.

Now I’m just annoyed by the whole thing. Annoyed enough I’m not going to head out to the Nokia developer event on Tuesday at CTIA, where supposedly they’re giving away N8s for free anyway. The three dozen people I heard this from all say it’s a secret. So shhh! Don’t tell anyone. Me, I’m torn between being convinced that enough people know about the secret that it’s probably a Nokia ploy to get more folks to the event, and just not caring about the platform. So instead, I think I’ll just watch the numbers, see if the platform seems to be headed for a turnaround at all, and fork over the cost for the device if the numbers say it’s worthwhile. See how that works?

Om’s other comment on stage, about Apple not having to buy developer love with million dollar contests – they just built a platform that developers wanted to be on. That’s also something you might want to take to heart.

6 1

Mobile Payments

• The characterization of the panel that Liz lays out is pretty fair, there was definitely a divide between folks who thought that NFC would have an impact and those who thought it was just an expensive stepping stone. Osama from PayPal, summed up the issue as “revamping point of sale vs eliminating it completely”. He stressed that with real world objects being increasingly networked there’s not necessarily a need to have a point of sale. Just indicate you want something right there in the aisle, which flips a bit somewhere indicating a given bit of merchandise is allowed through the doors without setting off an alarm. Smart, and a logical extension of the kind of “Internet of Things” discussions we frequently have.
• Geoff from Mastercard said that they’re working on enabling mobile transactions for unbanked users via Banknet, which sounded awesomely interesting. However, I can’t dig up any info about that effort.
• Geoff also spoke about incentives and coupons getting evaluated and redeemed right along with purchase, so I have to assume that the Mastercard world of mobile transactions sees the consolidation of folks like Groupon into payments instead of leaving them distinct.
• David from Zong was one of the folks who thought that the real value of mobile payments didn’t lie with revamping POS, he said that the value would come from offers, additional CRM hookups, and being able to tie into social networks.

Native Apps vs. Web Apps

• I think the choicest quote from the session was actually Ilja from GetJar: “An app is just an icon. If it’s a web app or a native app makes a difference to the technologists, but consumers don’t care.”
• Jay from Mozilla also made a fantastic point that I’ve been pulling at for a while, that what we normally lump together in the web apps vs. native apps argument around the technologies used to implement applications isn’t really the interesting discussion. The more important issues lie with distribution, monetization, search, and ratings. If Apple allowed web apps in the app store we might divide up the argument differently.
• Michael from Sencha made an interesting point in that he assumed web apps were going to start replacing native apps in the enterprise before the consumer space. He said the desire to avoid device lockin and keep developer productivity high would push enterprises toward the web. Interesting. I always assumed that the need to go cross-platform would push consumer services to the web. But because consumer apps would also give up a bunch of their existing distribution channel in doing so, I can see where he’s coming from. The reasons for not going web currently are distribution and monetization, and in the enterprise you don’t have those concerns. Good point.
• Krishna pointed out that if the browser is the entire OS then the distinction between native and web goes away. I’m sure the folks working on WebOS at Palm would agree.

Service Avatars

• Mike from ThingM laid out some pretty concise points. Anyone familiar with the concept of ubiquitous computing will find a lot of them familiar, but Mike put them into a great overall framework. He was urging folks to stop thinking in terms of individual apps or particular devices in the generic sense – but to think about services and how objects in the physical world can become the interfaces to those services. Don’t think of a camera as a device for taking pictures, but as a peripheral for Flickr.
• The overall argument was deriving from the reduced cost of adding computing. When it’s expensive to add computing to a device you only have a few devices that include computing, those devices need to be generic because they need to fill all the different roles. However, with computing getting less expensive now you can sprinkle it around as necessary, and make each instance of the tech more focused and differentiated. Most people just say “when computing gets cheap enough we might as well add it to everything”, this take of allowing the installations to move from generic to specific is a pretty significant twist on motivations, and a much more compelling framework.

There was actually a ton of additional interesting conversation, but I’m running up against my allotment of allowed blogging time for today. Diving through the tweets for #mobilize and #mobilizeconf should turn up some interesting stuff. Like Om asking why Nokia feels it’s necessary to buy developer love with millions of dollars in contest money instead of just building fantastic product the way Apple has, or the folks from Evri saying that apps effectively boil down to filters and that launching an app should be thought of as a search. Hopefully some of that stuff is out there tweeted, if not I’ll try to dig up some extra time this weekend to get some of it down.

6 0

I’m a developer, so the answer to that question has always been no. Although us developers are pretty much “pure” online interaction – we don’t have a lot of the need for offline interaction that lots of other professions do – everyone just assumes that if you’re going to be a developer you’re going to have a computer system of some kind. What if that wasn’t the case however? What if the knowledge of local conditions or business models trumped the other concerns? What are the tools you could use to get the job done if you had a business opportunity and a mobile phone, and that’s it? These are the kinds of questions that have been dragging me out of bed lately.

8 0

It made me think a lot about the shifting mindshare (or maybe share of attention?) going on in mobile. Back in 2003 and 2004 stuff like ubiquitous computing, RFID, and sensor networks were part of common conversation for just about everyone “working in mobile”. In 2010 when you mention mobility iPhone and Android pop to mind immediately, and the discussion only infrequently makes it outside of handset technologies. The attention goes where the money flows, not abnormal. But I was somewhat surprised to realize how long its been since I’ve thought about some of these things. And in some cases surprised to see how far some of the technologies have come even though they’re progressing effectively under the radar.

7 0

• Irv Henderson from Yahoo kicked off the topic with a presentation that included a sub-$100 phone that included a bunch of smartphone level capabilities (covered in detail by Dennis in his wrapup of business day). He was demoing the browser in particular, and how Yahoo is using the mobile web to reach all these devices that it would impossible to port to. Lots of other folks in conversations picked up the thread however. In particular I detected an edge of panic from handset and operating system providers whenever the name MediaTek was used
• Lots of talk, as always, about addressing the developing world. But the talk always seems to be very high level pontificating. My attempts to nail down even just one or two solid bits of advice for folks interesting in addressing that market with a new offering mostly came up empty. One bit from Purnima Kochikar did register however. She noted that in India in particular folks do not want subscription/bundle services. They would rather pay more for a single-serving version and be able to pick and choose on their own. She used the example of a video service that that charges a small amount for individual clips, and is doing quite well with the model. Practical advice FTW!
• From the developer day stuff I was blown away by how many folks are using PhoneGap. Most objections to using the mobile web can be answered for almost any platform with “well just wrap it in a PhoneGap project till that kind of thing gets fixed”. The Palm folks use it, Nokia uses it, the toolset folks use it. Fantastic to see.
• For a while I’ve been saying that tying more offline purchases into mobile will bring the real state-change we’ve been looking for in mobile advertising. It looks like the way that’s starting to happen is via geo-local advertising. It doesn’t sound like the standards have followed here (no one I spoke to knew of MMA or IAB standardized methods for specifying the geo info associated with ad buys), but folks on the panels claimed that advertising spend on local services was up significantly so far this year. Foursquare is the main driver of conversation here, but apparently couponing and incentive offers in apps like Yelp, on yp.com, and through Navteq LocationPoint are starting to open up the door. Those local ads tend to be drivers for real world commerce… so this should be fantastic news.

Probably my biggest realization however was how much mobile has grown. I actually learned a lot at Mobile 2.0 developer day, cause I’m just not able to follow everything interesting happening in mobile. 3 or 4 years ago that wasn’t the case, it was pretty easy to play with all the new stuff and be aware of all the activity. I just can’t do it any more though, it seems like every time I turn around there’s a new tool or technique I’m not aware of. I was chatting with Bruce Jones from GetJar about it, he’s been around for quite a while too. I was actually wondering if I’m just getting too old and tired to be able to cover everything, and he suggested that there’s just more going on. So it could be that he was just trying to make me feel better…

I don’t think that’s the case. If I take a look at the lineup of mobile related events happening this month it’s staggering. When we started doing this it was pretty much us and CTIA. Now there’s MobileBeat, AppNation, Mobilize, D4M, MobiTechFest, Think Mobile, and more. I think that’s a pretty solid indicator that the growth is real.

4 1

I’m a huge Android fan. My main phone right now is a Nexus One. I would actually like to see Android grow into a viable competitor for the iPhone. But there’s this huge glaring dark spot with respect to the number of handsets in the market determining the viability of the platform. If number of handsets out in the market really was the determining factor in the viability of the platform then Nokia would have already won. So obviously, it’s got to be a more complex issue.

So if it’s not number of handsets out in the market what would be the signaling factor, what else do we need to pay attention to? As far as third party developers go, their main set of concerns revolves around their ability to make money off their applications – either through direct sales or by monetizing audience. Right now the iPhone does that far and away better than the Android Marketplace does. Why?

I think a lot of it boils down to consumer disposition. Completely outside of the technology itself, it’s more of a marketing or psychology problem. I’m just not familiar enough with the terminology here to know what to call it. But the iPhone is a consumer pull, and Android is a service provider push. Apple seeded desire for the iPhone with a brilliant marketing campaign, and for the most part folks who get an iPhone genuinely want an iPhone. They know what an iPhone is and they know what they can do with it.

On the other hand, lots of the folks who end up with Android devices didn’t necessarily make a decision to get an Android phone. Snag someone in an elevator some time who has an Android phone and ask them why they got it. Generally they’ll say something like “it’s less expensive than an iPhone” or “I didn’t want to get on AT&T” or “I’m not an Apple person”. It’s not that they went out to explicitly get an Android phone, they just went out to get a good phone that isn’t an iPhone. What got sold to them was an Android phone. There’s a whole other discussion about if carriers are driving Android sales harder cause they’re making more off each Android unit in the field than they are off iPhone.. but lets skip that one for right now.

Because the consumer motivation started out different, their behavior ends up being different. I’m not sure if it’s causality or correlation, but Apple has setup the App Store in a way that it seems to drive a ton more sales than the Marketplace does. I’m not saying that the Android technique isn’t valid. Just that an equal number of Android handsets in the market does not make it on par with iPhone as far as third party developers go.

6 2

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.

7 1

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.

3 6

Even with that simple arrangement there is a degree of complexity to take into account though, mostly in the form of pricing. A high priced item is generally a higher margin item for the developer, but will also normally shift few units. Sometimes lowering the price so that you can get additional purchases will give you the extra lift you need to get into the charts, and the volume you sell will more than make up for the lower margins. It’s a very error prone process, because there’s so little hard data about individual applications available to the public. And even when you do have hard data it’s pretty hard to replicate previous successes because the marketplace is evolving rapidly.

Then there are a few hacks you can use to segment the two functions. The most common is having a free or low cost ‘lite’ version of the app and charging for enhanced functionality either via in-app purchases or having another version of the app with a different price. This allows the lower cost version to hopefully make it up into the charts for you and serve as a marketing function, while being able to keep the price of the full version at a point where the margins are a bit thicker without losing out completely on the exposure the app store itself can get you. The other option is to offer the main app for free and use some kind of in-app purchasing for segments of functionality or content, the so called freemium business model.

Then there’s advertising and affiliate programs. The success of advertising and affiliate programs is majorly a function of how large your audience is. The number of users your app has. And (just as important!) how often they use your app. It’s not very useful to try to advertise with a generic network in an app that’s been downloaded 3 million times, but only has 30 thousand active users on any given day. However the success of an advertising or affiliate program is also a function of how strongly segmented your audience is. For instance if you have 1 million users from all age groups and all walks of life, you might not have the kind of audience you would be able to find eager advertisers for. However, if you have 500 thousand users, all of who live in the San Francisco Bay Area, have indicated in some way that they’re at an auditorium or concert venue in the last week, and tend to be in the 18 to 25 age group – you could probably find someone looking to reach those people.

This is where the fundamental tension comes from. If you setup your app to do well getting directly sold through the app store (broadly appealing, low cost) you normally have to tilt things in the direction of that being your major monetization route. If you raise the price to where you can make decent money off the initial sale you’re normally also cutting the audience side down and limiting the scope of the advertising and affiliate programs you can run. Same thing with more directly targeting your app. If you make the app more specific and compelling to a smaller group of users, you can raise the price. But if you raise the price you usually also cut down volume.

This isn’t to say that you can’t come up with a targeted app that you can sell at a decent price, but also yields a good audience for advertising and affiliate programs. After all that’s what magazines do. They’ve managed to charge for buying the issue off the newsstand, but also take advertising money from companies who want a presence in that issue. However, I frequently hear the options expressed as either/or by app developers. They feel if they charge for the app they shouldn’t be running advertising. I understand where that sentiment comes from, but it’s not the way most other areas of business operate. I wish my cable provider didn’t run advertising in exchange for my paying for the service, but unfortunately that’s not the case.

Our first panel discussion at Mobile 2.0 developer day is going to explore a bunch of these issues, in addition to some talk about alternative distribution models I’m sure. Peter from Rovio is going to weigh in on how Angry Birds has managed to hold the #1 paid app in the app store for just about every region. They’ve sold more than 6.5 million of the paid application to date. Chris Dury from GetJar is also going to be present, he had some fantastic commentary at a recent Mobile Monday when he summarized the options available to developers as get featured, get targeted, or get viral. Sean from Flurry is going to be weighing in not just on the AppCircle system they have setup for promotion and monetization in-app, but also bring some numbers to the conversation from the huge base of info Flurry collects on the analytics side. Jahanzeb from iTeleport is going to represent the targeted side of the house, discussing how their app makes more than $1k a day without ever appearing in any charts at all. And finally Raj Singh is there to moderate, he’s worked with big companies, startups, and frequently his own efforts to find novel distribution and monetization models for consumer mobile apps and services.

If you want to join us at Mobile 2.0 use the promo code ‘friends’ for a 20% discount off the normal ticket price. Hope to see you there!

5 3

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.

4 2

Thanks to everyone who came out to participate and made it a fantastic night, it was a great set of conversations! Much of the conversation focused around distribution and monetization, those are the hot button items generally speaking. There seemed to be a decent amount of doubt from some of the audience however that one could put together a profitable business in mobile. Chris Dury from GetJar had a fantastic summary of the options a developer has: get featured, get targeted, get viral.

The featured one is usually the first one everyone talks about. How do you make it into that coveted top 25 list on the AppStore? Have a great app, make something with wide appeal, time your marketing and PR pushes for maximum impact, price appropriately for large download volumes. Lots of folks get ruffled feathers about this setup by the way. It’s called a hit-driven marketplace, borrowing a term that seems to have been reserved mostly for the gaming industry previously. Which means if you’re at the top of the pile you make a whole ton of money, but if you’re at the bottom of the pile you don’t make crap. And with more and more titles in mobile app stores, and big corporations with deep pockets participating, people argue that there’s no way for a small independent developer to make money in the app store any more. Bullshit – but still, it’s what people say. It just means there’s competition now, and that you can’t release junk and expect to make wads of cash. Most of us don’t expect that though, so it’s just a point to consider and not a market killer.

The second method is to figure out a segment of users you’re going to be generally appealing to, users who are willing to pay more than the general population for what you have, and spend some money to reach those users in a targeted fashion. For a fantastic writeup of the principles in practice, checkout the blog posting from the iTeleport folks about how they’re making money despite never making it up into the charts. They’re never in the top 1000 apps actually in any region. But they manage to make north of $1000 a day through AppStore sales. Really this is about basic business principles. I’m surprised how often I speak to folks looking at doing a mobile project who don’t have the floor nailed down here. The major questions you need to answer here are: how many users are there out there who match your segment, how much does it cost to reach a user, and how much do you make from each user. If there are enough users, and you make more off of them than it costs to get them, you’ve got a business. There’s nothing magic about this on mobile though. This would be the same if you were running a boutique clothing store, selling decorative masks on the street, creating a new line of dietary supplements, running a restaurant, etc. It’s just business. And good business is good business no matter where you do it, just as crappy business planning is crap no matter where you do it. If you decide to release a poorly implemented application with no differentiating features for $5 on a mobile app store and fail to make money, that’s not the app stores fault. If I decided to try to sell twisted paperclips for $10 a unit in Union Square and didn’t make money would it be the fault of Union Square as a business venue? No. It’s because you’ve built a business that isn’t good enough to compete. Own up, it’s a necessary part of progress.

The third method is to go viral, which really means not relying on the app store itself to get you in front of new potential users, but to rely on your current users “getting you new users”. I don’t want to get into this whole area of how viral transmission works, explicit sharing vs. data exhaust based linking. While it’s a great topic, it’s just too huge and complex. But if you want an example the most relevant today is probably FourSquare. I will point out however that viral can actually lie in perfectly well with getting featured or being targeted. Running a good viral campaign could get you the download velocity to get up into the charts and propel you even higher. And a well structured set of viral features could lead to you getting in front of additional targeted users if you plan things in a way so that your viral hooks tilt usage in the direction of a behavior you’re trying to support. Horrible simplification, I know, But that’s all I’m going to say.

So where does that leave us? How do you evaluate the potential of developing a mobile application as a business? It depends which of those vectors of transmission you want to appeal to. If you want to shoot for getting featured you really need to plan what you’re doing more like a physical goods business than in internet business. Way back in the dark ages of computers, before most of you were born probably, a major part of what software vendors used to have to worry about was distribution. There were physical boxes with install media in them sitting on shelves in a computer store. The concerns of software providers included things like shelf placement and how many stores they could get placed in. It’s still the way the console games industry works. And really, its the way a lot of the application stores for mobile work currently. It’s not that they’re physically limited the way that a store is, but by deciding to lay out their online store so that there are a limited number of slots they’re effectively taken digital distribution and forced it back in to the physical square-footage model of software distribution. Along with all the benefits and detriments that go with it.

If you don’t want to just spin the wheel on getting featured you’re going to have to do some additional planning however. We’re at the very beginning of a pretty major shift in the way that services are delivered. A few years ago it was a very small minority of folks who were thinking about how ‘mobile’ fit into their overall service plan. Now it’s pretty much taken as a given. Simply put, the model hasn’t been able to absorb the interest. Some of us are working on trying to figure out how to bridge that gap. How do you wring the inefficiencies out of the app world and allow for an environment that can see the kind of proliferation of services we saw on the general internet? We’re not there yet. So it takes some additional planning to avoid getting lost in the noise of the marketplace. But the potential is very real. Just take a look at the usage and adoption numbers. If that’s not a market worth going after I’m not sure what is.

5 1