If you are in the North-West of England and have nothing to do or, rather, nothing really, really important to do, you may want to drop in for our latest Mobile Monday Manchester edition, which takes place tonight starting at 6pm at the BBC in the brand-spanking new MediaCityUK.
The topic of the night will be “Second Screen” and we will have people from all corners of that: speakers from the Beep itself, companies providing infrastructure and service as well as creative agencies that deliver on these screens.
More info here. To join us, please sign up here (there is only standing room left though…).
There seems to be a new round of buzz around the good old HTML5 vs native debate or, in other words of web vs apps. We had a Mobile Monday session in Manchester (@momomcr) on this, debate on ForumOxford is flaring up again, and more… So I thought let’s do this again and see – if anything – changed since I posted about this (for the record: here’s the first post from 2009 and the second one from 2010). Where has the battlefield moved to in the interim?
Mobile apps must die
There has been (as you may have sharply derived from this post’s title) a post from Scott Jenson, the Creative Director of Frog Design (they of much Apple fame – you know, they designed the Apple IIc and such), which he entitled – somewhat combattively – “mobile apps must die”. His argument is, in short, that the mobile desktop cannot cope with the plethora of native apps (or app icons?) and that it would be much better to use dynamic “use it and lose it” approaches for which the web is perfectly suited. He starts of on the value vs pain paradigm: if the balance is less than 0 (i.e. value exceeds pain), the solution wins. And he posits, that native apps don’t do that.
I am not doing the intellectual argument Scott poses any justice here (and I will pick up on some more points further below), so please make sure to read his post!
One size does not fit all
The challenge is to find a universal solution, I suppose. Jenson focuses merely on apps that – arguably – make a user’s life better if and when he/she is out and about and is looking for utilities to help mundane tasks/etc. There are tons of fairly one-dimensional apps for that: a retailer app for their catalogue, London tube map, some couponing app, a mobile banking app, apps using NFC, Bluetooth, camera (QR readers) and more. There will also be more complex ones: fancy AR-powered things, things like Foursquare (anyone near?), etc, etc. So, is this painful? Yes, it is. Would it be better if there was a seamless universal (cloud-based) solution that would make it “just so”? Oh, by all means.
BUT… it would not solve all use cases for smartphones (or mobile computing in general). There are tons of applications and use cases that are not the out and about equivalent of a Google search (and, yes, I am fully aware that 40% of Google mobile searches relate to locations), and I would posit that one has to judge each one on its own merits.
UX
The starting point should always be the user experience. Jenson points out correctly that this is not only about the perceived value of the product or service in isolation but it is more of a function: if the perceived value exceeds the pain to use it, it works. If pain exceeds the perceived value, it doesn’t.
But it is this very statement where things with Jenson go horribly astray. There is a reason why Apple has not yet moved Keynote to a cloud-based SaaS solution but keeps selling it as a stand-alone app: because it works better. The perceived value of using the product far exceeds the pain of having to download and install the application.
Tackling the shortfalls
When looking at the UX chain (from product to discovery, maintenance, management and use), there is more than one answer to shortfalls of some of these elements. Rather than moaning about distribution and app management, one can also improve those processes. The OS-based app store model all but replaced the carrier stores for smartphones now, and why? Because the end-to-end solution is less painful (not only for users of the apps but also for its producers!).
It is possible to draw a map of this (and I would if I possessed more artistic skill) where you could derive on what is right for you: if you need access to hardware APIs (camera, 3D acceleration, Open GL ES, etc), native might be your way (one of the reasons why you are not seeing higher-end HTML5 games in large numbers yet). If you capture light-weight information-heavy content that relies on dynamic updates, a web “app” might be good for you, in other cases, a native app with some functionality coupled with a container for web functionality might be the right way.
So there we have it: it still is the old “it depends” answer. Having said that, with webkit and HTML5 adding functionality all the time, ever (?) improving bandwidth and better compliance on the browser side, the usecases for native apps will likely get less over time. Will it happen in full swing in the next 18 months or so? I doubt that very much.
Tonight (11 July), Mobile Monday Manchester opens its doors at Dukes 92, 18-20 Castle Street, Manchester, M3 4LZ (map). Our topic of the night will be Mobile Apps vs Mobile Web. We’ll put two teams against each other with short presentations making the case for apps and the web respectively, followed by a panel discussion.
As of last night, we had already had more than 120 registrations, so hurry if you want to come along. Registration is still open here.
