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.

Introduction

This post was inspired by a comment I left on Todd Lucier’s website regarding best-practices for mobile websites. The travel / tourism industry is not particularly advanced when it comes to use of web technologies (obviously excepting that some sites are much better than others). Many booking sites for hotels, airlines and so forth have very backwards – almost 1990’s style – interfaces; many destination websites allow for minimal user interaction with the site beyond clicking on links; those that do more often place high barriers to usage – account creation & verification, etc..

This post is about how travel / tourism sites – especially hotels, DMOs, CVBs, conventions, conferences, event holders – can easily improve at least one aspect of their site. It’s about how to allow sharing and distribution of information with others, particularly travelers!

This post should be readable by any professional who has content on the web. The technical bits are “high level” and my goal is that you should be able to point your IT/Web team to these recommendations and say “do this”.

The Webs

The phrase “Web 2.0″ has been popular for the last few years to describe certain trends in the web industry: incorporating user-generated content, social media, APIs,  the “read/write web”, using rounded corners and images with reflections, and so forth. Though a blurry concept, it’s a reasonable stake in the ground to differentiate what came before in the early days of the Internet: the web as a method for delivering relatively static or source-driven content on pages. Of course, once there was a Web 2.0 immediately people started to define what Web 3.0 should be: the semantic web, linked-data, and so forth. These terms are almost (but not quite) meaningless to the end user, but what they’re getting at is that Web 3.0 should also somehow incorporate information in well defined, usable ways so that data available in one place can be cleverly reused, repurposed or redistributed in surprising ways in other places.

To summarize to the point of absurdity:

• Web 1.0 is about pages
• Web 2.0 is about people
• Web 3.0 is about information

All these concepts, of course, have been in the web since the beginning. “Web #.0″ is a convenient shorthand about how much weight we’re putting on various concepts.

The Why – TripIt as an example

TripIt is a popular travel itinerary management website (and iPhone application). The “clever bit” about TripIt is that you can mail it your travel confirmations from your airline, hotel and so forth and it figures out what the message really means and builds a travel plan for you. However, there are several rather basic shortcomings:

• if you want to consume the information outside the context of TripIt, you’ll have to rebuild all the infrastructure yourself
• if TripIt doesn’t understand a message, data will have to be entered manually. Since you’re not Air Canada or Starwood Hotels, TripIt doesn’t understand your message (or your website)
• if message formats change – for any reason, including stylistic ones – TripIt will no longer understand the data until they catch up and write a new parser to understand the changes

There is an alternative that overcomes these issues. What if everyone agreed on common ways of expressing information so that custom parsers, etc. don’t have to be developed? Then anyone could potentially read and use the data in travel messages and on websites, and anyone (i.e. you) could create data that can be reused by those “anyones”.

Sounds hard or perhaps even obscure? It isn’t – some of technologies for doing this have been around as long as the Web, and you’re almost certainly using tools today that can take advantage of information shared in the proper formats.

iCalendar

iCalendar (also sometimes called vCalendar) is the standard for transferring information between calendars. Do you use Outlook, Outlook Express, Google Calendar, Yahoo Calendar, or iCal? Then any time you send a calendar entry to another person you’re also using iCalendar; if you sync two calendars, you’re using iCalendar. If you download an event on Eventful, Upcoming or Meetup – you’re using iCalendar.

Every event on your events calendar – individually, collectively and grouped by topic – should be available for download as iCalendar on your site. Your website is not the center of the traveler’s experience. By making the event transferable to their calendar – and other applications which can consume iCalendar – you’ve giving the traveler a little piece of your website that they can take away use the way that they prefer.

It’s also worth noting that if you’re using some sort of event management software or content management system, this should be near-trivial for your web team to implement correctly.

vCard

vCard is the standard for transferring information about people and organizational contacts. If you use Outlook, Outlook Express, Google Mail, Yahoo Mail, (Macintosh) Mail, Lotus Notes and so forth, you’ve probably used vCard – especially if you’ve ever mailed a contact to another person.

You should create and place on your website vCards for your organization / destination, and for every person that you’re listing on your site. Why supply only an e-mail address when you can give a complete downloadable contact file with photos, maps, phone numbers, website addresses, etc.?

Like vCalendar, vCard is trivial to implement correctly.

Microformats

(This is the only paragraph that’s really explicitly Web 3.0, sorry).

