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

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:

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!”)

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

Web applications suffer from lack of access to much of the more “interesting” functionality on the phone

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.

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!

Like this:

LikeLoading...

Related

You might want to take a look at our approach to solving the mobile app problem..

We made the browser contextually aware of who, what and where you are on mobile. The browser can now change it’s menus based on information that is sent to the web service and then back down to the device.

This solution works fine on Blackberry and Windows Mobile and has been designed with all other mobile platforms in mind including Symbian.

One of the big advantages is the ability to do (for example) real time GPS enabled local search. The mobile device simply sends the web service the GPS coordinates as part of the web request (via the browser). You can then mash out this data to any service that needs it and deliver location based results inside the browser.

For developers we even came up with a cross platform mobile developer tool. You can decide what device, user and location information you need and then have the Mobile Application Generator simply build everything you need (the widget) on the fly for multiple mobile platforms.

>You might want to take a look at our approach to solving the mobile app problem..

>We made the browser contextually aware of who, what and where you are on mobile. The browser can now change it's menus based on information that is sent to the web service and then back down to the device.

>This solution works fine on Blackberry and Windows Mobile and has been designed with all other mobile platforms in mind including Symbian.

Happy to show you a demo. We can do it live over the web. Just takes a few minutes and I’m sure you’ll be intrigued at the possibilities that having access to the operating system API’s in real time via the browser (and in turn allowing that data to be available to the web app) can offer mobile software developers.

Please send me an email at peter dot cranstone at 5o9inc.com and we can set up the demo.

I think there’s a third which, had manufacturers paid close attention to at the beginning, might have sidestepped this entire ‘problem’ – that of phone UI design.

Smartphone manufacturers want to sell phones as platforms (rather than simply as out of the box devices). You’d have thought that they would therefore paid more attention to easing the process of getting an application onto the phone in the first place. If you want people to add functionality to phones, then the user interface has to encourage them to download, install and use. It has to be friendly enough so that the ‘average user’ feels as confident in adding apps to a phone and accessing them as they do with adding apps to their PC/Mac.

At the moment most smartphones are like Linux boxes (the technical community is very excited by them but when assessing the UI use a definition of ‘easy to use’ not shared by the wider population).

It’s no wonder that web-based applications are seen as a possible alternative. Users understand browsers in a way they do not understand the working of the sometimes appalling UIs shipped with many smartphones. Apple seem to have understood this and as a result have found a gap in the market big enough to drive several thousand iPhone-laden 18-wheelers through.

It doesn’t matter how great your apps are, if the end-user doesn’t understand intuitively how to get them onto the phone and working, they aren’t going to sell.

>Smartphone manufacturers want to sell phones as platforms (rather than simply as out of the box devices). You'd have thought that they would therefore paid more attention to easing the process of getting an application onto the phone in the first place. If you want people to add functionality to phones, then the user interface has to encourage them to download, install and use. It has to be friendly enough so that the 'average user' feels as confident in adding apps to a phone and accessing them as they do with adding apps to their PC/Mac.

>At the moment most smartphones are like Linux boxes (the technical community is very excited by them but when assessing the UI use a definition of 'easy to use' not shared by the wider population)…

>It doesn't matter how great your apps are, if the end-user doesn't understand intuitively how to get them onto the phone and working, they aren't going to sell.

But Apple isn’t the only company with an Application Store. What I’d like to do, given more time, is to compare the Apple AppStore functionality with that available for Nokia S60 phones via their Download! service at http://www.download.nokia.com/

Here’s a very quick first impression of the Nokia service. When you go to the page you can see on the left hand side a section which asks you to enter your country, operator and phone type.

In this day and age it’s hard to believe that we still have to do that. Why doesn’t the web site know Where I am, What device I’m using and Which Operator service?

This is what continues to amaze me. The amount of friction in the transaction.

We have this really simple demo that shows the web service who I am, where I am and what device I’m using plus which operator service I have plus the usable canvass size of the screen so you can deliver a great web page that fits correctly.

The very second you log on to Nokia’s download service it (they) should know all this information.

They control the ecosystem – why can’t their phones indicate terminal and device capabilities in real time via HTTP?

Now for Nokia’s bigger problem (bigger opportunity). They really want to become a Mobile Internet Services company – in which case they should be delivering compelling value from their site to every other mobile device that isn’t any iPhone.

The future is clear – it’s one platform (the Web), it’s one interface (the browser) and it’s multiple data sets (the context). Nokia have an incredible opportunity to do what no other mobile operator/developer has done – namely deliver Mobile Software as a Service across multiple devices using nothing more than the browser and the web.

Right now there is still too much friction in the transaction – Apple have done a better job because they own all the end points – Nokia should win the war by owning the rest of the market.

PS. Just for grins I logged on to the download site with my Blackberry – it just blew up my browser. This is why Nokia is having a tough time – first experiences count and Apple know how to deliver something credible and compelling.

