Five big problems with mobile travel applications (and a bonus one for Android users)

The World Wide Wait was a common term used in the late 1990s to vent the frustration of being unable to access the huge potential of the internet.

The “Wait” was due to slow dial-up lines, clogged service provider servers, and let-it-all-out heavy graphic/flash websites.

In 2011, the same label could be refreshed for mobile apps, in particular travel mobile apps. In part because of similar network speed reasons, but also because of wrong decisions in app design.

Here’s a summary of the most common problems with mobile travel apps today:

1. Assuming always-on data connection.

It’s not always on. Full stop.

Because it’s mobile, users constantly lose coverage: metro/tube stations, inner buildings, car parkings, cathedrals (yes), rural areas.

And obviously, when it comes to traveling abroad, roaming forces data networks off for most users. Also let’s not forget in-flight situations, where data is off and you’d still need to access data in your apps.

The fact is that as soon as coverage is lost, some apps stop working.

I’m not talking about features which obviously need remote access, like checking live availability, or bookings: even simple static data or previously downloaded items disappear.

Case in point with the Eurostar or the AirFrance apps. No connection? The apps are virtually dead. Even the phone number list, which might be the only way to get in touch with the airline in case of problems abroad, is not accessible.

The return mobile boarding pass so efficiently downloaded before departure? Gone, right when you need it to board the train back home.

Good cases: American Airlines and Delta apps at least provide a simple static tap-to-call contact screen, to get in touch even if there’s no connection.

Don’t assume always-on, build standalone apps with good caching.

2. Assuming high speed network access.

Despite what you can read on theoretical data speeds, truth is mobile bandwidth is far from fast and predictable.

Tons of factors can influence the actual speed, such as number of people in the area, architectural structures of nearby buildings, weather conditions, and even the position of the hand on the device.

It’s a good thing that our phones can transmit faster, but if everyone wants to transmit at the same time in a busy area, no one gets enough bandwidth and we must all keep retrying until everyone else is silent.

Take for example small femtocells used in underground metro stations. These can typically accept two concurrent connections. That does not mean that only 2 people can use the network, because statistically each device will just need access for a few tens of seconds.

However, with 100 devices in the approaching train all trying to connect at the same time, and 100 other devices on the platform, things start getting very busy.

Whether the app pulls data from the network, or you have a mobile optimised web site, keep data transfer very compact. It’s really the size that matters.

Don’t use a big CSS with loads of effects and scripts that might be used only once. Don’t build big XML APIs with tons of data “just in case” (forget SOAP, go REST). Cache everything you can to avoid reloading the same data multiple times.

3. UX design too small and packed.

Some designers seem to forget that a finger is a finger. Every action button or dropdown list should be not only large enough that it can be hit with reasonable success, but also spaced away from other active items to avoid tapping the wrong one.

Selecting items in predictive search lists can be difficult if the results are too small and squeezed one next to the other.

There seem to be some design legacy from older WAP/text based sites, where we used to scroll from (small) item to (small) item just with the phone up/down buttons, or even with the dial pad, but we’re now in the smartphone era.

Forms can reveal huge problems.

  • Each field should be easily tappable without touching nearby fields;
  • Remember the virtual keyboard will open up filling half of the screen, make sure the rest of the form and in particular the submit buttons still remain accessible!
  • Moving the device from portrait to landscape mode can mess up the layout big time, and what was easy to tap in a mode might become weird in the other mode: test in both scenarios.
  • Calendars… make them full screen, simple, with large arrows to move from month to month. Make the number big. As with usual localizations, some countries start the week on Sundays and others on Mondays. If you can’t make it dynamic, at least make sure the Saturday and Sunday columns have a very different background color to limit risk of confusion.

Test your app using leather gloves to make sure it works for everyone.

4. Poor data synchronization with the cloud.

Some apps seem to require a login every time they need to be used, and expect to have data connection for login verification every time.

For example the AA app loses the session if there is a loss of data connection, hence all stored trips and boarding passes disappear until the next succesful login – which requires data connection.

This approach finds some rationale with data privacy, but it does not meet expectations. If I download an item to my mobile to have it accessible on the road, I need to have it accessible in all situations.

Take for example, TripIt and other itinerary management apps: they are born mobile, and are handling this well.

You install and register your account once, and then forget it. Every plan you send by email will appear automatically in your device.

