dw2

29 January 2010

A strategy for mobile app development

Filed under: Agile, applications, consulting, fragmentation, mashup* event, mobile web — David Wood @ 12:15 am

The mashup* event in London’s Canary Wharf district yesterday evening – hosted by Ogilvy – addressed the question,

  • Apps: What’s your strategy?

The meeting was described as follows:

This event will help people in strategic marcomms roles understand the key challenges with respect to apps and identify the building blocks of an app strategy:

  • What are the platform choices?
  • What are the app store choices?
  • What devices should you support? …

mashup* is bringing together several industry experts and specialist developers to help demystify, clarify and explain the issues around the rapidly emerging Apps channel…

The event was sold out, and the room was packed.  I didn’t hear anyone question the need for companies to have a mobile strategy.  Nowadays, that seems to be taken for granted.  The hard bit is to work out what the strategy should be.

One of the speakers, Charles Weir of Penrillian, gave a stark assessment of the difficulty in writing mobile apps:

  • For wide coverage of different devices, several different programming systems need to be used – apart from those (relatively few) cases where the functionality of the app can be delivered via web technology;
  • Rather than the number of different mobile platforms decreasing, the number is actually increasing: fragmentation is getting worse;
  • Examples of relatively new mobile platforms include Samsung’s bada and Nokia’s Maemo.

One mobile strategy is to focus on just one platform – such as the Apple iPhone.  Another strategy is to prioritise web-based delivery – as followed by another speaker, Mark Curtis, for the highly-successful Flirtomatic app.  But these restrictions may be unacceptable to companies who:

  • Want to reach a larger number of users (who use different devices);
  • Want to include richer functionality in their app than can be delivered via standard mobile browsers.

So what are the alternatives?

If anything, the development situation is even more complex than Charles described it:

  • Mobile web browsing suffers from its own fragmentation – with different versions of web browsers being used on different devices, and with different widget extensions;
  • Individual mobile platforms can have multiple UI families;
  • Different versions of a single mobile platform may be incompatible with each other

The mobile industry is aware of these problems, and is pursing solutions on multiple fronts – including improved developer tools, improved intermediate platforms, and improved management of compatibility.  For example, there is considerable hope that HTML 5.0 will be widely adopted as a standard.  However, at the same time as solutions are found, new incompatibilities arise too – typically for new areas of mobile functionality.

The suggestion I raised from the floor during the meeting is that companies ought in general to avoid squaring up to this fragmentation.  Instead, they should engage partners who specialise in handling this fragmentation on behalf of clients.  Fragmentation is a hard problem, which won’t disappear any time soon.  Worse, as I said, the nature of the fragmentation changes fairly rapidly.  So let this problem be handled by expert mobile professional services companies.

This can be viewed as a kind of “mobile apps as a service”.

These professional services companies could provide, not only the technical solutions for a number of platforms, but also up-to-date impartial advice on which platforms ought to be prioritised.  Happily, the number of these mobile-savvy professional services companies (both large and small) is continuing to grow.

My suggestion received broad general support from the panel of speakers, but with one important twist.  Being a big fan of agile development, I fully accept this twist:

  • The specification of successful applications is rarely fixed in advance;
  • Instead, it ought to evolve in the light of users’ experience with early releases;
  • The specification will therefore improve as the project unfolds.

This strongly argues against any hands-off outsourcing of mobile app development to the professional services company.  Instead, the professional services company should operate in close conjunction with the domain experts in the original company.  That’s a mobile application strategy that makes good sense.

17 July 2008

Mobile development in a hurry

Filed under: Mobile Monday, mobile web, Symbian Press — David Wood @ 12:18 pm

“Google Mobile are moving all development away from downloadable apps to the mobile web”

That’s a message mjelly records Charles Wiles, product manager for Google Gears for mobile, as making at this week’s MoMo London event.

I was at the same event. I’m not sure I remember hearing quite such an emphatic message as mjelly reports, but I do remember hearing the following:

  • Eric Schmidt (Google CEO) has been asking the Google Mobile team why they only make one app release every six months, whereas development of apps for PC web-browser happens much more quickly
  • Downloadable apps for mobile devices are fraught with problems – including BIG issues with device fragmentation
  • Taking Google Maps for mobile as an example: there are 10+ platforms to support, requiring 100’s of builds in total – it all adds up to PAIN
  • There must be a better way!
  • The better way is to deliver services through the mobile web, instead of via downloadable applications.

I’ve heard this kind of message at previous MoMo London events, from lots of different speakers. Downloadable applications (whether written in native C++ for in Java) introduce lots of problems with development, deployment, and usability, whereas mobile web apps are a whole world simpler. The message that comes across is: If you want rapid development that in turn allows rapid innovation, stick with the mobile web. It’s not a message I’ve enjoyed hearing, but I can’t deny that lots of speakers have said it (in various different ways).

But what made the presentation from Charles Wiles all the more interesting was that, after highlighting difficulties facing downloadable mobile apps, he was equally critical of mobile web applications (which run inside a web browser environment on the device):

  • Mobile web apps suck too!
  • Javascript takes time to execute on mobile devices, and since it’s single threaded, it blocks the UI
  • There’s often high network latency
  • The mobile web apps lack access to location, the address book, and camera, etc.

