Techdirt Insight Mobile Applications

Mobile Application Development Strategies March 7, 2007

The Issue Summary of Responses Techdirt Analyst Recommendations Insight Community Responses For additional insight from the Techdirt Insight Community, please contact Techdirt at http://www.insightcommunity.com or 888.930.9272

p. 2 p. 2 p. 4 pp. 5-15

T h e Iss u e Outline A Strategy For Developing A Mobile Application Developing applications for the mobile world is incredibly tricky. Unlike the PC world, where the choices are pretty obvious, the complexity level for mobiles is exponentially more difficult. You basically take carriers multiplied by OEMs/handset vendors multiplied by operating systems multiplied by development platforms to set the base level of complexity. Add to that the rapid churn rate of users, and it becomes even trickier. So, for a company that’s developing mobile applications, and wants to maximize coverage while minimizing integration costs, what is the best strategy? We recognize that it may be different for enterprise apps and consumer apps -- but are interested in both areas, so please give thoughts on both markets. Feel free to think outside the box, but hopefully the answers are practical. As a secondary question, if the strategy is to attack one platform at a time, what sequence of carriers/platforms/vendors makes the most sense, for each of the consumer and enterprise markets?

Su mma ry o f Re s p o n s e s One thing that became very clear in the Insights provided by the Techdirt Insight Community is that this is a really hard problem -- one that many of the experts had experienced first hand. The group, however, did have many practical thoughts. The first could be summarized as looking for the path of least resistance. Many noted that it helped to look for some kind of “least common denominator” for moving forward, with some going all the way down to the level of simply offering an application via IVR, SMS or WAP. Taking a step up from there, many people suggested focusing on Java as the platform of least resistance. No one really did so enthusiastically, given the many problems associated with Java, particularly the inconsistency of its implementation among handset vendors, which undermines the “write once, run everywhere” tagline -- but of all the choices it often has the least problems. Following that, the most common suggestions were some combination of Symbian, BREW or Windows Mobile -- though which one often depended on the type of application in question, as well as the targeted location. This highlights the importance of spending time on defining the requirements for your application, carefully considering the target market, and determining how simple an application can support your core functionality while delivering it with an acceptable user interface. A second important consideration in choosing a development strategy is what the corresponding marketing

strategy for the application would be. While this may not seem directly relevant to development, it is key due to the nature of the market. If you cannot establish certain key marketing relationships, then the development strategy may need to change drastically. While it is considered a pain, getting your application “on deck” from big-name wireless carriers is definitely a compelling strategy, if you are targeting the consumer market. Our Community makes it clear that this is no easy task, and may require either exceptionally talented sales people or a multi-pronged approach targeting a variety of carriers, while still preparing to prove out the application off-deck. If you must go off-deck with a consumer application, then they recommend partnering with one of the popular aggregators, such as Handango, and also preparing to spend a significant amount (both in terms of money and effort) on marketing. For an enterprise application, other potentially easier sales channels exist, such as selling directly to corporate IT departments, or through resellers. A third issue that plays into the decision making is target location. Many of the respondents focused mainly on a go-to-market US strategy, and noted that things changed if you were more focused on a European strategy -- where Symbian dominates. One of our bloggers pointed us to a marketshare chart (Figure 1) which was created by Symbian, so there’s a bit of bias -- and it also normalizes the population of each region, which may be distorting.

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

2

Fig. 1: Smartphone OS Market Share, 2006. Source: http://mobilephonedevelopment.com/archives/322 The final major concern brought up by our community was what additional features of a handset your application needed to access. If it doesn’t require access to more detailed systems (3D graphics was named a few times), then there will be fewer problems. The end result is that there really aren’t “easy” answers to the problems facing mobile application developers -- and, it seems that the best strategy may be a multifaceted approach. Depending on the target markets, it’s advisable to focus on platforms that quickly give you more bang for your buck (Java mostly; Symbian if focusing outside of the US). Following that, what shines through all the discussion is that partnerships are key. Finding the right partners, whether they’re the mobile operators, marketing partners or even development partners who can help port your app for you become key considerations.