Every trip you add or remove manually on the web is then perfectly synchronized with the app. You can simply trust that your itinerary app will always have all the useful data you need on your trip.

5. Requesting too many permissions.

We are getting used to being able to happily install any app, without checking who is the developer and the actual permissions we grant to access our phone data and functions.

But sometimes the requests are very surprising.

Why does TripCase need the address to my whole address book? Why does Expedia need access to my phone (including the list of numbers I call, apparently)? Orbitz doesn’t, for example.

I believe in the future users will get wary of malicious apps and will learn to pay more attention to permissions.

In social, an empirical rule for Facebook apps is that every additional permission requested decreases the app installation rate by 2-3%. We will probably get into something similar with mobile.

+1 (Android specific bonus) App cannot be moved to SD card.

This is a legacy problem for Android, probably the only serious architectural problem, with long term consequences.

Internal phone memory for many mid-range smartphones is only 128 or 256 MB. It’s small, and it fills up quickly. Many native apps like Google Maps, Contacts database or Flash already eat up a good chunk of the internal memory.

Since Froyo 2.2, apps can be moved to an external SD card of potentially any size, thus freeing up the internal storage. However, app developers must include the ability for their apps to be moved to the SD card.

Many don’t.

If a travel app cannot be moved to the SD card, it will have to fight for space in the small internal memory and it will only be kept if it’s really, really useful.

Expedia Hotels by Mobiata is 3.8 MB and cannot be moved to the SD card. Orbitz is 2.5 MB and cannot be moved to the SD card. Sooner or later, one will have to go.

Please, please, please make sure your Android apps can be moved to the SD card.

Share on FacebookTweet about this on TwitterShare on LinkedInEmail to someone
Daniele Beccari

About the Writer :: Daniele Beccari

Daniele Beccari is a contributor to tnooz, and head of travel products at Criteo.

As travel technology strategist, he has helped startups and blue-chip corporations define and launch innovative solutions in leisure, corporate, online and mobile sectors. He also served as Vice President, Europe and B2B, at Isango! (now part of TUI), and previously as head of corporate products for the e-travel division of Amadeus.

He started his career at HP, working on what is known today as the Internet of things. An MBA graduate from INSEAD, Daniele can be found somewhere between Paris, London, Turin, San Francisco or Tokyo.

Daniele's views are his alone and not the views of his clients or employers.



