Mobile Web Technologies Tide is Turning?

allthingsd.pngThere’s a thought-provoking article at at AlThingsD that observes that the Mobile Tide is Turning Towards Full-Fledged Apps rather web-based technologies. It describes the case of Facebook and to a lesser extent Quora who have embraced native rather than web technologies.

The lesson here is that if you want the best user experience you have to go native. However, remember not everyone needs ‘the best experience’ and it’s possible to trade this for quicker, less expensive development and more flexible cross-platform deployment by using HTML5 development. I see the more dangerous scenario as one where a company takes on HTML5 development without really knowing they are making a tradeoff. Trying to get HTML close to the user experience of a native app costs a huge amount of effort that might as well have been spent on native apps. Conversely, if you know and accept, rather than fight, HTML5’s limitations then its advantages will be maximised.

There are three main areas to consider…

  • Look and Feel: It’s possible to get HTML close to the look and feel of Android and iOS but it takes a considerable amount of effort due to browser fragmentation. If you want an Android/iOS look and feel then I would recommend you go native. If you want more of a custom, branded look then HTML will be ok.
  • Functionality: If you are just displaying information then HTML5 is ok. If you are doing lots clever things with the information together with phone features (improving the user experience) you should go native as adding many of these things via web technologies ends up being either impossible or will require native code written anyway (e.g. for PhoneGap).
  • Performance: The main issue here, for non-games, is usually scrolling. Less smooth scrolling is the tradeoff for using HTML5.

12 September UPDATE: Mark Zuckerberg admits wasting 2 years on HTML5

Web App Tips

People underestimate the effort required to create a great web app. They tend to get blinded by the write-once promise but in practice it can quickly turn into a nightmare. Brian Leroux takes a deep look at in his presentation on how the mobile web is a mess. I have previously written a lot about this (see the related articles below).

However, there are still some types of project, particularly self-promoted information-heavy apps, where web apps can make sense. Think very very carefully if you really need a web app or whether a normal ‘desktop’ web site will suffice. Keeping with the latter will save a lot of pain. If you do decide to create an app using web technologies, here are some high level tips to get you started…

  • Decide what devices you are going to support. No, you can’t support them all. Plan to fully test the devices you choose to support.
  • Think about the implications of different screen sizes and orientations. More specifically, think about families of different graphics sizes. Consider using common layouts to simpify moving between horizontal and vertical orientations.
  • Don’t make it look like iOS.  It’s like asking Ford car owners to use a Mercedes steering wheel in their car. Try to give the app a generic web theme that uses touch gestures when available on the device.
  • Consider what’s necessary to make the app secure. Motorola MOTODEV has a new article on Designing HTML5 Apps that includes tips on the security of offline storage, cross-origin resource sharing and web sockets.

Mobile Frameworks and Custom UIs

dotnet.gifIf you are looking for a good primer on how to choose a mobile framework for your app then you should take a look at "The developer’s guide to mobile frameworks" on the .dot magazine website. The author, Jonathan Stark, is correct. The actual choice very much depends on the needs of the project. 

One problem with web and webview hybrid apps is styling to get an iOS or Android look and feel. I am seeing many big brands’ apps forego this completely as a) It’s so complicated and takes an excessive amount of effort b) You’ll never get 100% look and feel c) It entails including lots of (large) javascript libraries that have their own bugs and d) The brand ‘look and feel’ across devices is more important than being consistent with other apps on the same device. This last point takes me back to 2007 when I talked about ‘Native or Custom UI?’ within the context of a wholly native app.

Android iOS Side-by-Side Development

smartcompany.gifAn article at Smartcompany describes a phenomenon I have been seeing for the last few months. 

"There is definitely more demand for Android development. It just used to be iOS, but now it’s more Android. We just got so many emails asking where the Android versions are."

More companies are starting to expect to develop an Android app along with an iOS app. While the article is Australia-centric, I think this is happening Worldwide.

The flow of Android jobs started last November when the number of Android devices increased significantly. At that time, I started getting more requests for ports from iOS to Android. The problem with these kind of jobs is that they are usually specified such that the Android app looks like an iOS app. It’s much better, and much less expensive to use Android UI idioms.

