Every now and then something comes and just delivers. These moments feel awesome, don’t they? I had one such experience today, so let me share it. Hailo (Crunchbase profile here) solves one of the world’s (well, for the time being, London’s) little problems, namely to hail a cab. You either stand around waving futiley around only to have people being picked up left, right and center (but never you) or you fiddle with phone numbers and hope they’re not busy, etc, etc.
Hailo is the self-proclaimed Taxi Heaven. And you know what? They certainly delivered. Here’s how it works: (1) get their app (for the time being available on iOS and Android). (2) fire up the app, it locates you and tells you how long you’d have to wait (6 minutes in my case). (3) press a button to “hail” the cab and you’re done.
The app keeps you up to date with progress (tour confirmed, updating ETA, etc). You can call the cabbie (who is provided to you by name) if you want, too. You can choose to pay with cash or by card (you can store your credit card in your profile and even add tips automatically). You take your ride. You pay. And if all that wasn’t enough, they even send you a receipt by e-mail.
It works like a poem. B-e-a-utiful! I am a sucker for betas but as you know (if you are equally inclined) that often causes frustration, too, because, well, it’s bloody beta. If what Hailo delivered is beta (and they’re early!), then their “gold” release will have you sinking to your knees.
Hailo is approved by TfL (Transport for London, the city’s transport regulator) and works (only) with “black cabs” (they are the nice, iconic official ones). For the drivers, they seem to be trying to make it easy AND add functionality: no hardware, no subscriptions, no exclusivity. Additionally, they use the drivers’ app (different to what me mere mortal uses) to spread word on traffic, status of any taxi ranks (100 cabs waiting for customers? Go somewhere else…).
Hailo, you guys rock!
A fairly wonderful conference will open its doors on 27 October in London, UK, namely Games for Brands, an event where we will do just that: investigate if and to what extent games may work for brands. Just speak to Barclaycard (their Waterslide Extreme game [done by Fishlabs] did more than 14m downloads on iOS) or Volkswagen (multiple games by Fishlabs [again]) for the Polo and others and a special VW Golf GTI edition of Real Racing by the recently acquired Firemint).
The event features a fairly cool line-up, too, including speakers from:
- Rovio (they of Angry Birds fame)
- Channel 4
- Wellcome Trust (yes, they’re the Glaxo Wellcome guys)
- Matmi (they did games and apps for instance for Lily Allen, Gorillaz, United.com and Vimto – the seriously mixed-up fruit)
- and, yes, I will be talking again, too (but when don’t I?)
I also have a goodie for the readers of this blog: four of you can get a very special discount and attend for £95.00 only. Tempted? Contact me (either via e-mail or Twitter or through the contact form here).
It’ll be a good one, so come along!
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.
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.