At eTail in Baltimore today, Abhi Dhar, CTO Walgreens provoked the crowd saying, “Consumers have changed because of mobile. Deal with it.”

[...]Retailer after retailer asked the question, “Should I do mobile web or native apps?” It was deja vu all over again. It’s the same debate mobile bankers had early last year. Abhi Dahl said “BOTH are very important.” I agree.

In mobile banking, we’ve found that banks must offer all three technologies: Mobile web, SMS, and native applications. Many retailers are still resisting hoping to avoid the fragmentation bankers have resigned themselves to.

David Siegel of 1-800-FLOWERS said, “Don’t try to change customer behavior, market to where they are.”

Customers look for brands using their mobile browser. Retailers should have a mobile site. Customers look for brands in their phone’s app store. Brands should have an app.

Companies resisting building a strategy addressing channel fragmentation are just wasting time and ceding market share to their competitors. Many retailers, including 1-800-FLOWERS said that mobile web accounted for over half their mobile sales. The many mobile web proponents I spoke with seemed to consider this evidence that mobile web is the “right” way to do mobile.

My opinion on this stat is that companies only offering mobile web are potentially missing out on 50% of mobile sales. Maybe these users would buy on mobile web if the native app weren’t available. Maybe. Remember, Apple had to create the App Store in response to overwhelming jailbreaking of the iPhone because Apple insisted mobile web was all we needed.

[...]As Jeff Dennes of USAA said, “If you don’t have enough [mobile] budget, get a bigger budget.”

Now is the time for companies to aggressively commit to mobile and emerge the market leader.

Customers are making decisions using their mobile phone. It’s up to retailers to decide to serve their customers.

Mobile Web publishers must deploy their sites across multiple domain standards to attract the largest audience, according to Ground Truth.

The company said that lack of standardization around mobile Web conventions presents hurdles for mobile publishers. Instead of opting for one, publishers should launch their sites across all the various mobile Web domains: “m.,” “wap.,” “.mobile” and “.mobi.”

[...] In the week ending July 4, Ground Truth measured 5.01 billion page views that included requests to 1,555,630 unique domains.

The data shows that 18,934 (1.2 percent) of those measured domains and sub-domains were mobile-centric, such as “m.,” “wap.” and “.mobi,” but 17.3 percent of total page views were served from those domains.

The remaining pages were served from domains without a mobile-specific domain, such as “www.” sites.  Some of these sites are mobile-aware, such as http://www.google.com and http://www.facebook.com.

Of the mobile-centric domains, the prefix “m.” and the “.mobi” suffix appear about equally, but sites using the “m.” prefix serve 21 times more pages than “.mobi” domains, Ground Truth reports.

Following in popularity, by number of sub-domains, are the “mobile.” prefix and legacy “wap.” prefix.

Google recommends that you use a subdomain of your current domain (e.g. m.myname.com) rather than .mobi.

Discover Anywhere Mobile recommends that you use m.myname.com, but also that you redirect all other possible domains (myname.mobi and so on) to your primary domain. This recommendation (and much more) is available on our whitepaper on .mobi Tourism as seen in our Resources section.

It is all well and good owning a mobile phone with GPS, tons of travel apps, but when it costs you £3 – £5 per MB to use the internet abroad, it becomes expensive very quickly. Last week I used my phone in-flight, while jaunting around New York and I have arrived home to a £60 bill for roaming charges.

[read more]

The BBC also wrote about this earlier this year:

If you use your phone in the UK to connect to the internet, for example to check emails or go on Facebook, you don’t usually need to worry about the bill – most home tariffs include unlimited downloads.

But, if you take a smartphone, like an iPhone, on your travels, it can have expensive consequences.

One German man was reported to have been charged £41,000 after downloading a television programme onto his phone.

Julia Feuell, from north London, also got a shock after a visit to New Zealand. Her 17 year-old son racked up a bill of £590.

If you’re creating iPhone apps,  it’s critical that your app doesn’t have an expensive network dependency. If it can’t run in “Airplane Mode”, it doesn’t work for travelers (and you’re missing out on other great benefits).

Here are the key advantages of developing an app:

• Immediacy – except for exceptionally-well developed websites, there is often a several second lag between doing an action on a mobile phone and seeing a result come back over the mobile network. Apps are immediate: when one does something, you see the results instantly. Immediacy leads to a different type of interaction between the user and the device, more playful, more experimental and fundamentally deeper.
• Offline Use – apps don’t depend on a network connection, which means they work in airplanes, in below-ground floors of buildings, in tunnels and (especially) they work on iPod Touches which comprise nearly half the iPhone device market.
• Gizmos – your app can access your device’s camera, compass, GPS, touch screen, motion sensor, and so forth. Mobile sites, not so much.
• Privileged space – people who own devices that can run apps, run apps. The first place they’re going to look for information is their apps which are given a “privileged” place on the screen of the user’s mobile phones. Your mobile app is just another website, that they may or may not get to when they use their browser.