Your email address will not be published. Required fields are marked *

  1. Utsav Srinet

    About travel times widget issue, this is very genuine problem for anyone who is using travel apps very frequently.My home & work address are saved in my google maps app. the error only occurred after doing the software update. However i was able to solve that problem. Thanks for sharing such a awesome post, you approximately all problems that everyone could face with these travel applications.

    Great! Cheers !!

  2. Ricky Cadden

    I manage Digital Marketing at TripCase, and wanted to provide a bit of insight here, from the app perspective:

    This is a great list, and as was pointed out in the comments, could also be applied to mobile apps in general (though that wouldn’t fit the target audience here, would it?)

    TripCase does indeed handle offline mode in a somewhat unique way. To manage data size and cache and all that, we store your current trip – this way, you can access the pertinent stuff without a connection. We also indicate this on the app itself with a red bar. You can get more details here:

    Additionally, with regards to permissions, we keep an updated explanation here: to let you know why we’re asking for things, and what *exactly* we do with that access. In most cases, we don’t really store anything, but the way these permissions are laid out by Apple/Google, this is how they work. Transparency is key, though.

    Daniele – hope you don’t mind the links – just wanted to provide some additional details.

  3. Patrick

    The Expedia app originally required Contact?address book permission and I pointed it out to them and they brought out a revision and now it does not. Orbitz never did. Airbnb will not remove it despite I asking them. I will not install an app that clearly does not require access to my Contacts to operate. That is why I deleted Facebook, they access your Contact, figure out who they are, then send them friend prompts, totally violating privacy. If the app does not need such information to operate it should not be asking access to Contacts/Address Book.

  4. Lakhdar Hamid

    Merci Daniele pour ton post
    À. Cette date les obstacles reste pratiquement les même usabilite et ergonomie prennent de plus en plus importance pour les apps différence screen rotation etc…
    La phase paper dans les dev restera très importante avant de coder le fine tuning avant publication restera déterminent sinon s’attendre à des reviews. Négatifs qui brisent les efforts des concepteur.

  5. The Radar: NYC’s Best Places for Tea, Airline Changes, Travel App Problems | ...microcerpt

    […] Travel apps can seem like the perfect companions for your next vacation, but common problems such as needing a data connection or high-speed network access can be problematic abroad. [TNOOZ] […]

  6. The Radar: NYC’s Best Places for Tea, Airline Changes, Travel App Problems – Intelligent Travel

    […] Travel apps can seem like the perfect companions for your next vacation, but common problems such as needing a data-connection or high-speed network access can be problematic abroad. [TNOOZ] […]

  7. Antonio Ca' Zorzi

    Good points, thanks. We have reviewed our first design, a me-too similar to other tourism guides, and opted for less features, less buttons, larger images. Our objective is to highlight the content we will be offering and to hide the technology as much as possible. Of course we are not relying on Internet access, because our content is embarked in the app.

  8. Daniel

    About the SD card issue – one problem with Android is that if your app has widgets, live wallpapers, or any number of other features then you cannot allow your app to be moved to the SD card. This is a pain point for many developers with regards to the “move to SD card” feature.

    • Daniele Beccari

      Hey it looks like all the Dan* of travel are gathering here.

      Thanks for pointing this out. It is definetely a pain point. More recent Android phones have 1-2GB which is definetely better, but as far as users are not aware of the move to SD issue, even 1G can fill up quickly.

  9. Ian

    Good points Daniele. We learned many of the lessons above in 2000 when building the first iteration of our app for Palm & Pocket PC PDAs. The devices’ resources constraints really forced us to code efficiently and think carefully about the user experience. For example, 11 years ago, very few of the PDAs even had CDPD wireless connectivity, so we built HotSync/ActiveSync + cache capabilities to download/store weather, currency rates, flight schedules, etc. In fact, we still cache all data on the device that isn’t real-time info.

    We learned lots of other tricks serving 9M users across 10 or so mobile platforms, but that’s for another discussion. 🙂

  10. Dan Gellert

    While I agree that these can be problems with mobile travel apps, labeling them as “Five big problems with mobile travel applications” is a bit of linkbait. The issues you bring up above are problems with poorly designed apps, not mobile apps in general (except for the last point which is more of a problem with lower end Android models than apps themselves – 3.8MBs is not very big considering the code and graphics that go into an app, especially if you want the cacheing or pre-seeding of data that you mention above in points #1 and #2). Companies that have developed their apps thinking about the true needs of the traveler and the mobile experience (versus just porting over their web experience to a mobile UI) are an amazing solution to travelers and provide an invaluable amount of support and information. The cream will rise to the top in any market and mobile is no different.

    • Kevin May

      Kevin May

      @dan – I take exception to your accusation of link baiting.

      Daniele identified five significant problems with mobile travel apps, plus one exclusive to Android devices.

      In my world of journalism, where we write headlines to outline what the story is about, this one is completely acceptable.

      Anyway, surely the same could be said for a series of posts on a well-known mobile app provider’s blog titled “Know Before You Go”, perhaps?

      Just sayin’ 😉

      • Dan Gellert

        @kevin – Clearly using “linkbaiting” was a poor use of words. I can see how that could be seen as offensive – wasn’t meant to be – apologies to the @daniele for that. I do think the article was a good one in that in brought up issues around how some of the above points aren’t problems with mobile in general but rather poorly designed apps.

    • Daniele Beccari

      @Dan –

      as you say, the issues above are problems with poorly designed apps.

      That’s exactly the point.

      The majority of travel apps are poorly designed.

      There are a few good exceptions – I like to mention TripIt, Wipolo and the latest Tripcase, as they are “born mobile” and get it. Haven’t had the privilege to use GateGuru yet, but I’m installing it as we speak.


  11. CityBot

    Couldn’t agree more, especially about the reliance on constant network connection. I travel a lot internationally, and It seems that travel industry is jumping on the “always on” bandwagon a bit too early and tripping over its own feet. I believe we will be always on and always connected eventually, but we are just not there yet.


Newsletter Subscription

Please subscribe now to Tnooz’s FREE daily newsletter.

This lively package of news and information from Tnooz’s web site provides a convenient digest of what’s happening in technology that drives the global travel, tourism and hospitality market.

  • Cancel