Microformats provide another way for delivering information about your destination, hotel, event, etc. to applications that may want to consume it. The advantage of microformats over vCalendar and vCard is that the data is built directly into your web page , doesn’t have to be independently downloaded and that there are more types of data encodable using microformats. Furthermore and of special interest, search engines are starting to look for microformatted information in webpages and are displaying results in-line with search queries (Yahoo, Microsoft, Google).

This is more technically difficult to accomplish than vCard/iCalendar, but it certainly worth considering for larger websites – and probably essential for very large websites with many property listings.

Conclusions

I hope you’ve found this an interesting introduction to how you can use web technologies and formats today to share your information “Web 3.0″-style. There is nothing particularly esoteric about these recommendations – they are all well known and often used in the tech industry. Your management team should give direction to the web design and IT staff that these are the types of features you want to see in the next iteration of your website.

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

Mark Evans of ME Consulting (and Mesh Conference fame) writes about social media and the travel sector:

[...] One thing that struck me during their presentations is how travel is such a personal experience, and how the best travel experiences don’t come from guidebooks but, instead, the people you meet along the way that suggest places you’d never otherwise have discovered.

This makes recommendation services such as Twitter a natural way for people to get travel advice from an extensive network of people who have real insight into what to see, do and hear, and a willingness to share it.

The question is how online travel services can effectively integrate Twitter into their offerings as opposed to having it exist as a standalone. Traveller, for example, has a way to ask questions that can be published on Twitter but there’s current no way to integrate the replies from Twitter users into Travellr’s database so Traveller users can benefit from what people are saying on Twitter.

My sense is the tighter integration of Twitter into online services will be a powerful and effective way to enhance the information available while extending the overall community. In some respects, Facebook is working on it with Facebook Connect but the reality is we’re just scratching the surface.

To comment on a personal note, when I was on vacation earlier this year in Florida I was happy to discover that some friends from Toronto were also down there via Facebook.

To reiterate and expand on one of Evans’ points, I believe the integration question is broader and potentially very technological difficult. It’s fine to get social recommendations, but how do we “keep” that recommendation in a useful form. That I have a Twitter recommendation to go to (say) the Distillery District while in Toronto needs to easily be integrated into whatever tool – e.g. Travellr – I’m using online, but then also be seamlessly transferable to whatever other travel services I’m using: TripIt, Google City Tours, and of course, whatever it is I’m using on my handheld. And of course, in a few short years the handheld is where all the action is going to be once in-destination.

Given the difficultly we see today in pleasantly presenting options to add calendar items, add business cards, subscribe to syndication feeds, and so forth – I suspect a more general solution will need to be found.

Google Labs has introduced a new technology called Google City Tours which has gathered quite a bit of attention over the last few days, most likely because it’s Google doing the announcement rather than anything novel or inherently interesting in the product. Internet produce profiling site TechCrunch’s description seems sufficient:

Getting started is incredibly easy — just type in where you’re visiting (say, San Francisco or London), and Google will present a suggested itinerary spanning a three day trip, with around a dozen attractions per day depending on the city. From there you can change the number of days you’ll be staying (Google will show more attractions the longer you stay), and you can also manually adjust the list of places you’d like to visit. You can add a new attraction by entering its name in a text field, and Google will try to find it in its database. All attractions include a star rating, along with its hours operation and location.

My personal opinion is that this is a typical Google Labs product – without significant improvement, we will likely see this product fade from site fairly quickly. The core of the application is simply Day 1, I go to these locations in this order, Day 2 I go to (etc.). The interface is plain but still relatively non-intuitive, the routes do not take advantage of Google’s map route features, and the tours are relatively random. Bizarrely, there seems to be no way to actually link to a tour so that it can be mailed or shared with somewhere else, or even used on a different computer — every page is more or less http://citytours.googlelabs.com/.

There are other sites that provide not unsimilar ideas. Planet Eye has travel packs for exploration ideas. The awesome TripIt offers a personalized itinerary based on the data you feed it via e-mails or manual entry, though it’s missing the “what should I be doing” (as opposed “what am I doing”) component.

Todd Lucier says “Google is no threat to DMO’s and Visitor and Convention Bureaus” but notes that is shoes what DMO’s should be doing. I agree and in fact at some level this is what Discover Anywhere Mobile is trying to accomplish, though obviously we’re targeting more the mobile space.

What’s really going to be needed in the long run is some form of data portability between different sources of tourism information. Every person should be able to select a restaurant from TripAdvisor, an itinerary from TripIt, perhaps even information directly from a museum’s web page and then be able display it in a tool like Google City Tours or Bing Maps and also seamlessly view on their mobile phone. It’ll be exciting to see how this goes over the next few years.