It’s the Experience, Stupid [Advice to Mobile Providers]
August 4th, 2008
Two years ago, my colleague Isaac went to SXSW, and came back with a presentation on Mobile Development. In it he said that one of the greatest challenges is getting a mobile application “on deck”. “On Deck” is the term used for an application that’s available on a provider’s mobile platform, that place you goto online when you browse applications, ringtones and such, and to get something on there used to take an Act of God. Why? Because all billing had to be handled through the provider, all sales had to be done though your phone bill, and payments to third party companies had to be set up through their system (and usually required a hefty premium). In short- more trouble than it’s worth. Fact is, this is largely still the case. Yes, with greater adoption of mobile web browsers these things are becoming a lot easier, yet getting an application onto a phone remains problematic, especially if the consumer isn’t aware that you have it. The best option these days seems to be building a Mobile website, which is a far cry from a good user experience.
So lets talk about the consumer for a bit, in particular the consumer described in The Long Tail. Here is an individual who knows his/her own lifestyle and needs, who like particular applications over others, whose preferred experience with one service might be different from his/her neighbor’s experience for the same. This is an individual who, when presented with a Smart Phone, wants to have features and applications behaving a particular way, and will only put up with the provided options of the telco because there’s no other choice. In short, they have a craving for personalization, and will gladly move to any platform that has applications that meet their needs.
Deploying a mobile application to meet these needs is, in its simplest form, the following: First, you must have a developer able to access your SDK, platform and testbed with minimal fuss. Then, that developer must be able to deploy his application to a location where a potential user may download it onto their device. Lastly, the device must be able to run said application. These three tenets of Develop, Deploy, Consume can be easily seen on the regular web. Developers have their SDK’s, Deployment happens on a web server, and browsers allow consumption of the offered services.
In the mobile world this isn’t quite as simple. Yes, there are many websites now that have mobile components, yet lets face it: The form factor and memory constraints of mobile computing devices make it so that few applications can offer full functionality and experience while constrained by regular browser controls. Additionally, we are back to (for the time being) the computing world of the early 90’s, where applications are restricted by processing and memory constraints. Back then, however, we could load applications from Floppy disks, something that’s not so easy on a mobile device. The development platforms exist, but deployment (as noted above) is extremely difficult, and the broad diversity of devices makes your target installable base problematic at best.
So let us take a look at the various players in the mobile market right now. First of all, let us look at the telecommunication companies, those that have the aforementioned problem with getting something On Deck. From their perspective, they have control over their delivery platform, and getting something from their platform to a mobile device is simple enough, however their process is such that they have completely lost their developer base. There are too many devices, too many different platforms and form factors, and deploying an application is simply too difficult for any developer to bother building something. Imagine the computing world in the mid-80’s, and you’ll understand what I mean.
Next let’s take a look at Microsoft, which in our case will also double as any company that has a mobile application which they want to deploy. Microsoft has historically been brilliant in its developer support tools, so much so that it’s stupidly easy to develop an application for their operating system. Similarly, the fact that they are in the software and not the hardware business lets them sell a platform rather than a device, which allows mobile manufacturers to create devices that can run any application built for it. The place where they have failed, however, is in securing and simplifying the delivery platform, which remains under the control of the telco’s.
Third, let us look at Google and Android. Here, the development platform is easy to access and has some brilliant development tools. And… then what? Well, frankly, we don’t know a whole lot about how Android will be delivered, because while many manufacturers and providers have jumped on the bandwagon, we as of yet have no idea whether Android will use an open application deployment platform, or even whether phones built by their manufacturing partners will come with Android pre-installed. The suggested promise of Android is Build Once, Deploy To Any Phone, but if it means that a developer still has to get something On Deck with a Telco, you will once again be in the same boat as Microsoft- a common platform, but no control over application distribution.
I should note here that I doubt Google will not have some central application service, it simply hasn’t been announced yet.
Lastly, let us come to Apple. In this case I have to make a special note, in that while I recognize the SDK is publicly available, it is unfortunately not available for Windows (No, Aptana junkies, that’s just a web browser). Thus while they have alienated a good percentage of computer users overall, the additional cost of an OSX development platform is comparatively minor, and won’t detract a company interested in building an iPhone application. Taking that into consideration, they have everything buttoned up. Developers can access the SDK, they have an established and largely ubiquitous deployment platform not tied to the telco, and they have a device that will run any software built. This end-to-end solution is exactly the same thing that made the iPod so successful, because it got a user from Purchase to Play in one smooth experience.
And no, I don’t own an iPhone.









re: “The best option these days seems to be building a Mobile website, which is a far cry from a good user experience.” …
One major change in the Mobile Web ushered in by the iPhone (and I’m not going to talk about its SDK) is the WebKit browser, which powers the iPhone’s Safari browser. What signficiant is that Webkit is now being put on to most of the forthcoming models of mobile phones. Have a ubiquitous and full featured browser on mobile devices is a hige advancement over the fragmented, feature-poor, and curious assortment of mobile device browsers in the past. Moreover Webkit supports Ajax development well paving the way to significantly better user experiences on the mobile Web. Thanks for mentioning Aptana and I know the focus of your post was not on the mobile browser apps, but one can certainly achieve a good user experince these days using Ajax techniques. Ajax libraries like iUI are optimal for Webkit and and mobile device screensizes. Moreover iUI now has Christopher Allen at its helm and is poised for further, signficant enhancements over the coming months. If you want to give iUI a try, Aptana Studio’s iPhone development plug-in includes it (along with code asssit, mobile device web app debugger, iPhone screen preview and other userful features, or you can also just get it from the iUI site.
–Kevin H @ aptana.com
..and I forgot that the iPhone development plug-in for Aptana Studio also includes several Ajax samples for the iPhone showing the kinds of richer user experiences you can deliver today.
more @ http://www.aptana.com/iphone
Well put Michael. Having recently bought an iPhone I can attest to them having got the formula mostly right. Some day I’m going to have to learn Objective C to write some of my own apps.
Re: Kevin
It is exciting that WebKit is being more broadly deployed on mobile platforms however, it is still very much in it’s infancy. As of this writing it only ships on a very few phones available in the US, notably the iPhone, and Nokia N95. It is available for WinMo6 http://www.torchmobile.com/, which could open up the install base. But most phone on the market today have very limited processing, even my Nokia N75, a considerably better than average phone, had very poor responsiveness on most websites. But, as they say, innovation lives on the edges so thats still a gtreat place to be looking to for some new breaks.
I’m inclined to think that the web based interface will always be less perfomant and usually have a poorer user experience than native or even bytecode compiled applications like java and flash because of the overhead HTML and JavaScript parsing and interpretation. But web apps are certainly easier to develop and will most certainly be where my first concentrated effort will lie.