We’ll also briefly mention here that most “mobile optimized” websites rarely are: they don’t work with the user’s location, they don’t design for limited bandwidth and high latency network connections, they’re not tested against a range of devices, and they rarely provide the right amount of information in the right way. In short, the user experience is awful.

Related reading:

• Five Reasons Mobile Apps Rule
• Mobile apps: Cemented into your business’s tech strategy?
• Mobile apps: Does your business need one?

If you are researching a trip to Italy, or want to learn about wines in the region or even just keep track of calories and new recipes while you’re away,”there’s an App for that.” It is important to acknowledge that phrase has now become common vernacular among iphone users just as “Google It” has to the entire population. With a current user base of 1.5 million iphone users and 1.2 Million Ipod Touch users in Canada alone [don't forget the iPod Touch - not all app developers really support this and it's almost half your market -- dpj] (Mobile Fringe), 2010 just may be your “app-ortunity” to launch a mobile marketing strategy.

Why now [to integrate mobile into this year’s marketing budget for Travel, Tourism and Hospitality professionals]? According to Sorge you cannot ignore the facts. “Mobile phones will overtake PCs as the most common Web access devices worldwide by 2013”, states Sorge, “In addition Mobile marketing will grow to $19 billion by 2012 from $1.6 billion in 2008.” Add to that better data plans being offered by cellular providers making web access from you mobile affordable and the solid distribution Apple has created with the App Store following in the itunes successful footsteps. iPhone and iTouch have over 60 million users that consume over 200 million apps per month – and now there is the iPad recently launched which is the happy medium between the two.

[...] Now is the time to jump in when costs are affordable and before the market gets cluttered with too much noise. In saying that, the same principles apply to every other marketing strategy – ensure first that your marketing budget is allocated to where your customers are RIGHT NOW – don’t go building an app for your ski destination if the website can’t be found when your customers are looking to book, or if your website is not even transacting business already.

[...] The cost? You can get an app created for as little as $5000 [even a good one -- dpj] depending on who is developing your app, and what you want to do. Don’t look at mobile in isolation, it should be integrated to your overall marketing strategy and be consistent in messaging with your website, search, email newsletters, blogs and social media initiatives.

Our take: apps aren’t the new search, they’re the new domain name. If you remember way back when to the 1990′s:

• the good domain names get taken early (try and get a short, meaningful domain name now)
• it’s much easier to be a winner if you’re in early, rather than be in late (Yahoo)
• great technology still matters (Google)

If you’d like to find out more about A Couple Of Chicks e-Marketing, there’s a profile on YongeStreet magazine: Hatching an Idea. If you’d like to find out more about moving your Travel, Tourism, CVB/DMO site onto mobile, well, contact us!

It is very important for DMOs and CVBs to realize the implications of this.

Many iPhone app companies are just traditional web developers offering what are called “wrapped apps”. A wrapped app looks – more or less – like an iPhone app, except it’s really just a shell of an application connecting to a web server over the Internet. This means that if your visitor is not connected to the Internet, they can’t use your app! And when they can connect to the Internet, there’s still very little immediacy – things take seconds to happen, rather than the instant touch-response cycle people expect from great apps.

Not only does this affect all iPod Touch users, it is also detrimental to any iPhone-using foreign visitor who will be paying very high data rates to connect to the web over the cell network. If they can’t use your app, or don’t want to use your app because it’s costing them a lot of money, they’re not going to get that great experience they’re looking for in your destination from your app.

How would using a wrapped app affect your DMO? The numbers follow…

From The Apple Blog, iPod touch Now Outselling iPhone:

At the iPad event, Steve Jobs announced 75 million iPhone OS devices had been sold to date, though whether that date was January 27 or January 1 is not known. It won’t matter either way, but let’s assume the latter. Through 2009, Apple sold 42.517 million iPhones. Subtract that number from 75 million iPhone OS devices and we get 32.483 million iPod touches.

If you’re still awake, here’s the bottom line: the rate of sales growth of the iPod touch is very likely greater than the table shows, as in double that of the iPhone. True, the period includes the holiday quarter, the best quarter for iPods, but it just doesn’t matter. The iPod touch, the stealth device for iPhone OS, will be the best-selling model for the platform in 2010, if it isn’t already, and it is.

To reiterate: there are about 32 million iPod Touches out there and a wrapped app won’t reach them when they need it most: in your destination.

From AdMob January 2010 Mobile Metrics Report:

iPod Touch users download an average of 12 apps a month, 37% more apps than iPhone and Android users.

The bottom line from the AdMob report? iPod Touch users love to use apps – but you have to make sure that they can use yours! A wrapped app – an app that depends on being connected to the Internet – does not allow them to do this.

Discover Anywhere Mobile produces native iPhone apps. All the essential data your visitors need is stored right in their iPhone / iPod Touch. This means that whether or not they’re connected to the Internet, they’re going to be able to find the things they’re looking for – and that’s why your DMO/CVB created the app in the first place, right?

All images taken from original blog posts.

These two issues are related.

Shopping List.

iPhone applications should not be an exercise in box ticking — iPhone app, check, next…. A useful iPhone application comes with a set of expectations from the user about the way it feels, the way looks, the way it reacts to way the user interacts with it. A failure to respect this leads to the fate of about ⅔rds of iPhone applications: they never get opened more than once or twice. For your destination this is a disaster – you’re supplying the best information possible on behalf of your members and your visitors are not even bothering to look at what you have to say.

There’s a reason you don’t photocopy your destination brochures, even though it has exactly the same information that your expensive glossy stock paper version has – it just doesn’t feel right.

Or to put it another way, you want an iPhone application that people look forward to using again and again.

Generic App. Wow?

Now, there’s two non-Discover Anywhere Mobile solutions for getting a custom iPhone application built: cheap or professional. Cheap is going to give you the photocopied brochure: it has the correct information but there’s no appeal. If data is being pulled from a website live (the easy approach, often taken for quick and dirty iPhone applications to solve the ‘keep-the-app-up-to-date problem’) your visitor is going to experience a delay getting to what they want to see. As Google has extensively studied in the past and has nearly perfected solving, even the tiniest delays ruin the user experience. You now have shelfware. Professional will give you the solution you’re looking for, given time and money. There’s some great looking iPhone apps out there in the tourism / leisure categories. Some of them cost 6 figures to develop, almost all the others a reasonably sized fraction of that. Why? Because great work – great graphics, a feel for the user’s needs, well-tested applications – requires talented staff at all levels of the development agency.

This is what you want!

Discover Anywhere Mobile has the solution for your destination. We’ve done all the hard work for you: we offer great looking interfaces that visitors will want to come back to again and again; we customize the interface for your destination’s branding and message, so visitors don’t feel like their getting a generic product; and – behind the scenes – we keep your visitor’s iPhone updated with your latest information to give them the immediacy they’re looking for while actually using the app.

And we’ve figured out how to do all of this at a price point that, quite frankly, is well below what anyone should be quoting for custom development, even for the “cheap route”.

And this brings us to the issue of ongoing maintenance. Nothing, not websites, not software, not mobile applications are “fire and forget”. Issues of bugs aside (which will always requiring fixing) no application remains fresh. Great websites are redeveloped every few years as our understanding of how people interact with the web evolves – every website is effectively amortized over the period you have it for.

Maintenance, for Discover Anywhere Mobile apps, covers several things. It covers the ongoing costs of getting your data, reorganizing your data for best presentation on the mobile web, and pushing out that data to all of your visitors for that great destination experience through an iPhone app. It covers access to all of our other features and apps for other devices that Discover Anywhere Mobile has and will make – yes, these will cost extra money but only a marginal incremental cost. The iPhone didn’t exist 3 years ago; the capabilities to do Augmented Reality weren’t there 6 months ago. Apps _always_ needed to be updated in the mobile world or, once again, you’re shipping shelfware.

In short, Discover Anywhere Mobile wants to be your partner in making sure your apps deliver the best possible destination experience for all of your visitors. Our solution provides the best of both worlds – low cost, with professional polish.

You may be right if you think the apps for smartphones like the iPhone or Android are passing phases. But that doesn’t mean you can afford to sit this one out.

PhoCusWright’s senior corporate and technology analyst, Norm Rose, said the market is only growing for consumers who use smartphones, and they want to use them to make travel decisions. Rose presented his conclusions in a Webinar this week called “The iPhone and the Future of Mobile Travel Applications.” He also is co-author of PhoCusWright’s Mobile: The Next Platform for Travel.

Rose predicted that the craze over apps may last only four or five years, but they will be crucial. Hotels and other hospitality-related industries need to plan a smart mobile strategy that will bridge the near- and long-term. Part of that is cementing your mobile brand in the minds of consumers so they stay loyal to your brand in the future.

…

PhoCusWright found a direct correlation between smartphone owners and frequent travelers. Its most recent consumer technology survey, released in May, showed that people who take more than four leisure trips annually are more likely to have a smartphone. Similarly, people who use social networking sites such as Facebook and Twitter also tend to be on the cutting edge of mobile technology and take an average of 4.7 trips a year.

Meeting these travelers on their own technology terms can be the key to capturing their business.

All emphasis added. Note that we don’t think apps are a passing phase – we’ll just get to the point where we don’t think about them anymore. Originally from HotelMarketing.com.

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.

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.