It’s for this kind of reason that Google has continued to release downloadable versions of their most popular applications. (Incidentally, pride of place on the Quick Access bar on my Nokia E61i idlescreen are the native C++ versions of Google Search and Google Maps. They’re in that pole position because I find them both incredibly useful.)

It’s also for this kind of reason that Apple’s initial message about how to develop apps for the iPhone – that developers should just write web applications – was so poorly received. Would-be iPhone developers strongly suspected they could achieve better results, in many cases, by writing downloadable apps. This expectation has been vindicated by the heady events around the recent launch of the iPhone application store.

Four challenges facing mobile web apps

The four factors I generally highlight as limitations in mobile web applications vs. downloaded apps are:

  1. The UI provided by a web browser is general purpose, and is often sub-optimal for a more complex application on the small screen of a mobile device (an example of the unsuitedness of the web browser UI in general is when users are confronted with messages such as “Don’t press the Back button now!” or “Only press the OK button once!”)
  2. Applications need to be able to operate when they are disconnected from the network – as in an airplane or during a trip in an Olde World London underground train – or whenever reception is flaky. On a mobile device, the user experience of intermittently connected “push email” from the likes of BlackBerry is far more pleasant than an “always connected web browser” interface to server-side email
  3. Web applications suffer from lack of access to much of the more “interesting” functionality on the phone
  4. Web applications are often more sluggish than their downloaded equivalents.

Exploring two routes to improved mobile apps

So what is the best answer? Improve native mobile app development or improve mobile web app development? Unsurprisingly, the industy is exploring both routes.

To improve mobile web app development:

Each of these initiatives (and I could have mentioned quite a few more) is significant, and each deserves wide support. Each of them also faces complications – for example, the more AJAX is included in a web application (addressing problem #1 of the four I listed above), the more sluggishly that application tends to run (exacerbating problem #4). And as web applications gain more access to underlying rich phone functionality, complex issues of security and application validation rear their heads again. I doubt if any of these complications are fatal, but they reinforce the argument for the industry also looking, in parallel, at initiatives to improve native mobile app development.

To improve native mobile app development, Symbian has been putting considerable effort over the last few years into improved developer tools, developer documentation, APIs, and so on. The results are encouraging, but the job is far from done.

Quick recipes on Symbian OS

One of the disincentives to doing native application development on Symbian phones is the learning curve that developers need to climb, as they become familiar with various programming idioms. That’s a topic that Kari Pulli (Nokia Research Fellow) discussed with me when he visited Symbian HQ back in Fall 2006. Kari had in mind the needs of people (especially in universities) who were already good C++ developers, but who don’t have a lot of spare time or inclination to learn brand new programming techniques.

We brainstormed possible titles for a new Symbian Press book specifically targeted at this important developer segment:

  • “Symbian progamming in a hurry”?
  • “Hacking Symbian OS”?

In the months that followed, this idea bounced around inside Symbian, and gathered more and more support. The title changed in the process, to the more ‘respectable’ “Quick Recipes on Symbian OS”. Michael Aubert stepped forwards as the lead author – you can read an interview with him on the Symbian Developer Network. Happily, the book went on sale last month. For my hopes for the book, I append a copy of the foreword I wrote for the book:

This book has been designed for people who are in a hurry.

Perhaps you are a developer who has been asked to port some software, initially written for another operating system (such as may run on a desktop computer), to Symbian OS. Or perhaps you have to investigate whether Symbian OS could be suited to an idea from a designer friend of yours. But the trouble is, you don’t have much time, and you have heard that Symbian OS is a sophisticated and rich software system with a considerable learning curve.

If you are like the majority of software engineers, you would like to take some time to investigate this kind of task. You might prefer to attend a training course, or work your way through some of the comprehensive reference material that already exists for Symbian OS. However, I guess that you don’t have the luxury of doing that – because you are facing tight schedule pressures. There isn’t sufficient slack in your schedule to research options as widely as you’d like. Your manager is expecting your report by the end of the week. So you need answers in a hurry.

That’s why Symbian Press commissioned the book you are now holding in your hands. We are assuming that you are a bright, savvy, experienced software developer, who’s already familiar with C++ and with modern software programming methods and idioms. You are willing to work hard and can learn fast. You are ready to take things on trust for a while, provided you can quickly find out how to perform various tasks within Symbian OS. Over time, you would like to learn more about the background and deeper principles behind Symbian OS, but that will have to wait – since at the moment, you’re looking for quick recipes.

Congratulations, you’ve found them!

In the pages ahead, you’ll find recipes covering topics such as Bluetooth, networking, location based services, multimedia, telephony, file handling, personal information management – and much more. In most recipes, we provide working code fragments that you should be able to copy and paste directly into your own programs, and we provide a full set of sample code for download from the book’s website. We have also listed some common gotchas, so you can steer clear of these potential pitfalls.

Since you are in a hurry, I will stop writing now (even though there is lots more I would like to discuss with you), so that you can proceed at full pace into the material in the following pages. Good speed!

Create a free website or blog at WordPress.com.