Today, companies are thinking more about developing iOS and Android side-by-side which is better as it encourages the UI designer to think deeper how things should be represented on the respective devices. It also allows developers to think more about shared code (Android via NDK) for when there’s more complex business logic. Unfortunately, it also encourages developers to try sharing in-app web/javascript-based approaches that can quickly get complex when trying to retain the underlying platform’s look and feel.

Relative Time Spent Using Apps

nielsenwire.gifNielsen has some statistics on the total time spent on apps and web, the proportion spent on each and a breakdown of apps that account for the majority of the time.

  • An hour a day is spent interacting with apps and web
  • 67% of this time is spent on apps
  • The top 10 Android apps account for 43 percent of all the time spent by Android consumers on mobile apps
  • The top 50 apps account for 61 percent of the time spent


What does this mean for mobile developers? At first sight you might conclude that it’s better to develop an app rather than for the web. You might also conclude that unless you are a ‘top’ app your app might not get much use. However, as with many other mobile issues, "it depends".

It’s not surprising a low number of apps account for a large percentage of the time. These apps will be email, social networking and other such apps that run in the background and are communication tools. No utility app is going to be able to compete on time spent. However, it doesn’t mean it won’t be run regularly, possibly for a short time, and become useful.

The main reason people choose apps over the web is usability. Apps are both easier to discover and easier to use. However, if you are a large company, lets say for example a large brand, you can easily channel people to the web. Time spent on the ‘web app’ can make it close to, but never totally as good as, the usability of an app. You can leverage the size of your company/brand to negate the time spent on apps vs web issue. This is what large publishers are already starting to do, but for other monetary reasons, in moving their apps off the Apple App Store and onto the web.

The two learnings from this are not to take statistics at face value and think how you can use existing company assets to create contrarian strategies. 

Google Mobile Sites

google.gifA while ago I mentioned how many mobile ads have nothing to point to and that companies should really have a cross PC and mobile strategy.

Yesterday, Google sites introduced support for mobile that provides a quick and easy way to solve these problems. However, it only claims to support iOS and Android (i.e. HTML based browsers) but does nothing for the very large (although radidly decreasing) installed base of WAP browsers. Google has put together a video promoting it for use by companies but, in reality, I am not sure how many companies want a mobile site that doesn’t use their own domain name. Also, this does nothing to help create dynamic web sites (sites with any changing data). I suppose it’s a start and better than nothing.

Mobile Web Templates and Guidelines

nokia.gifNokia have just announced that they have updated their mobile web templates that I first mentioned May last year.

The templates allow mobile web sites to be easily created that have a generic mobile look and feel. They can also be embedded in apps (read into a HTML control) but I wouldn’t recommend doing so as the look and feel won’t be much like a native app. The latest templates (v2) have been restructured for easier customisation.

While you are on Forum Nokia, also take a look at their Javascript Performance Best Practices that are also useful for anyone (not just Nokia related) using HTML5/Ajax/Javascript.

I still think there’s a general nieve belief that because authoring simple HTML is easy and readable on all platforms, it will become the de facto standard for mobile development. In practice, the templates show that there are issues with the UI. There are problems with browser fragmentation. The Nokia Javascript best practices also demonstrate coding can be tricky.

In 2007 I mentioned that we were missing the phone feature APIs needed to create HTML apps. This is still true today. As I mentioned later in that article, I believe that even when (maybe I should now say ‘if’) they become available, the complexity/differences of the APIs will percolate up to HTML to make development as difficult as native.

However, I am now starting to believe that it might be possible that future development tools will be able to abstract away some of these UI, Javascript and fragmentation complexities. It’s an opportunity for someone.

HTML5 Bits and Pieces

float.gifIf you are developing HTML5 apps within an App wrapper such as PhoneGap, you ought to take a look at Float Mobile Learning’s Developing Better PhoneGap Apps.
Coincidentally, there’s also an interesting story today on how all HTML5 apps aren’t necessarily treated the same on iOS 4.3.