Introduction

This is the second post inspired by a comment I left on Todd Lucier’s website. This 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.

The points in this post are fairly high level and should be readable by any professional using the web. Your IT staff and web designers should know how to fill in the technical details.

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, see the next section.

Discover Anywhere Mobile

My company, Discover Anywhere Mobile creates iPhone, BlackBerry and mobi websites for DMOs, CVBs, festivals, events, conferences, etc.. Our website explains the ins and outs in detail but briefly:

• we’re committed to creating great traveler-centric applications that will be second to none
• we do this very cost effectively for destinations; with various features we offer this can almost be cost neutral for DMOs
• beyond the initial setup, we can create and maintain the applications with no change to workflow at destinations (&c) and no additional management work
• we ensure that even downloaded apps are kept up to date with your data and your message

Conclusions

• every travel website should strongly considering having a mobi website companion
• that mobi website should be developer 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.