There were two additional suggestions from our community that could prove useful. One was to focus on developing the core functionality in-house, but then licensing it out to others to develop more detailed systems and/or porting it to other platforms. A related suggestion was to open up your application, either aggressively by going open source and hoping that others will port to additional applications, or while retaining control by simply opening up certain aspects to allow others to develop hooks or tools to allow you to more quickly tackle additional markets and platforms. Unfortunately, there doesn’t appear to be any kind of silver bullet, but a phased approach that looks for a few different paths of little (if not least) resistance, followed by iteration as the market adjusts, seem to be the strategies recommended by nearly all of our Community members who took part.

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

3

Techdirt An a lyst Re co mme n datio ns One of the main problems our Community faced in providing direct recommendations to this insight was that beyond just the complexity described in the question, the many different types of potential applications in which the company posing the issue might be interested presented yet another dimension of complexity to the equation. Had the community known more about the application in question, the strategies would have been more specific. Knowing more about what you are trying to achieve ourselves, we can provide a few more specific recommendations. The key remains exactly what was discussed above. Nearly all of the technical design choices depend heavily on the go-to-market strategy for the application. The more well-defined that is ahead of time, the clearer a development path becomes. Given your existing relationships and access to certain mobile operators worldwide, for consumer focused apps, it’s going to make a lot of sense to leverage those relationships as much as possible -- obviously for things like making sure your application is included on-deck, but even for development help as well. Even using your core system, you should work with the operators so that they can customize the application to work with the various platforms and handsets they support. This will be essential, as it’s likely on many low-end phones, developing an embedded version of the application will be necessary, since a Java version wouldn’t be allowed to access enough of the handset’s functionality to make the application work, or be useful. Providing a thorough developers’ kit will be im-

portant. On the enterprise side, it makes less sense to leverage those connections, but to focus on developing your application with a partner like RIM -- who dominates the business market within the US – so it runs well on their BlackBerry devices. Successfully proving the application on the enterprise side with RIM will have others in the corporate space banging down your door to help port your application to their platforms. Finally, we recommend watching a few technologies very closely, that while still early in development, may make the process much easier in the future. Things like Flash Lite and Opera’s widgets could provide a much simpler path to more widespread compatibility with minimal development time, though they’re generally aimed at web-based applications. Looking even further out, there are some new players in the space, such as DartDevices, who have a compelling “virtual layer/virtual terminal” approach to mobile application development. Its system not only allows you to run a single app on many different devices, but also to access apps found on one device from any other connected device. However, the company is early on in development and faces the same problem you do in getting its platform adopted more widely first. Overall, this is not an easy problem, but focusing on the go-to-market strategy first, followed by leveraging existing relationships with key partners, while monitoring some new developments, appears to be the most likely path to success.

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

4

In si gh t Co mmu n it y R e s p o ns e s Response 1 Before you devise a strategy for building a mobile application, here are some observations of the mobile world that can influence your approach: • Standards are not your panacea for interoperability. The mobile world is filled with confusing standards, protocols and operating systems. Even within standards, carriers and handset makers pick and choose what to implement and omit. Recognize that even though standards contribute to interoperability, it might give you a false sense of portability and interoperability. • Not all mobile ecosystems are the same. In the US, carriers have more control over the options a consumer has for handsets, applications and services. In Asia and Europe where it’s more common for handset makers to sell directly to the consumers, both the carriers and handset makers have relationships with the consumers. It’s important to know who your customer is and how the chain-of-influence is ordered. • Strict paranoid requirements are part and parcel of the mobile world. Carriers spend a lot of money and effort to build and improve their mobile networks. This makes them rightfully paranoid about introducing third-party systems into their backend systems and/or their phones. • The phone is sensitive to more things than the PC. Besides the value-add of an application, carriers and handset makers also care a lot about how an application uses the phone’s limited power, memory and network I/O, and how it affects other functions on the phone. With that in mind, here are some points you should consider in devising a strategy: • Question the value of a multi-platform app. You have to evaluate whether being on multiple platforms is a feature valued by your customer enough for you to go through the effort of porting and testing it across many different phones. If not, having this requirement might drain your resources better spent working on features that differentiate your product. It might be enough to choose the most popular platform and rev your product a few cycles to get it right before you port it to other less popular platforms. For

Blogger: Hiteck example, for a business app, evolve your application with Blackberry early adopters before you certify it on other platforms. If support for multiple platforms is unavoidable, then use Java, but keep in mind that different phones and models have varying degrees of Java support. There is enough expert knowledge published on the web that you can probably avoid most of the mistakes in writing a Java write-once-test-everywhere mobile app for the phone. • Adhere to standards. Despite the state of nonstandardization today, the desire is to simplify, standardize and have flexibility. Building an application to any standard is better than defining a proprietary one. This is especially critical for applications designed for carriers or handset makers. Some companies have tried to define standards in areas where standards are weak or non-existent. However, it is a risky and expensive endeavor that might have more marketing than technical value. • Position your product like Lego. If your product is targeted at carriers or handset makers, it’s almost impossible to sell an end-to-end one-size-fits-all solution. It’s more likely that the customer will pick and choose functions they desire and require that those functions integrate nicely with their existing systems. So, it is always better to architect your product to be built out of loosely coupled components that can be easily and independently integrated with other systems. • Open source your consumer app. This is an unconventional strategy that can have a lot of benefits if done right. Let loose your source code and let the community port it to their favorite platform. Offer to certify the finished port for distribution with the mobile network. There are obvious risks here. However, having a community develop the product with you gives you access to user feedback and grassroots marketing opportunities around our product. • Open up your consumer app. This is different than open sourcing your product. This is exposing parts of your product for customization and improvements. One area that is suitable for such customization is the application UI. The mobile UI has always been a challenge due to phones having varying form factors,

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

5

screen resolutions, number pad and keyboard layouts. Since there is no practical way to optimize the app’s UI for each and every combination, the result is a less optimal, lowest-common-denominator UI. Without having to expose source code, you can open up that part of your app to customization and let the real users of each phone model hack the best UI for it. Additionally, the company can potentially create a mini marketplace where people can sell/buy customized UIs for your app, much like what some GPS vendors are doing by exposing their voice UI, so 3rd parties can provide different (celebrity) voices for audio directions. If you have to attack one platform at a time, here are some things to consider: • Consider up-and-coming platforms. Besides going with the obvious choice of the most popular and widely marketed platform, you might look into in-

novative companies providing platforms that can be disruptive to existing ones. These companies will pay more attention to early adopters like yourself, and you benefit from any attention they get in the marketplace, just by the virtue of being one of the few early adopters. This way, your product doesn’t get lost among the many choices a consumer has on a platform that attracts many vendors and developers. • Let business relationships drive the sequence. In the mobile world, sometimes it is better to evaluate the carriers/platforms/vendors based on the kind of relationship you can develop with them and go with the one that can provide the greatest opportunity for support and distribution. In this case, it is impossible to pin down any particular carrier/platform/vendor. If you use this approach, it can be educational to learn how Danger got stuck exclusively on T-Mobile, whereas Blackberry is available on all major carriers.

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

6

Response 2

Blogger: Hersh

First a little background and a rambling analysis of the options available on mobile:

developers -- we are probably the first shipping product to try to use it.

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?

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?

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

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 re-

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

7

ally 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: • If the application is simple and does not require any special hardware access (like cameras or 3D acceleration), then you should create a Java app

