This post was also published on CNET and VentureBeat.
Taking your site mobile is a technology minefield. Here's how we're doing it at CBS Interactive.
The mobile technology landscape is incredibly confusing. There are numerous choices, ranging from new HTML5 technologies, native app development methods, and all sorts of content management systems.
At CBS Interactive, we have numerous mobile solutions, including native apps for CBS.com, CNET, and "60 Minutes," along with mobile-optimized Web sites for GameFaqs and global properties like ZDnet.
At first blush, it seems problematic that various properties have picked completely different architectures for mobile delivery. A technologist's initial inclination is to have everyone run a consistent architecture across all of our properties. Yet it actually makes sense to run a variety of architectures to support mobile delivery.
The biggest issue to address is the ongoing tension between HTML5 and native. Most of the debate between the two is focused on different technical features that very quickly delve into minutia. However, the actual decision between the two should be made based on the type of traffic a site has.
Where's the traffic coming from?
If the majority of a site's traffic is side door traffic from Google, Facebook, and Twitter, the site should embrace mobile web and HTML5. Since most of the site's users are arriving via links, the content must quickly load in the
mobile browser. Such sites include music lyrics sites such as our site MetroLyrics and other types of information look up sites.
If a majority of a site's traffic is direct but intermittent traffic--meaning users come directly to the site, but only once in a while--the site should implement HTML5 mobile Web. These types of sites are "tourist sites" that are not visited regularly by people and therefore users are very unlikely to download an app. Such sites include corporate websites such as my company's CBSi.com homepage.
If the majority of a site's traffic is direct traffic where people are regularly going straight to the site's home page from a bookmark or typing in the URL, the site should use native apps. Such sites include CBS.com, CNET Reviews, and other types of highly branded destination sites.
Sites with direct traffic that is intermittent--meaning people drop by every now and then--should still use HTML5 rather than native. For sites with a lot of direct traffic, native apps also provide useful additional features such as push notifications and offline storage, which are not relevant to sites with intermittent or side door traffic.
Sites that have an even mix of direct and side door traffic should also implement both native apps and an HTML 5 mobile view. A word of caution, however: there is always an inclination to heavily promote your native app to everyone going to your mobile Web site by forcing users to click through a native app promotion. This is a way to piss people off. Most of those visitors are clicking on a link in Google or Facebook and expect to see the content. They don't want to download your app.
What can you spend?
Once you determine whether to build an HTML5 mobile Web site or a native app, the next big question is how much you are willing to spend. Really, there are only two choices: complete and cheap or custom and expensive.
Sites should generally start with a turnkey and cheap solution. For turnkey mobile Web HTML5, vendors like Pressly and Mobify will take your content and make it sport a sexy, Flipboard-stye tablet interface. Wordpress includes mobile plugins that work great on
Android. Be sure to add a "view full site" option so that your users can opt out of the mobile experience and access functionality that the turnkey HTML5 solutions do not yet support.
To deliver turnkey native apps, services like MobileRoadie will consume your content, social feeds, and more and let you style good iPhone and Android native apps, with iPad soon to come. The apps are gorgeous and responsive and provide extensive options.
For the sites that need to support both mobile web and native apps, it is likely that the turnkey vendors will soon begin to support both distribution channels, and one vendor will be able to deliver best-of-breed solutions for both mobile HTML5 and native apps. For now, however, I suggest using a different vendor for each.
Once you have a baseline mobile presence, you can consider adding a custom experience that will support numerous features and user interface enhancements. Unfortunately, custom means expensive, both for HTML5 and native apps.
There are numerous systems integrators such as that deliver elegant, iPhone, iPad and Android native apps. Be aware that these integrators are going to need to be able to integrate with your registration, user profile, and content systems and that will likely require engineering and IT work. Some integrators such as FreeRange360 have an underlying platform that makes this type of customization relatively straightforward.
That said, it is relatively straightforward to efficiently deliver an excellent mobile Web experience. Libraries like jQuery mobile and Sencha mobile provide excellent HTML5 iPhone-style user interface controls, and it is easy enough in modern web frameworks such as PHP and Ruby to detect what type of device is requesting content and delivering a customized page for particular screen sizes, known as the "if viewport then" technique. It is tedious and cumbersome work, but can be done, and provides an excellent level of control and flexibility.
For properties that contain primarily text and images, you could consider a hybrid HTML5-native approach, where a mobile-optimized HTML5 site is wrapped with a native wrapper like PhoneGap. While this sounds like an ideal solution, consider that this approach is quite nascent, and that it takes quite a bit of work to make HTML5 work and look like a native app.
In summary, when discussing your mobile strategy, use the type of traffic your site has to determine whether to use HTML5 mobile Web or native apps, and then use your level of budget to decide whether to go turnkey or custom. And have some fun with your apps and please let me now what's worked for you.