tag:blogger.com,1999:blog-17898384.post115156043463260382..comments2024-03-25T21:41:06.801-07:00Comments on Mobile Opportunity: We need a new mobile platform. Sort of.Michael Macehttp://www.blogger.com/profile/17966107280587843091noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-17898384.post-849580043231255902007-10-13T03:22:00.000-07:002007-10-13T03:22:00.000-07:00Hi Mike,Can you fix the links in your article. Non...Hi Mike,<BR/><BR/>Can you fix the links in your article. None of the ones pointing to PalmSource seem to work anymore. <BR/><BR/>Thanks!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17898384.post-59574384567094382692006-12-16T21:26:00.000-08:002006-12-16T21:26:00.000-08:00I think it's a really interesting possibility, San...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).<br /><br />So 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).Michael Macehttps://www.blogger.com/profile/17966107280587843091noreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1163607929802418442006-11-15T08:25:00.000-08:002006-11-15T08:25:00.000-08:00Nice Article. I am a regular on your blog.Have you...Nice Article. I am a regular on your blog.<BR/><BR/>Have 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).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1161703895210676162006-10-24T08:31:00.000-07:002006-10-24T08:31:00.000-07:00FYI: SavaJe finally bit the bullet this week. Well...FYI: SavaJe finally bit the bullet this week. Well, there's a possibility it could come back, but <B>all</B> 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.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1155502868185844852006-08-13T14:01:00.000-07:002006-08-13T14:01:00.000-07:00Renaissance wrote:>>the Nokia E61 will only hold j...<B>Renaissance wrote:</B><BR/><BR/><I>>>the Nokia E61 will only hold just over a 1000 contacts before it gets flaky</I><BR/><BR/>Good point. I think two things are going on here:<BR/><BR/>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.<BR/><BR/>If you ever tried to get sync to work properly with the earlier Symbian phones you'll know what I'm talking about.<BR/><BR/>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. <BR/><BR/>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.Michael Macehttps://www.blogger.com/profile/17966107280587843091noreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1155039670340079812006-08-08T05:21:00.000-07:002006-08-08T05:21:00.000-07:00Did anybody point out that many mobile devices don...Did anybody point out that many mobile devices don't do what they are supposed to do as well as they should. <BR/><BR/>For 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. <BR/><BR/>So a Palm Zire has a better address book than Nokia's BlackBerry or Treo competitor. <BR/><BR/>Mobile apps are declining, probably because the basic utility of the devices doesn't inspire confidence.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1154057797194145692006-07-27T20:36:00.000-07:002006-07-27T20:36:00.000-07:00This is a great article. I read it quite a while b...This is a great article. I read it quite a while back, and have re-read it a few times since.<BR/><BR/>I'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. <BR/><BR/>The post is at:<BR/>http://justanothermobilemonday.com/Wordpress/2006/07/26/who-makes-this-stuff-with-the-makers-of-pocketbreeze/Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1152891229114086292006-07-14T08:33:00.000-07:002006-07-14T08:33:00.000-07:00Mike, a very insightful post, as always.I believe ...Mike, a very insightful post, as always.<BR/><BR/>I 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:<BR/>a. a UI customisation layer for end-to-end UI customisation<BR/>b. an application environment for easy app development and easy app deployment<BR/>c. ease of portability and integration to the underlying reference design.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>AndreasAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1152246181362453072006-07-06T21:23:00.000-07:002006-07-06T21:23:00.000-07:00Chris wrote:>>We had all the right ideas. Just nev...<B>Chris wrote:</B><BR/><BR/><I>>>We had all the right ideas. Just never the ability or focus to prioritize on what was really (in the longer run) important.</I><BR/><BR/>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.<BR/><BR/>The big "aha" moment for me in the last six months was when I realized the same problem applies to <I>every</I> 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.Michael Macehttps://www.blogger.com/profile/17966107280587843091noreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1152216168986414922006-07-06T13:02:00.000-07:002006-07-06T13:02:00.000-07:00>>How hard would it have been for Palm to include ...<I>>>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?<BR/><BR/>The hard part would have been getting the rights to reproduce all of the apps, but I agree with you completely.<BR/><BR/>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.</I><BR/><BR/>Yes. <BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>It was frustrating.<BR/><BR/>We had all the right ideas. Just never the ability or focus to prioritize on what was really (in the longer run) important.<BR/><BR/> - chrisAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151912316783293812006-07-03T00:38:00.000-07:002006-07-03T00:38:00.000-07:00Anonymous wrote:>>Super Waba is a "better" version...<B>Anonymous wrote:</B><BR/><BR/><I>>>Super Waba is a "better" version of Java that should be part of any future mobile device.</I><BR/><BR/>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 <A HREF="http://www.superwaba.com.br/en/default.asp" REL="nofollow">link</A>.<BR/><BR/><BR/><I>>>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?</I><BR/><BR/>The hard part would have been getting the rights to reproduce all of the apps, but I agree with you completely.<BR/><BR/>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.<BR/><BR/><BR/><I>>>Regarding "killer apps": the bottom line is that Palm never took advantage of the ones they had sitting right under their noses.</I><BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/><BR/><I>>>perhaps smartphones are an answer to a question that no one was asking? Yikes! Now how's that for profound?</I><BR/><BR/>Excellent! You can post here anytime.<BR/><BR/>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.<BR/><BR/>But I am not a big fan of convergence in general. I think it fails about nine times out of ten.<BR/><BR/><BR/><B>Fiat wrote:</B><BR/><BR/><I>>>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.</I><BR/><BR/>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.Michael Macehttps://www.blogger.com/profile/17966107280587843091noreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151905560403396822006-07-02T22:46:00.000-07:002006-07-02T22:46:00.000-07:00My experience with the PalmOS Expert Guides gave m...<I>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. </I><BR/><BR/>It worked for the Expert Guides because they were not a profit center for PalmSource. Building a business model around volunteers, though, is risky.<BR/><BR/>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.<BR/><BR/>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.Rachel Luxemburghttps://www.blogger.com/profile/12521247639838493705noreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151892441749498722006-07-02T19:07:00.000-07:002006-07-02T19:07:00.000-07:00One other thing, Mike. How likely is it that in th...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.<BR/><BR/><B>In 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?</B><BR/><BR/>Yikes! Now how's that for profound?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151884681469873682006-07-02T16:58:00.000-07:002006-07-02T16:58:00.000-07:00A few points, Mike:1) Super Waba is a "better" ver...A few points, Mike:<BR/><BR/>1) Super Waba is a "better" version of Java that should be part of any future mobile device.<BR/><BR/>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).<BR/><BR/>3) Regarding "killer apps": the bottom line is that Palm never took advantage of the ones they had sitting right under their noses. <BR/>- Palm could have seized the success of RIM had it only offered a turnkey email solution to businesses.<BR/>- MP3 was not pushed when it was hot.<BR/>- Video encoding + playback has been ignored by Palm.<BR/>- Personal broadcasting (e.g. Slingbox) is being ignored by Palm.<BR/>- GPS was pretty much ignored by Palm even though it could have been another "killer app".<BR/><BR/>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.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151716583438955202006-06-30T18:16:00.000-07:002006-06-30T18:16:00.000-07:00Here's an article that Carlo Longino wrote a few w...Here's an <A HREF="http://mobhappy.com/blog1/2006/05/31/should-we-just-give-up-on-mobile-data-and-content/" REL="nofollow">article</A> 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.<BR/><BR/>The comments to his post are interesting too.Michael Macehttps://www.blogger.com/profile/17966107280587843091noreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151716212027138392006-06-30T18:10:00.000-07:002006-06-30T18:10:00.000-07:00Yet more interesting comments! Thanks.Rafe wrote:...Yet more interesting comments! Thanks.<BR/><BR/><BR/><B>Rafe wrote:</B><BR/><BR/><I>>>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><BR/><BR/>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.<BR/><BR/>We won't know until somebody gets the right formula for discovery and purchase.<BR/><BR/><BR/><I>>>Part of this comes down to different platforms / tools being good for different jobs.</I><BR/><BR/>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.<BR/><BR/><BR/><I>>>I don't think a sandbox is the answer. If you make your security model robust enough you shouldn't need a sandbox</I><BR/><BR/>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.<BR/><BR/><BR/><I>>>One interesting approach is the idea of super distribution which allows people to copy their applications to each other.</I><BR/><BR/>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. <BR/><BR/>In spirit, it's a bit like affinity links for Amazon.<BR/><BR/><BR/><B>Chris wrote:</B><BR/><BR/><I>>>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.</I><BR/><BR/>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.<BR/><BR/>Unfortunately, DoCoMo has had a terrible time transferring the iMode model to other countries.<BR/><BR/><BR/><I>>>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><BR/><BR/>It's going to take a while, but I do have hope.<BR/><BR/><BR/><B>Raddedas wrote:</B><BR/><BR/><I>>>Sorry if I came across too strong</I><BR/><BR/>No need to apologize -- you made good points.<BR/><BR/>I'm sitting here grinning because we're actually so much in alignment.<BR/><BR/><BR/><I>>>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.</I><BR/><BR/>Yes, absolutely. <BR/><BR/>Perhaps we should do both -- cope with Java while we try to build something better. <BR/><BR/>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.<BR/><BR/>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?<BR/><BR/>I look at my visitor logs, I know people from some of the right companies are visiting. Forward this around, folks.<BR/><BR/>Hellooooo...<BR/><BR/><BR/><I>>>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.</I><BR/><BR/>Sigh. I wish I could argue with you, but right now I can't, especially regarding the US.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>At some point I'm sure something will break, but it's hard to predict when.<BR/><BR/><BR/><I>>>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</I><BR/><BR/>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.<BR/><BR/><BR/><I>>>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.</I><BR/><BR/>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.<BR/><BR/><BR/><I>>>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</I><BR/><BR/>As GB Shaw wrote in the play <I>Back to Methuselah</I>, "You see things; and you say Why? But I dream things that never were; and I say Why not?"<BR/><BR/>Or something like that.<BR/><BR/><BR/><B>David wrote</B><BR/><BR/><I>>>I wonder if you know of any data about whether vertical apps inside the enterprise are faring any differently.</I><BR/><BR/>Great question. No, I don't have any data.<BR/><BR/>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.<BR/><BR/>The comments from Mel Sampat at Microsoft implied that this is the case.<BR/><BR/><BR/><I>>>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.</I><BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/><BR/><I>>>The idea that I'd pay extra to have my spam pushed to my smartphone in real-time is ludicrous</I><BR/><BR/>:-) <BR/><BR/>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.<BR/><BR/><BR/><I>>>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><BR/><BR/>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.<BR/><BR/>I believe the real killer app is customization itself. It's the software discovery and installation experience. <I>That's</I> the thing that makes the device indispensable to everyone.Michael Macehttps://www.blogger.com/profile/17966107280587843091noreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151676059415056112006-06-30T07:00:00.000-07:002006-06-30T07:00:00.000-07:00Sorry if I came across too strong, I agree we prob...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.<BR/><BR/>As 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...<BR/><BR/><I><BR/>>>and how much would you have to pay them to get listed?<BR/><BR/>> 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><BR/><BR/>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.<BR/>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...<BR/><BR/><I> >>Answer: 99% of the time it will be operators deciding, and they always want lots of money.<BR/><BR/>> 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.</I><BR/><BR/>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.<BR/><BR/>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...raddedashttps://www.blogger.com/profile/14429544221232115028noreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151623788083109852006-06-29T16:29:00.000-07:002006-06-29T16:29:00.000-07:00>>and how much would you have to pay them to get l...<I>>>and how much would you have to pay them to get listed?<BR/><BR/>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><BR/><BR/>Amen.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>The sad thing is - it really shouldn't be that hard to do.<BR/><BR/> - chrisAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151619161714526762006-06-29T15:12:00.000-07:002006-06-29T15:12:00.000-07:00Difficult issue to tackle this as I don't think th...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.<BR/><BR/>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. 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. <BR/><BR/>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.<BR/><BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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). <BR/><BR/>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.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151605201850366292006-06-29T11:20:00.000-07:002006-06-29T11:20:00.000-07:00Cool comments. Thanks, everybody.Sarah wrote:>>On...Cool comments. Thanks, everybody.<BR/><BR/><BR/><B>Sarah wrote:</B><BR/><BR/><I>>>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.</I><BR/><BR/>Okay, so by suggesting that this software layer should be completely sandboxed, I'm making the problem worse. Good point.<BR/><BR/>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.<BR/><BR/>I wish I had a good answer to this one.<BR/><BR/><BR/><B>Raddedas wrote:</B><BR/><BR/><I>>>note that all your example Palm apps could be done on any MIDP1 device.</I><BR/><BR/>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.<BR/><BR/>I think you and I don't actually disagree on all that much.<BR/><BR/><BR/><I>>>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><BR/><BR/>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.<BR/><BR/>But I don't think the platform <I>has</I> 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. <BR/><BR/>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.<BR/><BR/><BR/><I>>>The high-end platforms listed here need high-end hardware and the market does not exist for that</I><BR/><BR/>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.<BR/><BR/>Again, though, I don't have any problem if the API layer is Java. Whatever works.<BR/><BR/><BR/><I>>>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.</I><BR/><BR/>Agreed, but I think they could do a <B>lot</B> better.<BR/><BR/><BR/><I>>>who decides which apps are listed</I><BR/><BR/>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.<BR/><BR/><BR/><I>>>and how much would you have to pay them to get listed?</I><BR/><BR/>Nothing. A developer creating an app for your platform is doing you a favor. You don't charge them for that, you <I>thank</I> them.<BR/><BR/><BR/><I>>>Answer: 99% of the time it will be operators deciding, and they always want lots of money.</I><BR/><BR/>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.<BR/><BR/><BR/><I>>>I can't see why any developer would ignore 80-90% of the market.</I><BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>Depends on the type of app, of course.<BR/><BR/><BR/><B>Tom wrote:</B><BR/><BR/><I>>>Your comment are too much PDA oriented</I><BR/><BR/>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.<BR/><BR/>Over time, what I'm describing is definitely a different beast from a voice-only mobile phone.<BR/><BR/><BR/><I>>>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.<BR/>Several offers already existis.</I><BR/><BR/>I'd love to look at them. Can you post a couple of URLs?<BR/><BR/><BR/><B>Michael wrote:</B><BR/><BR/><I>>>I happen to have a copy of the Ad</I><BR/><BR/>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.<BR/><BR/>I sure wish the company had run those ads. They might have changed a lot of subsequent events.<BR/><BR/>Or maybe they would have done nothing. We'll never know.Michael Macehttps://www.blogger.com/profile/17966107280587843091noreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151583244304051732006-06-29T05:14:00.000-07:002006-06-29T05:14:00.000-07:00I agree with most of the comment of previous poste...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.<BR/><BR/>There is already enough so-called ubiqitous platform (J2ME being the biggest one, but Flash, Brew, Symbian are others )!<BR/><BR/>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. <BR/>Several offers already existis, most of them on Java, few on native OS. <BR/><BR/>So this is already coming, the next step is probably a better integration with the handset, for instance for a preinstalled application....Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151579999077050612006-06-29T04:19:00.000-07:002006-06-29T04:19:00.000-07:00It's a very interesting post which seems to simult...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.<BR/><BR/>It 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.<BR/><BR/>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.<BR/><BR/>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).<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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 :)raddedashttps://www.blogger.com/profile/14429544221232115028noreply@blogger.comtag:blogger.com,1999:blog-17898384.post-1151572989825322192006-06-29T02:23:00.000-07:002006-06-29T02:23:00.000-07:00One problem we've had is the almost nil extensibil...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). <BR/><BR/>Partly, 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.<BR/><BR/>Thanks for the great discussion -- keep it going!Anonymousnoreply@blogger.com