and either i) partner with a publisher or ii) sell direct to the carriers, assuming you have a good sales team. Avoid off-portal unless you have a powerful brandpartner or tons of money to spend on marketing. You will take the application to every carrier in the US you can get a meeting with--everyone seems to have an interesting addressable Java market. When you decide to go international the application will probably only need localization. • If the application has “high-end” feature requirements like 3D acceleration, voice processing, camera access etc. then your engineers may have an easier time developing for Windows Mobile or Symbian. However, this is only going to be interesting, given the smaller addressable market, if you can sell for a higher price point, so your application better be compelling enough to justify the price. You may as well shop it in Europe at the same time -- remember to localize to Spanish, French, German, and Italian. With the international angle you might be able to get some interest from a publisher. If you are going to try and sell direct then you need a significant sales team -- or a product that is so unique and compelling that it sells itself. • If you are going for a mass-market product, but Java just doesn’t give you the capabilities you need, then the next largest “uniform” market is BREW. You need to get a meeting with Verizon, so hire a good sales person or get a publisher. Verizon is the biggest BREW market in the US. BREW is going to give you more features than Java, but less than Symbian/Windows Mobile -- you are going to spend about $30,000 to certify your application for the minimum required number of handsets for Verizon. When you decide to go international you will end up porting to Symbian or Windows Mobile -- BREW presence outside the US is not very big, and in the EU it’s negligible.

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

8

Response 3 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. Here’s some practical advice: • The off-portal market is just starting to take form in the US, and more so abroad. This market allows you to work around the carrier as a roadblock. Your own website can sell the app, or you can work through big portals and aggregators like Handango. The major downside here is that without marketing, who is going to ever find your app? If you’re ESPN, this might work, but if you’re an unknown, you will either have big marketing costs, or low adoption. • RE: the bullet above. Carriers love to see market traction as proof of concept. If you actually sold some units off-portal, it proves the app, the concept, the demand, the functionality. Thus, and off portal channel can be used as leverage in biz dev with carriers. • No amount of marketing can equal being visible on the carrier’s deck (on-phone catalog). That’s why content/app providers suck it up to the Goliaths and hustle to get on deck. But don’t expect that to be enough. The carrier will probably do nothing to promote your app. And if my discussions with content companies are any indication, most developers are angry at the way the carriers under-marketed, miscategorized, or buried their app. YOU will need to do all the marketing. The more you know this, and develop a plan, the more the carrier will have faith in your apps ability to earn them money. • Choose the carriers you target carefully. It’s a real resource drain to try to hit the big four, and the big two in Canada all at the same time. I find it best to keep an email or phone sales strategy going with all of them, but really only do a big push with focus, demo apps, and travel for one or two. If the situation changes, and doors close or open, adjust the targets, but trying to sell all the carriers at the same time is too costly - they each assume you will be compatible with 20+ of their phones during your sales cycle, so if you attack all, you have the problem you outlined in your question. The main reason that you do not have to sell all carriers simultaneously is the lemming factor: Once you sell into

Blogger: Derek one of them, it becomes 20x easier to sell into the others with the reference case. • BTW, I’m not saying to avoid smaller carriers like Alltel, USCC, Helio, Amp’d, or Virgin. Perhaps your app/content has a particular fit with them, which might make them a principal target. Some times these carriers are more agile, and fast to adopt new ideas. But more often, they fall into the “telephone and email” sales strategy. Most content/app firms try to sell into Cingular and Verizon, simply because of scale. Good argument, but that scale also makes them slower and more arrogant. However, if your content/app requires changes on the handheld software (or, God forbid, hardware), the small carriers are much less likely to be able to work with you. That’s because, if a carrier has fewer than 10M subscribers, it is very unlikely that they can get a hardware customization out of a Samsung or Nokia. By the way, if your content/app does require specific hardware changes on the phone, that’s about as long a shot as there is. • What’s a good strategy? Start with a LCD (Lowest Common Denominator) app if you can. Take PayPal as an example. Their first app is an SMS P2P payment utility with IVR. It’s basically ugly, but it’s compatible with almost every phone out there. I would expect them to follow-up with a WAP interface, which is also LCD and compatible with a vast percentage of the live handsets in the field. Other benefits include: little testing, no NSTL BREW testing requirements or fees (notoriously high). Of course, SMS and WAP only work for the simplest information-type of apps. A First Person Shooter (FPS) doesn’t quite fit the LCD mold... So avoid FPS, and apps that rely on vector graphics, 3D, etc. If that’s what your app is, they you’re stuck with the n X n X n X n complexity matrix you described, then your game better ROCK and it’s time to go find some more venture capital! • By the way, with a LCD app, expect the carriers to not “get it”. They would rather launch a lousy 3D FPS, with vector graphics, customized avatars, and stereo sound than a useful business application that is ugly (or even not ugly -- simply put, they prefer the flash). Trust me that the people who are screening apps at the carriers are terribly unqualified to do so. That’s not necessarily a condemnation of them, since the job of making decisions for consumers is over any one’s ability. So that said, let me therefore directly condemn many of the people making the screening decisions as

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

