Fixing Mobile Messaging

Posted on November 15, 2010 by miker

SMS is a fantastic service for person to person communication, but just about every other aspect of it is broken. Lately I’ve been paying a lot more attention to messaging because of the mobile web. It’s a current area of drastic disparity between native apps and web apps on mobile, and something that keeps folks tied to a particular platform. SMS sucking is why we have cloud to device messaging for Android and iOS and BlackBerry specific push APIs.

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!

Posted in Browser, Community, iPhone, Technology, ThisIsMobility | 3 Comments

Under the Radar 2010

Posted on November 13, 2010 by miker

I spent the day yesterday down at the Under the Radar conference in Mountain View. Awesome job once again by the organizers, who managed to pull together plenty of interesting companies I wasn’t yet familiar with and a great set of judges. I reconnected with a bunch of people I haven’t seen in a long time too, so awesome day all around.

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.

Posted in Business, Community, Technology, ThisIsMobility | 1 Comment

Top Startup Legal Mistakes

Posted on October 28, 2010 by miker

The topic for November at Mobile Monday Silicon Valley is Top Startup Legal Mistakes. I’ve been talking to a whole boatload of startups lately, and this seems like a really timely topic. There are a lot of folks out there looking to strike out in a new direction. While there are some awesome resources out there to give folks a bit of a lift (see the Series Seed public funding documents for example), there’s still a lot to wrap your head around if you’re starting out for the first time. So we pulled together a few lawyers who have been through the process plenty of times before to point out the common things to be aware of and discuss how to make sure you avoid the most difficult issues.

Posted in Business, Community, ThisIsMobility | Leave a comment

Sizing an Advertising Market

Posted on October 23, 2010 by miker

There was a decent amount of discussion about the virtual goods vs advertising numbers that Flurry released. Awesome set of numbers they put together there, thanks for sharing them!

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.

Posted in Business, Community, MobilePayments, ThisIsMobility | Leave a comment

Mozilla Open Web App Prototype

Posted on October 20, 2010 by miker

I think this prototype of an open web app system from the folks at Mozilla is quite interesting. First thing to note is that it works currently on Android and iPhone devices even in the prototype version they have up. Not mobile specific rendering on some Android devices, and there are a few issues with links in overlays, but the core is working.

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.

Posted in Browser, Community, Open Source, Technology, ThisIsMobility | Leave a comment

Thank You Twitter and Facebook

Posted on October 13, 2010 by miker

Getting people to build mobile websites has been an uphill battle for a long time. We had a chicken and egg problem. People didn’t browse the web from their devices because the experience was horrible, and website owners didn’t make mobile optimized versions because people didn’t browse from their devices. That’s all changing now, quickly and drastically. I just want to pause for a second to recognize both Twitter and Facebook for their role in making it happen, cause between the both of them they’re the major drivers of adoption of the mobile web based on what I’m hearing.

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.

Posted in Browser, Community, Technology, ThisIsMobility | 3 Comments

CTIA 2010 – OMS Pitch Sessions

Posted on October 8, 2010 by miker

Yesterday I attended and participated in a subsection of the CTIA show organized by Jai from Open Mobile Solutions called developer pitch sessions. There were some interesting presentations in there, and some great conversations. Here are a few of the bits I thought were worth mention:

  • 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.

Posted in Community, ThisIsMobility | Leave a comment

Apps vs Web Apps Recap

Posted on October 6, 2010 by miker

We had our Apps vs Web Apps discussion at Mobile Monday SV Monday night, and unfortunately lots of folks thought we didn’t really do the topic justice. I want to thank Raj and the panel participants for making a go of it, I think they did a great job of covering a ton of ground. This is by no means a criticism of them, just an attempt to summarize and extend the conversation and feedback that came up after the panel. Which actually is a fantastic sign. Most of the time when I talk to folks after a discussion at MoMo they don’t have a strong opinion. But this time we definitely got some reactions! So maybe we did do our job well after all :-)

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.

Posted in Community, Mobile Monday, ThisIsMobility | 8 Comments

Developer Device Programs

Posted on October 2, 2010 by miker

I don’t have an N8. Apparently some folks at Nokia are surprised by this. Maybe they bought into the corporate line about Nokia really caring about developers these days. Nokia gave Om a phone at Mobilize (and his “Thanks, but do I have to use it?” response probably sums up one of their flaws in gauging the right avenues for promotion), a few of the business folks at Mobile 2.0 had one, but I don’t have one. Normally, this wouldn’t surprise me actually. Despite all the talk about companies who love developers, what they really mean is they love folks who blog about developing. Those of us who just keep building high value businesses and aren’t necessarily quite so vocal, not so much.

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.

Posted in Community, ThisIsMobility | 6 Comments

Mobilize 2010 Wrapup

Posted on October 1, 2010 by miker

I was at Mobilize 2010 yesterday. Fantastic event! Congrats to the whole GigaOm team, great job. Here’s some of the stuff that really stuck out for me:

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.

Posted in Community, Software, Technology, ThisIsMobility | Leave a comment