You make a great point about the user (customer) and how they already understand how to use a web browser. In Mobile it’s all about the 0-1-2-3 rule:0: behavioral changes1: login 2: second response time3: clicks to relevant content

Apple have got control over the entire ecosystem – they know who you are, exactly what device you are on and it’s capability, plus they now know where you are. Critical pieces of information when you want to deliver a great customer experience.

No other mobile platform currently offers “web services” that level of frictionless interaction – yet.

David,Thanks for an extremely interesting article.I am a founder of a start up that developed the next generation media player for handsets. (“TuneWiki”).Our beta launch of the product was on the iPhone platform, and we were adopted by more then 1 million users in several months.We have struggled whether to do a full application or a web application…and ended up in the middle…having an hybrid application that plays the music and the lyrics synch (one of the additions that we have for the mobile player) through the application and the social network in a browser inside the player application. We found this to be best of all worlds as some of the requirements of our player are different in each platform.But the major decision to go on the iphone was the readiness and ease of use of the hardware and the operating system of the iPhone to adopt our application. We found the basic same capabilities on the Android Platform (..and We won in the Android competition..), yes, hardware is still missing unfortunately….Do you think this is a limitation of the Symbian operating system and the hardware behind it? We would love to try and build the same successful experience on the Symbian OS, do you think this might be possible?

“But Apple isn’t the only company with an Application Store. What I’d like to do, given more time, is to compare the Apple AppStore functionality with that available for Nokia S60 phones via their Download! service ..”

A key point. I’ve been a Nokia user for several years until recently (the iPhone) happily juggling my Nokia phone and 770 tablet. But I was only peripherally aware of the existence of the Nokia download service.

>Apple isn't the only company with an Application Store. What I'd like to do, given more time, is to compare the Apple AppStore functionality with that available for Nokia S60 phones via their Download! service at http://www.download.nokia.com/.

I’d missed the fact that, in AllAboutSymbian, Steve Litchfield had already carried out a searching review of Nokia Download vs. Apple’s AppStore. The title of the posting gives a good flavour of the conclusion: “Download! – absolutely no excuse“. The comments at the AAS site (52 so far) make sobering reading.

Hi David, thanks for writing a very interesting article. I think you’ve pointed out some fundamental problems that are intrinsic to both mobile web applications, and platform native applications. I think that the fragmentation we’re seeing in the mobile space is much the same problem that we saw on PC platforms before Windows. There was so much variability in the platforms that developers had to write separate versions of their applications for each version of each platform, that it became incredibly difficult to write applications that were actually useful. Now near-universal operating systems like Windows and Linux solve this problem for developers. The OS handles all of the interactions with the various platforms. Developers just have to write their applications to run on the OS, and then they can be confident that it is available to all devices that run that OS. The mobile web solves this problems, in its limited way, but it doesn’t take advantage of the unique properties of mobile devices, the ability to relate the software application and activities to the mobile, physical, real world in which the user is operating. At GoLife Mobile (www.golifemobile.com) we are creating a hybrid platform which brings together the best of both worlds: a cross-platform application framework that gives developers a consistent, familiar environment to create ‘write-once/run-any’ applications (like a mobile browser), and at the same time acts like a server-client framework, where all the heavy-lifting is done by the server with minimal load on the client. This combination lets developers easily create applications that run quickly, lightly, and anywhere, enhance and are integrated with the device’s properties and capabilities, and fit into the user’s mobile lifestyle.

The key to mobile (just like any other platform) is getting developers to develop to it. The more you can do to reduce the friction the greater the number of developers.

The OS should simply handle all the necessary work and the developer should just write the app in the best language for that platform.

The critical part comes next – how do I connect that app to the Web. Simple socket calls have been the approach up until now. It works, and all you have to do is keep up upgrading your app as your “service” changes.

However this approach is costly and time consuming.

So what’s the alternative – leverage everything that is currently in place – yet make it smarter.

Take the HTTP protocol which was designed to be extensible and extend it to support more “context”.

In fact a VP of Nokia was talking about this the other day. He said that it’s currently impossible to get all the context from the mobile device as you would have to know everything about the device.

He’s “incorrect”. You write the app that asks the device what you want to know – simple programming techniques as already mentioned.

The clever part comes next – instead of making a socket call to the web service – add it to the HTTP protocol and the request being made to the web service.

This way the “web service” knows (has) the context it needs to deliver the right web service via the browser – now you can use HTML/XHTML to deliver a great customer experience without the customer having to learn anything new.

The simplicity of this approach is that no new hardware is required and it leverages all your existing infrastructure and programming expertise.

Everyone wants to keep adding platforms which customers (there’s the really important word) don’t want to manage. They want to use what they have – just in a smarter more efficient way.

Ironically the HTTP protocol allows for this to take place (RFC 2616 Sec 12.1 pay special attention to the disadvantages section – it’s wrong)