Qatar Airways launched a sparkling mobile version of its website this week and raised the question once again over how to prioritise mobile web development.
The Middle Eastern airline created the new service in conjunction with mobile content specialist Mobiqa, allowing passengers to fulfil a range of tools.
Customers can check-in, view flight status, select seats for departure as well as find out information on services and the airline.
As with most mobile websites, a browser is automatically detected so functionality and screen size can be optimised for the user.
Qatar has opted for the service over developing other types of check-in and passenger tools, boasting that the system works “without the need to download an application”.
This leads to an interesting question, and one which many airlines and other travel suppliers and services will no doubt be grappling with as they develop a mobile strategy.
What are the advantages of mobile browser version of a site over a dedicated app?
For some it will be development costs and the prohibitive nature of focusing resources on a product for one or more types of handset, rather than a general mobile web version.
But perhaps the flipside of the argument is whether the additional, not critical content such as guides and other information, which can be viewed without data roaming, is a value-add for customers and should be pushed into an app.
This looks like a brave face on the fact that their apps aren’t ready yet … or they’ve been sold a pack of goods.
The difference between a mobile website and an app is the difference between flirting and dating. Have a look at your or a friend’s iPhone – every one of these has the ability to save a webpage to the desktop as a “web app”. What’s the ratio of (regular) apps to web apps? That metric is a pretty good expression of how users want to experience information on their mobile devices.
I’d wager a guess that if you are an airline, the majority of folks will hit up your website on their mobile before checking if you have a mobile app to download. I’d look to the ratio web traffic on mobile vs downloaded apps for a more reliable metric.
Part of the beauty of the app stores is letting those that aren’t already familiar with your content discover it and giving publishers a way to sell content again. Then again, part of the beauty of web apps would be that you would be more visible in Google’s mobile search. Not to mention the fact that it’s cheaper to develop and immediately has a *much much* bigger reach.
The argument isn’t about reach, or about not doing a mobile site at all – it’s if you’re using a smartphone capable of modern apps (and thus probably fall into a pretty good to fantastic demographic) what to you prefer your companies to be providing you.
Air Canada provides an app, and I suspect (though I have no way of verifying) that iPhone users quickly switch over to this from whatever AC provides for a mobile service (http://mobile.aircanada.com/). Likewise for TripIt (http://m.tripit.com/).
To reiterate, it’s not either/or, it’s both because you have to reach users where they are, not where you want them to be. (That’s a good article on this subject BTW)
It *is* actually possible to make “not critical content such as guides and other information” viewable offline using a web app (ie. making data roaming costs a non-issue). Not many have gone this path yet, but with android making the strides it is, I think mobile web apps will be making quite the comeback.
Certain things like games are much better suited for downloadable apps (although there have been some mighty impressive games developed in html5 that feel just like ‘offline’ apps), but most travel apps are really nothing more than an interface reworking that *need* an internet connection to work. Why all these companies are going bananas developing ‘offline’ free apps for narrow markets is beyond me, but hey, if everyone else is doing it, it *must* be the right thing to do, right?!
Don’t get me wrong, if you are *selling* your apps, then clearly the best way to go is app stores. You almost have an obligation to use the window that is (still) there.
I guess it’ll converge in future to use both in conjunction, supported with common set of APIs in the background. There are few things which only native apps can achieve are critical differentiations. Like push notifications, offline content etc. The content like flight status, available fares etc. may be delivered thru web pages once called form apps. The transition b/w app screens and web screen will be a area which would some creative way of integration.