9

clueless. As an example, I built an educational gaming app with Leapfrog (by far the market’s leading maker of educational toys), and the Leapfrog product manager had to endure multiple meetings where an (unnamed) US telco peon arrogantly told her how to best build an educational game. The gatekeepers are carriers are basically 20-somethings with enough balls that they would give Ghandi advice on how to form a peaceful resistance movement. • Enterprise apps, though less sexy, are actually an easier target, since you don’t have to worry about the carrier so much, but you can sell into the IT dept. These guys are looking for practicality and ROI, not pop and fizzle. This works better with the LCD approach. Also, it may be possible to work around the n X n device complexity issue by building a targeted enterprise app, and only developing for...say...the Blackberry OS. The challenge on this side of the business is that to sell into enterprises requires a large sales force, which is probably impractical for you, so you’re looking at partnerships in the sales channel... Ingram Micro, telcos, SIs, or such. • The platform decision is shifting, but as a short answer, perhaps BREW is the easiest thing to say (this is US-specific advice). Don’t forget that if you can do SMS or WAP, that may be better because of cost and reach. For a full environment, BREW is an easy starting point for developers because everything is mapped

out for you and you will face far fewer decisions and surprises. As your experience develops, J2ME is a reasonable second platform. Depending on the nature of the app, Flash Lite is becoming more widely used for graphical apps, but handset support for it remains thin. • When faced with n X n X n matrices, consider outsourcing testing. Since the landscape of target handsets is constantly changing, it is very costly to create your own lab. Outsourcing this step is also expensive, but less so - there’s no way around the fact that the matrix makes testing and compatibility cost money. Consider TestQuest or MobileComplete as examples of mobile app testing houses. • Outsourcing and Core Code: Many development houses create a core set of code which they re-use with all their apps. The advantages are faster development, lower costs, and easier testing. You can build your core platform yourself, license one, or outsource development to a firm that already has one. I know a bunch of these firms big and small, but you probably know the biggest ones, like ThumbPlay. • If you have a great idea for a mobile app, you could avoid all the risk and hassle by licensing your idea to one of these existing mobile development houses. But be careful you don’t get your idea stolen!

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

10

Response 4

Blogger: jimh

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.

ket. Reputation for being difficult to develop on is reducing with newer development tools, but don’t try this with a rookie development team. The new OpenC libraries will make porting existing C++/C applications far quicker.

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.

Palm - U.S. market only, and dying fast.

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:

Linux - Fragmented, no overall target yet.

Java - J2ME - On countless millions of handsets globally, a first glance a good choice, but remember the writeonce debug-everywhere and consider restricting your development to a few target handset models. BREW - Great in certain U.S. markets, virtually unknown elsewhere. Symbian S60 - The biggest selling smartphone OS by far globally, but has a minority share of the U.S. mar-

Windows Mobile - Has a good chunk of the U.S, market, but again a bit-part player elsewhere. i-mode - No significant presence outside Japan. Flash Lite - Now appearing on S60 handsets, so potentially a big market, but is it too restricted for your application?

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.

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

11

Response 5 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 preloaded 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%

Blogger: mgrosx 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.

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

12

Response 6 This is definitely a tough question, a few points first : If you want to address 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),

Blogger: alex 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/S60, then Motorola (Java), Sony Ericsson (Java), HTC (Windows Mobile) and you have most of it...

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

13

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

Blogger: mikerowehl 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.

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

14

Response 8

Blogger: daniel.taylor

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

Techdirt Insight Community — Mobile Application Development Strategies, March 2007

15