5 Mar 2007, 11:59PM PT
27 Apr 2007, 12:00AM PT
Closed: 5 Mar 2007, 11:59PM PT
Earn up to $150 for Insights on this case.
8 Insights
Outline A Strategy For Developing A Mobile Application by Derek Kerton
Tuesday, February 20th, 2007 @ 12:22PM
Well, your first paragraph shows that you have run into the biggest problem with mobile development, and understand it well. The second biggest problem is the roadblock represented by the carriers and their walled gardens. They are a hurdle that normally needs to be jumped to get to paying customers.
I have been building mobile content since 1999, starting with Infoseek portal content, then running the team that brought Disney.com, Oscars.com, ESPN, ABCNews.com, and ABC content to mobile phones. In 2001, I started independent consulting at www.kertongroup.com, and since then have consulted on content or application builds for Leapfrog, and some smaller players in the US and abroad like Synapse Group and PayPal. To be honest, I've been involved in as many failures as successes, since sometimes the carrier's ability to delay outlasts the startup's persistence to sell.
So here's some practical advice:
Outline A Strategy For Developing A Mobile Application by Teck Chia
Friday, February 23rd, 2007 @ 1:38AM
Before you devise a strategy for building a mobile application, here are some observations of the mobile world that can influence your approach:
With that in mind, here are some points you should consider in devising a strategy.
If you have to attack one platform at a time, here are some things to consider:
Outline A Strategy For Developing A Mobile Application by Matt Gross
Sunday, February 25th, 2007 @ 10:46AM
The difficulty in developing applications for the mobile world is the lack of uniformity of platform. Only the least common denominator of technology is available to the mass market: voice and text messaging. However, as capability of handsets increases and carriers/operators developer more attractive pricing policies, mobile applications are also reaching the mainstream.
Within the last several years, a viable market in 'downloadable applications' has developed. 'Downloadable applications' are generally defined as software written in J2ME or BREW. These applications are either pre-loaded or downloaded to the handset.
To take a snapshot of the US market, software on the handset is a recent innovation. As recently as 2005, a single application, MapQuest Mobile, account for 20% of the US revenue for downloadable applications. Most carriers blocked or made difficult any downloads that were not purchased on their content decks, thus ensuring that applications were sanctioned by the carriers and integrated into their billing systems.
In the last two years, this market has grown substantially driven by a couple of different factors. 'On deck' applications have seen their greatest success when carriers put a major marketing effort behind the effort, both in-store and through general marketing, such as was the case with Verizon's VZNavigator. At the same time, 'over the top' efforts, perhaps best exemplified through Google's GMail and Google Maps applications, have seen great success on carriers such as Sprint, Cingular, and T-Mobile.
Outline A Strategy For Developing A Mobile Application by Alexander CASASSSOVICI
Monday, February 26th, 2007 @ 2:25AM
This is definitely a tough question, a few points first :
If you want to adress 100% of user-base, use IVR or SMS. If you want to use anything else, be prepared to lose a lot of the available user base!
The second choice would be WAP or xHTML mobile browsing. Never underestimate this solution as it can really bring some efficient service and information into your mobile. Of course it's not that sexy, but it is efficient!
Third choice : Java. It's really not a write once run everywhere solution ... Firstly, installing the application on the mobile is a pain for the user.. you should always provide a SMS OTA provisioning system. Secondly making a good Java application is an art. There are some tools available to try and simplify the UI design (as regular Java widgets are really bad looking), such as j2mepolish.org or Geniem and those often can lead to good results... but if you run into any problems you're dead.
Fourth choice : Use Flash Lite, or Flash-like players such as Streamezzo's or Bluestreak's. It might be the fastest way to make your mobile application and connect to online services.
Fifth Choice : do it by hand, platform-by-platform using native code... this one is really time- and cash-consuming but gives the best results and lets you really optimize the user experience on each device. Don't forget that when you have good specifications you can outsource that!
Start with Nokia Series 40, then Symbian/S 60, then Motorola (Java), Sony Ericsson (Java), HTC (Windows Mobile) and you have most of it...
Outline A Strategy For Developing A Mobile Application by Michael Rowehl
Tuesday, February 27th, 2007 @ 2:18PM
The easiest way to hit the broadest coverage with maximum value is normally to concentrate on the user experience end first to figure out what you want to develop. Frequently companies try to map a desktop applications to mobile platforms and treat the process as a porting problem. But mobile offers one of those 80/20 kind of setups, where if you think about what the user of your system is really looking to do, you can frequently provide them a simple effective and efficient way to do so without getting bogged down in details.
Normally that means minimizing the information and actions available. If the desktop version of an application provides a dozen pieces of info on each page and the menus provide two dozen actions, the mobile version should provide just two or three bits of info and maybe a half dozen actions. Developing an application for a mobile user base isn't about offering the complete set of what could be done in every situation. The simple mobile applications are normally the most effective ones.
Outline A Strategy For Developing A Mobile Application by Daniel Taylor
Wednesday, February 28th, 2007 @ 7:02AM
Any vendor interested in developing a mobile application should look long and hard at the consumer market. The reason is that the enterprise is a far greater challenge.
The enterprise is a longer-term investment with greater risk and numerically fewer chances of success. Integration and device management are major issues that can quickly become limiting factors for an application developer. Also, it takes a far larger organization to support the enterprise market than it does consumers. Indirect channels become critical, and an application developer can find itself heavily invested in the success of a program from a single wireless operator. Few applications developers can withstand this level of risk.
Keep in mind that Research In Motion took a "gamble" when the company invested in 100% indirect, carrier distribution for BlackBerry. RIM is the exception that proves the rule.
The consumer market can include traditional "consumers" as well as workers who have provisioned their own mobile devices. In western Europe, this second category is much larger than it is in North America.
The next step for the consumer market is to address the Total Available Market (TAM) discussion. What platforms will lead to the largest market opportunity for a given geography? I'm a big fan of Java applications that are an easy download and can be supported on a broad number of mobile devices (smartphones and traditional mobile handsets).
Going into the smartphone/PDA category for individual consumers reduces the TAM but does offer some advantages for applications developers -- namely a keyboard and a larger screen. I'd consider Windows Mobile and Symbian as key platforms.
Outline A Strategy For Developing A Mobile Application by Hersh Reddy
Wednesday, February 28th, 2007 @ 6:21PM
First a little background and a rambling analysis of the options available on mobile:
My experience with mobile software has been limited to consumer applications, and I've only shipped products for Symbian and BREW. So although I hope my insights about Java are accurate, they are less a result of hands on experience and are based more on discussions I’ve had with other people in the industry.
The first thing to consider when planning for an application launch is the feature set of your product. Are the features you intend to support easily implementable on the lowest common denominator platform, or do they require handset by handset tweaks?
Simple features which migrate easily include things like text display, basic input, simple sounds, 2D image display etc. Things that don’t often have a standardized implementation across handsets are features like 3D graphics, access to the camera hardware, mp3 playback, integration with phone contacts database, screensaver functionality etc.
To take just one example which I am intimately familiar with, 3D Graphics: there are several “standards” available for mobile 3D -- OpenGL ES and the JSR 184 Java specification, for example -- however the performance you get on a particular handset implementations vary widely, and not just because of the variation in the underlying handset hardware. In addition, many OEMs pay scant attention to supporting such “high-end” APIs, which allow applications access to more of the handset’s functionalities, and you often have to resort to third-party libraries to get support on a particular handset.
If your application intends to integrate with phone functionality in any way at all, then your porting becomes several orders more complicated. For example, the product we are shipping right now is a BREW application which needs to launch when the handset is flipped open. Seems like a simple thing to do, especially since you would expect BREW to have a standard way to receive a “flip” event and perhaps handle it? Well, that is not the case. The reality is that since Verizon layers their own custom solution on top of Qualcomm’s basic BREW, and since OEMs are not held to strict quality guidelines when implementing the BREW specification, most (in fact, all but two) handsets in Verizon’s selection do not issue the “flip” event. The reason such an egregious error is allowed in shipping handsets is because it is not a feature which is commonly used by developers -- we are probably the first shipping product to try to use it.
So the correct strategy to pursue for an application launch is not independent of your application's features. Do your features require only commonly used capabilities, or will you be trailblazers?
If you don’t need tight phone integration then there is no reason to not use Java for your application. It has, by far, the largest addressable consumer market. If you DO have cutting-edge features and tight phone integration then you might want to focus on a more “full-featured” platform like Symbian/S60 or Windows Mobile, as they will typically have better (i.e. standardized) access to handset features. But they are a MUCH smaller market, albeit a market that arguably is more affluent and perhaps buys more content/applications (I have no data to substantiate that claim). BREW is something in-between; a fairly large market, with potentially more handset features exposed to the developer, but also more complicated development/porting.
The next thing to think about is how you are going to market and sell your application. There are on-deck applications and off-portal ones. If you are going to get on a carrier deck, then you either need a great sales person, who actually gets her calls to the carriers returned, or you need to partner with a mobile publisher like Glu, EA, Hands On etc. etc. These publishers will typically take 50% of your revenue in exchange for the service of placing you with the carrier. They will do little else. The 50% split is simply because they get you in the door – and by the way, this is 50% AFTER the carrier has taken their slice from on top. On the positive side, they may bring you some powerful brands or some marketing dollars to help push your application.
Though this sounds far from optimal, it’s still better than the dogpile which is the off-portal world. That is a black pit of literally 1,000 nameless applications -- you need to have some smart marketing to drive customers to your product in this mess. It’s a risky proposition. My opinion is that it’s better to go with a publishing partner and to try to get on a carrier deck.
As for choosing a carrier to launch on: ideally you would be launching on all carriers. And if you have a good sales team, and a Java application, there is really no reason why you cannot at least target the major US carriers with your initial launch. But, again, this assumes your application is of the lowest common denominator type that is amenable to deployment via Java.
If you launch with a BREW application then obviously your launch is much more constrained. The only major BREW carrier in the US is Verizon (Alltel, US Cellular and Cricket are much smaller). The certification process for BREW (True BREW Testing) is a colossal time sink and not insignificant expense. However, once you get through the testing you find yourself (assuming your bizdev team was good) on the much more rarified deck of Verizon. Here you face much less competition (probably because TBT and getting on the deck are such a pain), and if you can get into the “Featured” list on the deck, then living can be quite good. But I cannot stress the importance of a good sales team if this plan is to succeed. This is DEFINITELY not the plan to pursue if you are a small team of brilliant engineers, with one webmaster/sales guy.
I would not suggest a Symbian or Windows Mobile launch for a mass-market consumer application, unless there is no other option, since those platform markets are too fragmented and small, in the US, to allow you to get a substantial addressable base in a reasonable number of development/biz-dev steps. You can hit them in your second-wave of releases -- perhaps at the same time as you enter the EU market (Symbian has a healthy addressable market there).
So a strategy to summarize my thoughts:
Outline A Strategy For Developing A Mobile Application by Jim Hughes
Wednesday, February 28th, 2007 @ 11:21PM
Here is my strategy for developing a mobile application. Wow, that sounds simple, no? In my view there is no simple strategy for developing a mobile application, much as developing any other application there is no silver bullet.
The basics of mobile development are exactly the same as any software development process, you need a concept, the means to convert this idea into functional software, and a marketplace desperate for your product. The best way I've found to get from concept to reality is by producing some realistic use case scenarios and a good set of requirement documents, if your application is being developed by a third party, getting the details and right at this stage can reduce the confusion and problems during development.
As for mobile development there are unique requirements there, primarily around the choices of target market and target devices. Consider also the internationalisation aspects of your development, can your application work anywhere around the world? Are you going to restrict it to an English-speaking audience? Are there cultural issues that will prevent your application from being popular in certain markets, for instance American date formats in Europe, gaming software in the U.S. etc.
When you come to choose your target device, here are a few rough guidelines of the current market breakdown:
A good graphical breakdown of the current market can be found here - http://mobilephonedevelopment.com/archives/322
Other factors include data costs: has your target geographical market got flat-rate data plans? If not, how are you going to attract people who are worried about high data costs?
How are you going to get your application to market? Are you aiming to get it onto an operator’s deck? Or sell via sites like Handango?
Are you really thinking mobile-only? If you're thinking hybrid (web/mobile), are you going to restrict either approach?
Lots of questions, and your development will throw up more, but if you can resolve most of mine in the design stage, you will have a good basis for the software development.