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.

This post originally appeared on Tnooz: Five big problems with mobile travel applications (and a bonus one for Android users)

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.