Best Practices: Travel Websites and Mobile

by David Janes on August 29, 2009

Introduction

This guest post is about how to create a website specifically created and optimized for people using the Internet from mobile phones.

To make sure this is perfectly clear, we’ll be talking about two different sites: your “normal” website (e.g. www.example.com) and your “mobi” site (e.g. m.example.com). Your website is what one would normally see on the Internet, your mobi site is something that you’re explicitly using for mobile devices

Why am I doing a mobi site?

Because there’s a lot of travelers using smartphones, there’s going to be a lot more in the future, and they’re visiting to spend money:

  • Nearly 70 percent of frequent business travelers have a smartphone somewhere on their person (link)
  • 1 in 7 computer owners currently own a smartphone (link)
  • over 40% percent of consumers will make their next mobile phone a smartphone (link)
  • more than three quarters of smartphone owners said that they will either be planning or taking a trip in the next 6 months (link)
  • smartphone owners demographically skew wealthy (link)
  • as of January 2009, there are about 18m iPhones and about 13.6 iPod Touches in use (link)
  • iPhone and BlackBerry sales are expected to increase 25% this year (link)

What is the emphasis of your mobi site?

In-destination, the emphasis of a mobile site should not be marketing: the user is sold, they’re there. Instead, it should be to rapidly allow users to navigate to information they’re interested in consuming in the most convenient possible way.

This means:

  • allow users to quickly see navigation items in the most obvious way possible
  • present location information based on proximity (if GPS is available)
  • present event information based on date.

IMHO concepts such as “the entertainment district” may have to become de-emphasized as this is an organizational unit more suitable to the printed page than mobile devices.

Page size and features

Page load speed is as critical as possible. This is true in the web browser world too, but in mobile:

  • minimize JavaScript, as there’s probably not a lot of value in clever browser tricks or the CPU cycles to do it.
  • minimize page size, as that corresponds to time-to-download and also cost to the user. In any case, do not exceed 25K for a page (why)
  • put CSS and JS in separate files to optimize caching
  • minimize images. 0 is a good number; 1 is OK; 2 is too many. It goes without saying that any images should be small both in dimensions and bytes.

Since the traveler is likely not to be using their normal carrier, they’ll appreciate the effort.

Which devices?

Test your mobi site on a BlackBerry and on an iPhone (here’s why). If it looks decent on those, it’s probably at least tolerable on lesser devices.

The relationship between your Mobi site and your website.

When a mobile browser reaches your normal website, you have several options:

  • use CSS to make your normal website look good a mobile browser
  • automatically redirect users to your mobile site
  • prominently display a link to your mobile site

You should probably do the first option anyway, but this is not sufficient for creating a compelling mobile experience, as you really want travelers to see your mobile optimized site. Either of the other two options are good, with my preference being the “display a link” option, as users may still want to reach content that is only available on your normal website.

Detection of whether the user is reaching your site via mobile browser can be done “server side” (in the website code) or “client side” (using Javascript). My preference is the first.

If a user reaches your mobile site from a non-mobile web browser (i.e. from their computer) there’s no need to do anything special. You probably should have a link from your normal website to your mobi site somewhere anyway.

Domain Names

You have two good options for a domain name for your mobi website:

  • m.example.com
  • example.mobi

My preference is the first. Note that you should always register your .mobi name so that someone else doesn’t. You should redirect the user’s browser from the unused one to the correct one.

iPhone and BlackBerry Applications

Places with large event calendars, many properties or listings, or many visitors should consider developing custom iPhone and BlackBerry applications. This will:

  • provide a superior experience to what is achievable in a mobile web browser
  • reduce dependence on having an Internet connection in order to be able to achieve tasks
  • provide “wow” factor
  • enhance loyalty, the chances of repeat visits, and create word of mouth

I am not a neutral party in this recommendation.  My company, Discover Anywhere Mobile creates iPhone, BlackBerry and mobi websites for DMOs, CVBs, festivals, events, conferences, etc.. Our website explains our mobile web services in detail.

Conclusions

  • every travel website should strongly considering having a mobi website companion
  • that mobi website should be developed especially for the needs and limitations of mobile devices
  • the emphasis of mobi website should be user experience in-destination, not marketing
  • larger organizations should consider apps

Please feel free to leave comments below, or follow me on Twitter at @dpjanes.

This post originally appeared on the Discover Anywhere Mobile blog.

  • David, this is a great point. A lot of websites haven't quite figured out that an increasing amount of traffic is now coming from mobile and the content needs to be accessible. I think one of the few industries that's gotten it "right" so fair are the airline sites.

    One quick update on the "m." and ".mobi" rule you raised - a mobile-optimized site doesn't need to have these modifiers in the URL. Our company has created a few that simply redirect the user from the main URL with no other action necessary. Check out our trends and insights blog on mobile for more info: www.mobilebehavior.com/next-gr...
  • Thanks Todd:
    I like that you are also exploring some of the more cutting edge mapping and mobile applications. I've just started a GreeenSudbury map at OpenGreenMap.org and realize there is so much to learn about Google Earth, GPS etc. I post a daily news roundup from Northern Ontario at http://GreenSudbury.ca and often check your great stories and informative posts.
    Keep up the good work1
  • I think with WAP it doesn't really matter, unless you're getting into graphics. Text will resize to the appropriate sign anyway.

    If you use an automatic redirect to the mobile, it won't matter if you link back to the main site: when they click on the link, they'll just end up back on the mobile site!
  • I'm thinking we're going to opt for the server side redirect to our new WAP pages for handhelds by editing the .htaccess file and including the code found on this helpful site.
    http://dev-tips.com/featured/r...

    That way, the iphone, blackberry and palm apps will automatically be shown the new url.

    Of course I'll always include a link back to the main site.
    Any advice on the screen dimensions we should be designing for if using a universal redirect such as this?
  • Yes, this is an excellent point. Note that Google's first big breakthrough (in the web world) was that the search page should minimize distractions - a field & a couple of buttons. This model has to be everywhere in mobile.

    On the iPhone, any place you _display_ a telephone number should be click to automatically dial it! I believe this will work on the BlackBerry too, but I'm not sure if non-sophisticated browsers on Nokias and what-have-you will recognize the "tel:" URL link to automatically dial. Ah well.
  • Thanks David.
    I had a thought the other day that as screen size decreases, the time commitment of the user decreases as well. Mobile sites need to get to the point much more quickly than websites in general - NO DISTRACTIONS. Handheld users are even more likely to be multi-tasking and want the information NOW. It also needs to be place relevant. It has to answer my needs as I stand HERE in your community or en route.
    So DMO's and travel regions need to be smart about their mobile Web presence and design it with a deep understanding of the needs of travelers in their region.
    Lastly - make sure your phone number is always prominent. Since this mobile user is holding a phone, you might intuit, that they would appreciate being able to call someone.
    Thanks again David.
blog comments powered by Disqus

Previous post:

Next post: