Two weeks ago, I asked why mobile application sales are dropping. A great discussion followed, with many different perspectives (if you haven't read the comments, I encourage you to check them out).
To me, one of the most striking comments was the one no one made – nobody came back and said, "you're wrong, sales are actually going well." I think we have a consensus that there's something wrong with sales of sophisticated mobile data apps – native apps that are more than just games or ringtones.
There are two schools of thought on why app sales are down. One perspective is that the market was a mirage in the first place – most people don't care that much about mobile apps, and to the extent that they do, mobile browsing is a good substitute. I think this perspective is growing quickly among industry insiders, and even someone from Microsoft largely seconded it.
Another interesting example of this view is the weblog i-Mode Business Strategy, which tracks adoption of i-Mode data services. It's carrying a lot of quotes from operators and others saying that a mobile device should be focused on a single purpose, and the whole idea of deploying a lot of different apps or functions is low-value.
"All i-mode applications are in fact secondary, the primary being the voice. The secondary applications typically struggle through out their life cycles for the lack of focus and synergy."
The other perspective is that a diverse market for mobile data exists, but we just haven't tackled it correctly yet. For example, Bob Russell at Mobile Read wrote a very kind commentary on my post, but also strongly encouraged people not to panic and give up on the future of mobile data. Several of the other replies to my post echoed that theme.
I'm somewhere in the middle. As I've written before, I believe that a mobile device has to solve a compelling problem before people will buy it. Solving fifteen problems is too hard to market, so there needs to be one flagship function or usage that gets a device sold in the first place. In this respect, I think the "mobile device = appliance" folks are right.
But once the user gets a mobile device, I think many customers will allow it to blossom into more usages – if that blossoming process is handled properly. That's where I think the mobile data world fails today, and that's what I think we need to fix.
The role of mobile data
When I started work at Palm in 1999, I was already using a handheld to track my calendar and contacts, but not much else. I was lucky enough to get a cubicle in the middle of the developer relations team, who taught me all about the third party apps that were just then starting to take off for the platform.
The variety was so huge that I'd spend hours browsing around on PalmGear, picking out new things to download. Many of the applications turned out to be things I tried once and never touched again, but a few filled meaningful roles in my life and I came to depend on them.
There was my buddy Convert-It, which converts between English and Metric measurements (a must for any competitive analyst based in the US).
Tide Tool tells me when it's a good time to go tide pooling at the beach.
Mars Clock lets me track the time of day on Mars for the Mars Rovers. (Why does that one matter? Because if you're browsing the Mars Rover pictures that NASA posts on the Web every day, Mars Clock lets you convert between the Mars days that NASA lists and actual Earth days – so you can figure out when a picture was taken.)
This is a treasure chest
To me, the Palm Launcher became a treasure chest of useful little software gems, things that enhanced my life and made me happy. But I discovered that my gem collection was different from everyone else's. Tide Tool didn't matter to most people, and Mars Clock was interesting only to the fanatics who followed the photo stream from the Mars Rovers. Other people had their own favorite apps that I didn't care about.
Even among the Palm enthusiasts, there was never a single "killer" application everybody used. Instead, everyone had a different set of personal killer applications that met their own individual needs. Each person was a vertical market of one, the exact opposite of a mass market.
I discovered that when I was talking with potential customers or the press, I could hook almost anyone on Palm if I had fifteen minutes to show them the range of software available. But you can't spend a quarter hour per customer on a product that sells for only a couple of hundred dollars – that's a great way to go broke slowly. So we started to look for mass market ways to have that conversation.
At one point Palm planned an extensive TV advertising campaign for the range of applications, called "The Perfect Day." The first commercial was already finished when the tech bubble burst and Palm's stock value collapsed. The company decided to cut expenses, and the commercials were the first thing to go. The video was shown at a few trade shows, and that was all. (I tried to find a copy of the commercial online, but couldn't. If you know where to see it, please post a link.)
Later, when I was at PalmSource, we didn't have nearly enough money to do TV ads, so we tried to use the Web to spread the story. The result was something called the Expert Guides, a set of about 50 volunteer-written guides to applications for Palm OS. I'm more satisfied by these guides than I am by just about anything else I was involved in at Palm.
If you want to understand the power of mobile data software, and what it can mean to a person's life, browse some of the Guides. The ones on personal health, aviation, and professional medicine are especially impressive, but you can also find quirky things like cigar and liquor software, scuba diving software, and software for various religions.
In addition to creating the Guides, we ran a couple of contests soliciting first person usage stories from users. They were big successes, generating several thousand stories. They ranged from comical to heart-wrenching – people using handhelds to overcome disabilities or start new careers. Almost every story featured different apps. One story I remember in particular was reprinted in the Aviation expert guide:
"I'm a Mission Pilot with the Civil Air Patrol, the auxiliary of the U.S. Air Force. Installed on my Palm Powered device (a Tungsten T now, but over the past six years I've owned an i705, Palm Vx, Palm IIIx and Pilot Professional) are several aviation application including the Airplane Owners and Pilots Association (AOPA) airport directory. It contains virtually all information about thousands of airports across the US. On a January 11 night flight over northeastern Oklahoma, we heard a pilot call over the radio that he was having difficulty finding his destination airport in the darkness. He was alone and his charts were inadequate, out of date or missing. While my crewmember dug through his flight bag of charts, maps, directories and other guides, I pulled my Palm i705 out of my flight suit, turned on its internal light, opened the AOPA eDirectory and found information on the airport that this pilot was flying to. Within 60 seconds, my radio call advised the lost pilot of the airport's location, frequencies, hours of operation and instructions for turning on runway lights and rotating beacon from his aircraft. And my hands never left the flight controls. Is the Palm a great device? You bet. Is there a wide variety of software for use on it? An unbelievable amount. Is it convenient to use, even while flying an airplane? Absolutely. A lifesaver? The other pilot would certainly say so. And it's never farther away than the front pocket of my flight suit."
We had a database with several thousand of those stories. We never figured out what to do with them, other than list a few of the best ones in the Guides.
Based on all this interaction with customers, I an utterly convinced that mobile data, and all the myriad applications associated with it, will eventually be a very common, well-loved part of the lives of huge numbers of people around the world. This stuff is just too useful once you really dig into it.
I'm also convinced that conventional marketing won't make mobile data happen, because the compelling thing about mobile data isn't the total number of applications – it's the individual discovery of an application that does something critical just for you. We have to find a way to explain mobile data differently to every individual person.
After you think about it for a while, the right place – maybe the only place – to explain this is on the device itself. I think the right way to do it would be something like this:
When the user first gets started, the device asks the user a few questions about their work and interests. Based on the user's responses, the device suggests the installation of appropriate software. So, for example, if the user is a doctor and a boy scout troop leader, the device suggests a selection of medical software, and a boy scout troop management program (yes, there's an Expert Guide on that, listing about 70 relevant applications, including knot-tying instructional software -- something critical for a Scout). If the user agrees, these are downloaded to the device, and the user's wireless account is automatically charged for them. If the user doesn't agree, the device makes it easy to come back and buy the software later.
By customizing and automating the whole application shopping process, we make it easy for people to discover what they can do and get used to the idea of using their device for more than one purpose.
I think this integrated discovery and install process is the key to making mobile data take off.
Why hasn't it happened already?
If the right thing to do is so obvious, why hasn't some mobile OS company done it already? I spent the last seven years wondering about that question, and never got a satisfactory answer.
But I get it now.
Making real, personalized mobile data succeed isn't in the critical interest of any of the powers in the mobile design chain.
Hardware vendors focus on the lead solution that's built into their device, because that's what drives the hardware sale. So, for example, Palm has a strong incentive to spend all its time making e-mail on the Treo work great.
The OS vendors focus on the needs of the people who control their sales. That means supporting the feature requirements of the mobile operators, because they're the ones who decide if devices with a particular OS will be offered to users.
To an OS company, the operators are a feature requirements black hole, an "endless aching need" in the words of Bette Midler and Amanda McBroom. There's always one more feature they want implemented, or one more deal you can close if you just respond to a request. These opportunities expand to consume all available engineering resources, no matter how many engineers your company has.
I finally understood this a couple of months ago when I was talking with a former Palm employee who had moved on to one of the biggest mobile-related companies – a firm so huge that you'd assume they have enough engineers to do anything. We were talking about flaws in the user interface of a new product the company had released.
"Hey," I said to my friend, "You're on the inside now. Why don't you just call the product manager and explain to him what's wrong?"
"I did," my friend replied. "But the product manager said all the engineers are busy answering operator requests, and there's no one left to work on user features."
"There's no one left to work on user features." If mobile data fails, you can carve that on the tombstone.
We need a new platform – sort of
If we can't count on the OS companies to make mobile data work, then the obvious answer is to get away from the OS companies. Separate applications discovery, purchase, and compatibility from the underlying OS. Let the OS company serve the needs of the hardware companies and operators, while this new software layer serves developers and users.
What we need isn't a new OS, we need a new software layer on top of the OS.
I think that software layer should include:
--The APIs needed to run the applications, consistent across all devices so developers can write once and run anywhere (think of this as Java done right). That creates the largest possible market, encouraging the creation of the focused vertical applications that drive mobile data adoption.
--The software discovery and sales experience. The whole chain from learning to purchase to billing to installation should be built in, to make it effortlessly easy for people to try and install new mobile apps.
--The billing system needs to be managed carefully. The right thing is take a sustainable, restrained cut of developers' revenue and grow along with them. Many online mobile software stores take an enormous cut of the developer's revenue. That doesn't cultivate a developer community, it's more like running a McCormick harvester across it – you bring in an impressive harvest for a little while, but in your wake you leave an empty field of stubble.
--An open garden. Any developer should be free to add an application to the store. Real mobile data is so diverse that no entity on this earth is capable of determining in advance what people will want. Rather than trying to pick winners, the platform vendor should take a uniform cut from everyone and let Charles Darwin choose the winners. Better yet, put in a user rating system to help the best apps rise to the top.
--Sandboxing. Because anyone can publish an app, the software layer should be thoroughly sandboxed so that a rogue app can't mess with the phone network. This is much easier to do when the layer is built on top of the OS rather than within it.
--The layer should include enough of the user interface so that developers don't have to rewrite their apps for every different device.
Which companies could make it happen?
No one's putting together the whole offering yet, but there are some promising possibilities...
Adobe Apollo. Adobe says it's creating a software layer that will run on top of both PCs and mobile devices. Adobe has enough financial resources to make the necessary investments, and operators are anxious enough to get Flash content that they might agree to bundle Adobe's software.
But to succeed, Adobe would need to give away Apollo. Today the company is charging for Flash in the mobile world, which will limit its deployment and prevent the creation of a standard. Also, Adobe hasn't shown any signs of including application discovery or purchase in Apollo.
Microsoft WPF. Microsoft is working on a software layer that's conceptually similar to Apollo, called Windows Presentation Foundation. Like Apollo, it's not clear if WPF will include the software discovery and purchase experience. Also, Microsoft is holding some features out of the cross-platform version of WPF in order to prevent it from cannibalizing native Windows sales. That's a very difficult line to walk.
Nokia S60. Nokia's S60 software is closely tied to Symbian, but the company could theoretically separate it and offer it as a layer. I have no idea if that has been considered, or how hard it would be to implement. Nokia has been making some efforts at improving the app discovery experience, including the recent announcement of the "Nokia Content Discoverer," one of the most awkwardly-named software products I've heard of in the last five years. I like the idea, though – it's supposed to help people find content and apps. I haven't been able to find any pictures or video of the product in action. If you're aware of any, please post a link in the comments below.
Nokia's other handicap is that it's very closely tied to the operators. It would have to hive off resources to support the apps platform separately from operator influence.
StyleTap. This small Canadian company has created a Palm OS emulator and is selling it for use on Windows Mobile devices. So you can run most Palm OS apps on Windows Mobile. There's no software discovery element, but it is a nice software layer, and could be evolved into a layer for all mobile devices. Unfortunately, StyleTap is charging $30 a pop for the emulator. If they wanted to become the mobile software layer of the future, they'd need to give it away and make money through app sales. I doubt a company of their size can afford to do that.
Brew. Qualcomm's Brew has one of the nicest software downloading and billing infrastructures I've seen, and includes a set of APIs. So it's a full software layer. Its two problems are first that it's made by Qualcomm, a company that already holds – and charges for – many fundamental mobile patents. The last thing mobile companies want to do is give Qualcomm more control over their lives. The second problem is that Brew is set up as a series of closed gardens. The operators choose which apps to offer, and there's no discovery experience that I'm aware of. So I'd classify Brew as great technology hamstrung by a completely wrongheaded business model.
Savaje. This company has gone through a full cycle of being unknown, hyped into extreme prominence, and then dropped back into obscurity. What they're trying to do is fix Java, by making it consistent across devices, efficient, and wrapping a better business and technical infrastructure around it. The question about Savaje has always been whether or not they can deliver. I'm not close enough to them to judge that, but if they get their act together they could be a promising option.
I know I've skipped a lot of other candidates, but hopefully you get the idea (if I missed your favorite, feel free to post a comment about them). There are a lot of companies trying to make various sorts of software layers, but most of them are focusing on the APIs and technologies, the traditional control point in the PC world. That's nice, but what's really needed is a new business layer and infrastructure, not just another set of APIs. I think the first company that realizes this will be the one that drives the blossoming of mobile data.
I hope it'll happen soon.
One problem we've had is the almost nil extensibility of mobile programming environments. By that I mean that while I can set up any nice all-in-the-box app I want to, I have ENORMOUS difficulty writing an app that needs to receive a stream of data from any novel hardware or technology (eg, [x,y] coordinates on a non-touchscreen enabled device).
ReplyDeletePartly, this is because current devices are still very limited in terms of multi-tasking functionality, and partly because FlashLite et al are closed boxes. But it requires strenuous hacking and runaround for us to demo the truly novel stuff. And truly novel is necessary to keep the paradigm moving forward.
Thanks for the great discussion -- keep it going!
It's a very interesting post which seems to simultaneously say so much that is right but ultimately misses. I think I'll blog a longer response, but in essence there are very good points here but everything is 1) PDA focussed and 2) because of this not going to happen in the next 3-5 years.
ReplyDeleteIt is absolutely right that every user will have their own personal killer apps - but note that all your example Palm apps could be done on any MIDP1 device. There is no need to (if you'll excuse the term) fantasise about a ubiquitous smartphone platform (S60, Windows) or other dev environment (Flash) to achieve them - of course some apps need advanced functionality, but I found it very interesting that none of your examples do, and I think most other 'killer' apps will be relatively quick simple affairs too.
The high-end platforms listed here need high-end hardware and the market does not exist for that - your airline pilot may well buy a top-end device, but most of your cub scouts, cigar and liquor users, and medical staff probably won't, like over 90% of the rest of the world's population. If you pin your hopes to these platforms you also must admit that the market you want will not occur for many years, until the hardware and battery performance drops significantly in price. Even if 100% of phones sold over the next year were smartphones, they'd still add up to much less than half the installed user base you're trying to sell to. So the answer has to be work with what you've got, and use a mixture of in-house and 3rd party APIs to cover over the shortcomings.
It's worth remembering that mobile dev will always be like extreme cross-browser web design - juggling screen sizes, speed and memory differences - and the APIs can't coddle the user completely from this. Things can always be better, but realistically the only reason the newer/smaller platforms are less fragmented is that very few manufacturers support them. MIDP is maturing (very slowly), bugs will always exist in any platform but they seem to be happening less frequently as the mainstream implementations mature (round the edges there are obviously nasty problems still, but none of these devices sell well enough to be that important - we haven't had a T610 or 6600 in a while).
Offering to customise a device with 3rd party apps is a lovely idea which IMHO would always lead to two problems - who decides which apps are listed, and how much would you have to pay them to get listed? Answer: 99% of the time it will be operators deciding, and they always want lots of money. Nice idea, couldn't see it ever working in practice.
If we assume that we must make our money selling apps for hardware that people have now, we have one global choice with two additional regional options: MIDP, with DoJa the only serious platform for Japan and BREW useful for the US and some other markets. BREW handles the content discovery side excellently, but content cannot reach the consumer without paying a lot of money to Qualcomm - great for some products (like game franchises), no good for small volume personal apps. J2ME is abysmal at the content discovery side, but it is nearly ubiquitous. Operator portals offer some of the content discovery advantages of BREW for J2ME, alongside all the cost and selection implications. This side has to be improved, no question.
I think off-device initiatives can help, as can compelling free content eg. as part of marketing promotions, driving user adoption like SMS voting did without the users having to understand the technology side. An excellent scalable good looking UI platform on top of MIDP would also be nice, but unless it can be retrofitted to older devices it will go unused for a long time, and that is even more true for any other platform.
Apologies for another J2ME rant, but ultimately unless you are producing apps for a well defined niche and doing well from it, I can't see why any developer would ignore 80-90% of the market. Then again speaking as a J2ME specialist don't let me stop you, leaves more work for me :)
I agree with most of the comment of previous poster. Your comment are too much PDA oriented, and I do not think that phone needs a PDA. PalmOS was good for tech people who wanted to spend some time to find the right application, but it's far from being a mass market approach.
ReplyDeleteThere is already enough so-called ubiqitous platform (J2ME being the biggest one, but Flash, Brew, Symbian are others )!
I agree on one strong point, is that discovery mechanism needs to be improved. Many people are working on solutions on this point, the main trend being the "ODP" -on device portal- which propose a better discovery mechanism than traditionnal wap browsing, through advanced features like recommendation or profiling.
Several offers already existis, most of them on Java, few on native OS.
So this is already coming, the next step is probably a better integration with the handset, for instance for a preinstalled application....
Cool comments. Thanks, everybody.
ReplyDeleteSarah wrote:
>>One problem we've had is the almost nil extensibility of mobile programming environments.....I have ENORMOUS difficulty writing an app that needs to receive a stream of data from any novel hardware or technology....it requires strenuous hacking and runaround for us to demo the truly novel stuff. And truly novel is necessary to keep the paradigm moving forward.
Okay, so by suggesting that this software layer should be completely sandboxed, I'm making the problem worse. Good point.
It feels like there ought to be a way to protect the phone network while still giving the developer a nice set of capabilities to be creative with. But it'll require very careful architecting of the APIs -- and the more cross-platform the environment is, the more abstracted you'll be from the special features of the hardware.
I wish I had a good answer to this one.
Raddedas wrote:
>>note that all your example Palm apps could be done on any MIDP1 device.
Absolutely correct. My main point is that the truly broken part of mobile data is app discovery, installation, and payment. I guess I didn't make that clear enough.
I think you and I don't actually disagree on all that much.
>>There is no need to (if you'll excuse the term) fantasise about a ubiquitous smartphone platform (S60, Windows) or other dev environment (Flash) to achieve them
I'm fine with the platform being Java (that's why I mentioned Savaje), but you need a vendor driving it who can fix the problems and get the right infrastructure deployed across different operators.
But I don't think the platform has to be Java -- I believe the failure of mobile Java to drive a really robust mobile data ecosystem has left the door open for a different layer to establish itself.
Rather than fantasizing about platforms, I was trying to fantasize about who might have the will and the technical and market resources to drive a standard.
>>The high-end platforms listed here need high-end hardware and the market does not exist for that
I agree and disagree. Most people won't pay for high end hardware, but midrange hardware is affordable by a lot of people and it has a fair amount of power.
Again, though, I don't have any problem if the API layer is Java. Whatever works.
>>It's worth remembering that mobile dev will always be like extreme cross-browser web design - juggling screen sizes, speed and memory differences - and the APIs can't coddle the user completely from this.
Agreed, but I think they could do a lot better.
>>who decides which apps are listed
They all should get listed, like Amazon. The company creating the discovery experience should make it easy for a user to navigate this complexity. It's all about that startup and recommendation experience I described.
>>and how much would you have to pay them to get listed?
Nothing. A developer creating an app for your platform is doing you a favor. You don't charge them for that, you thank them.
>>Answer: 99% of the time it will be operators deciding, and they always want lots of money.
Somebody -- maybe an MVNO, maybe a more progressive operator -- will realize they need to work with developers differently. Once they do it, and real mobile data takes off, the others will be obligated to follow suit. It may well take a while, but that's exactly why I'm trying to explain the process here -- so we can nudge it along.
>>I can't see why any developer would ignore 80-90% of the market.
If they have to pay big bucks to get listed, and no one can find their app, and they have to rework their apps for every phone, a lot of developers would be happy to ignore that market. And that's what I see a lot of them doing.
If app discovery and billing works dramatically better on 20% or even 10% of the mobile devices, I think a developer might make more profit there than they would on the other 80% of phones.
Depends on the type of app, of course.
Tom wrote:
>>Your comment are too much PDA oriented
From my perspective, my comments wre oriented toward mobile data, not PDAs. For most people, PDA = electronic calendar. That's not what I'm talking about. I did want the PDA to grow into true mobile data, but it didn't. I now hope the mobile phone can grow into a real mobile data device. We'll see.
Over time, what I'm describing is definitely a different beast from a voice-only mobile phone.
>>Many people are working on solutions on this point, the main trend being the "ODP" -on device portal- which propose a better discovery mechanism than traditionnal wap browsing, through advanced features like recommendation or profiling.
Several offers already existis.
I'd love to look at them. Can you post a couple of URLs?
Michael wrote:
>>I happen to have a copy of the Ad
Thanks! The ad's not quite as sexy as I remembered it, but you can see how it was trying to reposition the device as much more than a calendar/address book.
I sure wish the company had run those ads. They might have changed a lot of subsequent events.
Or maybe they would have done nothing. We'll never know.
Difficult issue to tackle this as I don't think there's one obvious answer (otherwise it would have happened). I agree that distribution and payment/commercialisation is probably the main issue. If you make this sucessful and lower the cost of enough it doesn't matter what platform / language / technology you are using. I think it's too easy to say Java is the answer - at the moment I think that the perception holds sway because people see it as the least cost platform (now and in the future). Java needs JSRs to remain effective with increasing technical complexity and that leads to its own fragmentation issues.
ReplyDeleteI really dont see a ubiquitous software layer emerging. I don't think that is the problem to be honest. It might help, but I don't think its going to occur. At the moment various platform have their own strenghts. I think there'll be a number of major platforms which do well through volume - Java is sort of at this stage, but things like Flash and native platform OS coding are on the way to joining it. Part of this comes down to different platforms / tools being good for different jobs.
I think Java fragemnatation issues and the baggage that involves considerably detracts from it effectiveness / possibilities. Where is does seem to work well is where the Java implementation is standardised across a platform (e.g. Sony Ericsson, S40 S60) etc. Even then its not perfect.
I have heard open platforms vendors say that native allows access to the cutting edge, and Java is someways behind. However both are continually moving. Thus an app which had to be native 2 years ago can now be done in Java. This will continue. However it sees Java emerge as standardised across an open platform, but not necessairly among platforms.
I don't think a sandbox is the answer. If you make your security model robust enough you shouldn't need a sandbox (hmmm). I also think this puts too mcuh limit on innovation. The best user experience often comes from tight integration and innovation something which would be hard to do in the sandbox.
High end phone thinking is a bit of problem at times, but its not going to be long before the majority of mid ranges phones are running on some kind of platform (be it Symbian or Linux).
One interesting approach is the idea of super distribution which allows people to copy their applications to each other. Openbit have done some interesting stuff in this area and have added a mobile payment. On device payment via your phone bill or credit card. There still needs to be a way to seed the intial distribution though.
>>and how much would you have to pay them to get listed?
ReplyDeleteNothing. A developer creating an app for your platform is doing you a favor. You don't charge them for that, you thank them.
Amen.
I can't think of a single company that is doing the right thing to build a really open and robust developer ecosystem on mobile devices. Microsoft and Palm(Source) come closest - but they are totally missing out on enabling the business infrastructure.
Looking at your list of contenders - I worry that none of them seem to have either the vision or scale to make mobile data really take off.
I'd love to see somebody doing something innovative and exciting in this space - but I don't see much on the horizon to get excited about.
The sad thing is - it really shouldn't be that hard to do.
- chris
Sorry if I came across too strong, I agree we probably do agree on most of this - particularly the app discovery problem. Java has huge problems and other environments are probably better, but my main point remains that you work with what you've got and unless you're happy to throw out most of the market or wait 2-4 years in the hope that a smartphone platform really will break the mainstream (which they haven't done yet, despite the predictions of Symbian et al for many years) you have to learn to cope with Java.
ReplyDeleteAs an example, in my company, porting usually takes a week out of a 6-12 week project and a lot of that is tweaking the layout for the huge number of phone variations. This is for heavily graphical networked apps with lots of animation etc across hundreds of handset models. If you have smart people and a little time it's achievable, but you have to be prepared to grasp the nettle...
>>and how much would you have to pay them to get listed?
> Nothing. A developer creating an app for your platform is doing you a favor. You don't charge them for that, you thank them.
I'd love the world to think in this way, but this is where the 'fantasy' label comes back in. I've yet to meet an operator who thinks this way, I've yet to meet an operator that can change direction a little bit in a month let alone change their entrenched opinions on a dime, and so I don't see it happening. But don't get me wrong, I'd love to be proved wrong.
There is one other problem - finding things on Amazon is hard with a big screen, a keyboard and a mouse over broadband. Doing it on a tiny screen with a numeric keypad is a nightmare, and that won't change however clever the ratings system, so listing everything IMHO isn't practical. Effective filtering implies humans between the developer and the end user who need to be paid, and that's where it generally falls down. This is partly where I think off-portal initiatives can help - break away from the cramped mobile as the only way to discover content, push it from the environment and virally. Infrastructure isn't quite there, but it's closer than any new development platform...
>>Answer: 99% of the time it will be operators deciding, and they always want lots of money.
> Somebody -- maybe an MVNO, maybe a more progressive operator -- will realize they need to work with developers differently. Once they do it, and real mobile data takes off, the others will be obligated to follow suit.
Answer: DoCoMo. They got there first (years ago), they did it right (in Japan), and they are making a lot of money out of it (again, only in Japan). Every other operator wants to emulate them and none have managed because they can't bring themselves to let anyone else share the revenue. Witness the huge efforts Vodafone went to to copy them , like trying to enforce the same security alerts, user agent style, own-brand model numbering in Japan etc - they copied all the irrelevant stuff and missed the point... and now they are losing lots of money on content (think I heard that officially, but if not I may just have guesstimated at some point based on cost of advertising, available figures etc). Ditto iMode outside Japan, which even DoCoMo acknowledge to be failing - they've sold it to operators who have this strange belief that the answer lies in a sub-standard browsing experience (compared to contemporary XHTML browsing on mid- and high-end devices) and a hobbled set of Java APIs which are again behind the contemporary MIDP world, without the device standardisation that made iMode development easy.
Possibly I just have less faith in people and no faith in operators, but working examples have been out there and none of them has yet broken their mutual content suicide pact...
Yet more interesting comments! Thanks.
ReplyDeleteRafe wrote:
>>I really dont see a ubiquitous software layer emerging. I don't think that is the problem to be honest. It might help, but I don't think its going to occur.
I definitely don't see one emerging right now. The question is, if somebody got the discovery and billing thing right, could the network effect (apps base attracts users which attracts more apps) create a winner.
We won't know until somebody gets the right formula for discovery and purchase.
>>Part of this comes down to different platforms / tools being good for different jobs.
Very good point. Especially in a device with restricted memory, you can't optimize for everything. And a platform designed for 3D games (for example) might not be very useful for a business database app.
>>I don't think a sandbox is the answer. If you make your security model robust enough you shouldn't need a sandbox
I think you guys are persuading me on this one. I wanted a sandbox because I knew it would be a way to close off the (mostly) imaginary and semi-hysterical security fears of the operators. But you're right, if the system is designed correctly you should not need a sandbox.
>>One interesting approach is the idea of super distribution which allows people to copy their applications to each other.
Absolutely! Now that we're finally getting more deployment of Bluetooth, this is a very cool way to do distribution. The payment system should be smart enough to seek payment from the person receiving the beamed app, and also (if desired) pay a bounty to the person who beamed it out. Then a developer could incent his/her own customers to become a channel of distribution.
In spirit, it's a bit like affinity links for Amazon.
Chris wrote:
>>I can't think of a single company that is doing the right thing to build a really open and robust developer ecosystem on mobile devices.
As Raddedas mentioned, DoCoMo. I can't remember where I saw it, but there was a great quote from their CEO saying basically, "in a good business deal, both sides have to win." We should get that tattooed on the foreheads of the management teams at some of the operators.
Unfortunately, DoCoMo has had a terrible time transferring the iMode model to other countries.
>>Looking at your list of contenders - I worry that none of them seem to have either the vision or scale to make mobile data really take off.
It's going to take a while, but I do have hope.
Raddedas wrote:
>>Sorry if I came across too strong
No need to apologize -- you made good points.
I'm sitting here grinning because we're actually so much in alignment.
>>unless you're happy to throw out most of the market or wait 2-4 years in the hope that a smartphone platform really will break the mainstream...you have to learn to cope with Java.
Yes, absolutely.
Perhaps we should do both -- cope with Java while we try to build something better.
I know most small developers don't have time to invest in future possibilities. But we can at least campaign for them online, in the hope that someone's listening.
Are you listening out there? Do you understand that embracing mobile developers in an open way won't make you weak, but will actually make you more powerful? Do you understand the company that does mobile data right can set a standard as lucrative and enduring as Windows?
I look at my visitor logs, I know people from some of the right companies are visiting. Forward this around, folks.
Hellooooo...
>>I've yet to meet an operator who thinks this way, I've yet to meet an operator that can change direction a little bit in a month let alone change their entrenched opinions on a dime, and so I don't see it happening.
Sigh. I wish I could argue with you, but right now I can't, especially regarding the US.
Europe is a little more promising, since a lot of phones are sold through phone dealers rather than operators. If we ever get flat-rate data plans there (okay, another "fantasy"), a handset vendor might be able to build in a good software discovery/payment mechanism without going through the operator.
The operator roadblock is why there's such intense interest in WiFi in Silicon Valley -- folks here are hoping that if they can't change the operators, they will eventually find a way to go around them.
At some point I'm sure something will break, but it's hard to predict when.
>>Effective filtering implies humans between the developer and the end user who need to be paid, and that's where it generally falls down. This is partly where I think off-portal initiatives can help - break away from the cramped mobile as the only way to discover content, push it from the environment and virally. Infrastructure isn't quite there, but it's closer than any new development platform
My experience with the PalmOS Expert Guides gave me a lot of faith in the ability of volunteers to filter, if properly empowered. That avoids almost all of the payment thing. But I also like what you're talking about.
>>Answer: DoCoMo. They got there first (years ago), they did it right (in Japan), and they are making a lot of money out of it (again, only in Japan). Every other operator wants to emulate them and none have managed because they can't bring themselves to let anyone else share the revenue.
Yup, DoCoMo is my poster child. Unfortunately, the other operators' inept efforts to copy them (remember mMode?) have led a lot of people to conclude that the iMode model can't work outside of Japan. Which is both foolish and a teensy bit racist.
>>Possibly I just have less faith in people and no faith in operators, but working examples have been out there and none of them has yet broken their mutual content suicide pact
As GB Shaw wrote in the play Back to Methuselah, "You see things; and you say Why? But I dream things that never were; and I say Why not?"
Or something like that.
David wrote
>>I wonder if you know of any data about whether vertical apps inside the enterprise are faring any differently.
Great question. No, I don't have any data.
I haven't heard the squeals of pain from custom mobile developers that I've heard from the folks who target end-users, so I expect that the custom stuff is going okay. Not booming (or we'd see more companies piling in), but okay.
The comments from Mel Sampat at Microsoft implied that this is the case.
>>email, which you identify as the killer mobile app that sells devices like the BlackBerry and Treo, isn't turning out to be all that killer.
Oh yeah, I think this is going to be a rude awakening at some point for the mobile companies. We once thought mobile calendar was a killer app that everyone would want. Turned out there was a limit to that market, and we hit it -- hard.
Mobile e-mail is desperately loved by a certain percentage of people, and not important to the rest of us. So the mobile mail market is going to keep on growing right up until it stops.
When I read comments from RIM and Palm that they're moving into consumer e-mail devices, I worry. The core customers for mobile mail are professionals, prosumers. Making an e-mail device cost $50 doesn't make people buy it, especially if they have to pay $50 extra a month for the data service. That's $600 a year, Cingular! Only the hardcore will pay that.
The thing to watch is the rate of change of the growth curve for Treo and RIM. When the rate of increase starts to decline, that's a sign that the ceiling is approaching. Stand back.
>>The idea that I'd pay extra to have my spam pushed to my smartphone in real-time is ludicrous
:-)
I've been hearing similar things about SMS in Japan. It became a pretty big problem there. Don't know if the operators have managed to solve it.
>>I still think you've hit on the big problem with slow adoption of mobile data, but I believe the weakness of mobility's supposed killer data app is a substantial contributing factor.
I think your comments about e-mail are right on but let me give a slightly different take on the killer app thing. Mobile e-mail can get much better, but I think it will never be the single horizontal killer app for mobile because not enough people really care about it.
I believe the real killer app is customization itself. It's the software discovery and installation experience. That's the thing that makes the device indispensable to everyone.
Here's an article that Carlo Longino wrote a few weeks ago at MobHappy. It talks about the concerns regarding the growth of the mobile data market. I think he made some good points.
ReplyDeleteThe comments to his post are interesting too.
A few points, Mike:
ReplyDelete1) Super Waba is a "better" version of Java that should be part of any future mobile device.
2) How hard would it have been for Palm to include a CD with copies of all of the applications mentioned in the PalmSource "Expert Guides" arranged by topic? It would have taken a junior staff member all of one day to produce this and would have been an inexpensive (10 cents per device???), simple short term fix to the problem of users being unaware of their device's potential. A more sophisticated solution would involve Palm writing a version of the Desktop Installer that would allow users to easily pick from a list of a few hundred of the best PalmOS apps. Even better would be having this library of trial versions of apps somehow included in all devices (e.g. on a NAND Flash chip).
3) Regarding "killer apps": the bottom line is that Palm never took advantage of the ones they had sitting right under their noses.
- Palm could have seized the success of RIM had it only offered a turnkey email solution to businesses.
- MP3 was not pushed when it was hot.
- Video encoding + playback has been ignored by Palm.
- Personal broadcasting (e.g. Slingbox) is being ignored by Palm.
- GPS was pretty much ignored by Palm even though it could have been another "killer app".
If Palm would take the bull by the horns and actually do the grunt work it takes to be on the cutting edge rather than just waiting for third party developers to create solutions for them, they would be in a better position to take advantage of any "killer apps" that crop up.
One other thing, Mike. How likely is it that in the end we'll all just be carrying tiny 3 ounce featurephones that have big screens (for passive viewing of wireless video, Internet, videoconferencing, etc) most of the time, while also carrying full-fledged micro laptops capable of running Windows XP like the VAIO UX50 when at work/school? Unless someone figures out how to package a 4 inch screen into a 2 inch cellphone I'll bet that smartphone adoption by the masses will always be limited by people's desire for bigger screens +/- keyboards when performing all but the most simple computing tasks.
ReplyDeleteIn the end, if no one really wants to perform computing tasks on a cellphone, perhaps smartphones are an answer to a question that no one was asking?
Yikes! Now how's that for profound?
My experience with the PalmOS Expert Guides gave me a lot of faith in the ability of volunteers to filter, if properly empowered. That avoids almost all of the payment thing.
ReplyDeleteIt worked for the Expert Guides because they were not a profit center for PalmSource. Building a business model around volunteers, though, is risky.
For one thing, volunteers are vulnerable to loss of enthusiasm, burnout, or simply changes in their day to day priorities. That can happen with paid staff too, of course, but paying people tends to push getting their work done up the priority list, and you have more recourse if they don't follow through.
For another, as AOL discovered, if you rely on volunteers to do work that you are making a profit off of, at some point you may be looking at a class-action lawsuit from those volunteers, demanding a piece of the profits.
Anonymous wrote:
ReplyDelete>>Super Waba is a "better" version of Java that should be part of any future mobile device.
You're right, that one deserves to be on the list -- although it looks like it's being used more for custom enterprise develpment than prosumer. Here's a link.
>>How hard would it have been for Palm to include a CD with copies of all of the applications mentioned in the PalmSource "Expert Guides" arranged by topic?
The hard part would have been getting the rights to reproduce all of the apps, but I agree with you completely.
Hey, considering the relatively small size of most Palm OS apps, you could probably have included much of the entire PalmGear software library on a single CD.
>>Regarding "killer apps": the bottom line is that Palm never took advantage of the ones they had sitting right under their noses.
No argument from me, although I should add that making all the details of a solution work properly takes more time and focus than you'd believe. So you can't develop many of them at once.
I think a big challenge for Palm right now is that the smartphone thing is all-consuming. The operators can use up all of the engineering resources of even a very large hardware company, so little Palm really has its hands full.
I have high hopes for the Jeff Hawkins secret project, though. I don't know what it is, but I know some of the people working on it, and they're good.
>>perhaps smartphones are an answer to a question that no one was asking? Yikes! Now how's that for profound?
Excellent! You can post here anytime.
If we ever get those flexible screens that the display people keep promising, I think it'll be possible to create a single device that transforms from tiny to quite a bit larger.
But I am not a big fan of convergence in general. I think it fails about nine times out of ten.
Fiat wrote:
>>if you rely on volunteers to do work that you are making a profit off of, at some point you may be looking at a class-action lawsuit from those volunteers, demanding a piece of the profits.
Thanks, good point. I think the thing to do would be start with volunteers, and give them more and more reward as the business gets successful.
>>How hard would it have been for Palm to include a CD with copies of all of the applications mentioned in the PalmSource "Expert Guides" arranged by topic?
ReplyDeleteThe hard part would have been getting the rights to reproduce all of the apps, but I agree with you completely.
Hey, considering the relatively small size of most Palm OS apps, you could probably have included much of the entire PalmGear software library on a single CD.
Yes.
I actually wrote this up as one of my first proposals to product marketing way back when I started at Palm in October 2000. At the time, every single consumer-focused application on PalmGear could have fit on a single demo CD. It would have been an AMAZING tool to expose users to the wealth of applications out there.
But even then - product marketing and engineering was too swamped with "need to have" feature requests from licensees to devote any cycles on fleshing out something new and innovative that would benefit developers.
It was frustrating.
We had all the right ideas. Just never the ability or focus to prioritize on what was really (in the longer run) important.
- chris
Chris wrote:
ReplyDelete>>We had all the right ideas. Just never the ability or focus to prioritize on what was really (in the longer run) important.
Yup, yup, yup. To phrase it another way, the demands of the operators and licensees were so all-consuming that the company couldn't free up any time to work on anything else.
The big "aha" moment for me in the last six months was when I realized the same problem applies to every mobile OS company, no matter how many engineers it has. This is a structural business problem, not a technical one. I think we won't solve the problem until we separate the developer platform from the operators' OS requirements.
Mike, a very insightful post, as always.
ReplyDeleteI believe that the new breed of OS's has 'smartened up' compared to the open OS predecessors and now includes the three very important components:
a. a UI customisation layer for end-to-end UI customisation
b. an application environment for easy app development and easy app deployment
c. ease of portability and integration to the underlying reference design.
Examples of these OSes are the Purple Labs stack, A la Mobile, the Digital Airways + Sky MobileMedia + Montavista mash-up and the Voda-DoCoMo announced reference design. All of these are Linux based and it's no coincidence as Linux gives you clean APIs to the UI and ports across most reference platforms by default.
Symbian essentially has delivered NONE of the a, b, c components, Microsoft has really delivered only on b and S60 delivers only on b and is planning on delivering on a, too through an XML-based framework for UI definition Nokia is working on.
As for content accessibiliy and discovery platforms, I call these On-Device Portals (see ARCchart's Jan06 report on the topic which I authored) and I don't believe they will be standardised into a platform. Instead, Nokia's NCD (which has also adopted the ODP term by the way), Moto's Screen 3 and the 25+ vendors selling ODP products will hang around at least for another year before we see client-side commoditisation and vendor M&As.
Andreas
This is a great article. I read it quite a while back, and have re-read it a few times since.
ReplyDeleteI've started doing a series of Q&A sessions with mobile software developers, talking to them about what makes a great mobile app. Have mentioned this article within the questions to our first CEO, from SBSH Mobile.
The post is at:
http://justanothermobilemonday.com/Wordpress/2006/07/26/who-makes-this-stuff-with-the-makers-of-pocketbreeze/
Did anybody point out that many mobile devices don't do what they are supposed to do as well as they should.
ReplyDeleteFor instance the Nokia E61 will only hold just over a 1000 contacts before it gets flaky. And Nokia will eventually get around to fix it, but you will have to get the fix flashed on to your phone at a Nokia service centre.
So a Palm Zire has a better address book than Nokia's BlackBerry or Treo competitor.
Mobile apps are declining, probably because the basic utility of the devices doesn't inspire confidence.
Renaissance wrote:
ReplyDelete>>the Nokia E61 will only hold just over a 1000 contacts before it gets flaky
Good point. I think two things are going on here:
1. As I mentioned in my post, the operators consumer so much resource from even the big vendors that there's no time to fine-tune the mobile data features. So even a huge vendor like Nokia ships a supposed "PDA phone" with major bugs in the PDA features.
If you ever tried to get sync to work properly with the earlier Symbian phones you'll know what I'm talking about.
2. The common wisdom in the mobile phone world is that converged devices are eating the sales of standalone handhelds. To some extent that's true, but the PDA features in many of the "converged" devices are so bad that they make a horrible substitute for a handheld.
I think there are other causes for the dropoff in PDA sales (namely, a lot of the sales were gift and impulse-driven in the first place, and when the fad wore off the handheld industry hadn't taught users the practical reasons why they should buy.
FYI: SavaJe finally bit the bullet this week. Well, there's a possibility it could come back, but all of the staff are now looking for jobs -- even the ones who had been working for free hoping the company could land the VC money.
ReplyDeleteNice Article. I am a regular on your blog.
ReplyDeleteHave you thought about ajax based browsers as a standard for developing rich mobile interfaces? Opera seems to trust this model. It solves a lot of problems - distribution is easy (web), discovery is web search, installation and upgrade is seemless. (of course, its too early to say if and when mobile ajax will mature).
I think it's a really interesting possibility, Sanjay. I think the AJAX architecture used on the wired web needs to be modified, though, because a pure light client doesn't work well in a wireless device that might go in and out of coverage. You don't want all your apps to stop working when you're on an airplane or in a parking structure (or when you leave 3G coverage).
ReplyDeleteSo we need a version of AJAX that can cache data and application logic on the local device, and then update them in the background (like RIM does with its e-mail client).
Hi Mike,
ReplyDeleteCan you fix the links in your article. None of the ones pointing to PalmSource seem to work anymore.
Thanks!