作者：Peter Yared

手机技术领域相当令人费解。目前有许许多多的选项，包括新的HTML5技术、原生应用开发方法和各种内容管理系统。

flickr_iphone_apps(from venturebeat)

各种资产在手机推广时选择的结构完全不同，这似乎是个问题。技术专家最初的做法倾向于让所有人针对所有资产运行一致的结构。但是，运行不同结构来支持手机推广确实显得更有意义。

最大的问题是，如何处理HTML5和原生应用之间的纷争。有关这两者间的多数讨论都集中在不同的技术特征上。但是，真正的决策需要以站点流量类型为基础。

流量来源

如果站点大部分流量是来自于谷歌、Facebook和Twitter的间接流量，那么该站点应当使用移动网页和HTML5。因为多数的站点用户通过链接到达站点，因此内容必须迅速加载到手机浏览器上。此类站点包括音乐歌词站点和其他类型的信息搜索站点。

如果站点大部分流量是直接间歇流量，这意味着用户会直接访问站点，但是访问频率并不高，那么站点应当执行HTML5移动网页。这些类型的站点属于“观光站点”，人们不会频繁访问，因而用户不太可能下载应用。公司网站属于此类站点，比如CBSi.com主页。

如果站点大部分流量是直接流量，人们频繁通过收藏夹或输入URL地址直接访问站点主页，那么该站点应当使用原生应用。此类站点包括CBS.com、CNET Reviews和其他知名度较高的站点。

如果站点拥有的是直接间歇流量，这就意味着人们会不时访问站点，那么应当使用的是HTML5而不是原生应用。对于有大量直接流量的站点而言，原生应用还提供其他有用的功能，比如通知和离线存储，这些对间歇或间接流量的站点都不适用。

直接和间接流量混合的站点应该同时使用原生应用和HTML 5。但是，需要注意的是，不要强行向那些访问手机移动站点的人推广原生应用。这会让用户感到厌烦。多数此类访问者都是通过点击谷歌或Facebook上的链接访问站点，他们期望能够直接看到内容。他们根本不想下载你的应用。

type-of-traffic(from venturebeat)

费用

在决定是要构建HTML5移动网站还是原生应用后，下个大问题就是愿意花多少钱来制作。事实上，选项只有两个：便宜地完成或昂贵地个性化。

通常情况下，站点应当先选择可行且便宜的解决方案。对于HTML5移动网站，Pressly和Mobify之类的商家会帮助你制作完成，赋予站点极具吸引力的界面。带有手机插件的WordPress能够在iPhone和Android设备上良好地运转。记住，要添加“查看整个站点”的选项，这样你的用户才能够跳出手机体验，访问可行的HTML5方案还未支持的功能。

要制作可行的原生应用，MobileRoadie之类的服务值得考虑，可以让你得到优秀的iPhone和Android原生应用，iPad版本不久就将问世。应用美观且使用，提供了众多选项。

对于需要同时支持移动网页和原生应用的站点，很可能不久就会出现可提供同时支持两种传播渠道的产品服务。但是现在，我推荐分别选择相应的制作商。

获得基础的手机呈现方式后，你可以考虑添加个性化体验，增加支持的功能并改善用户界面。不幸的是，个性化意味着需要付出更多成本，对HTML5和原生应用均是如此。

level-of-investment(from venturebeat)

目前有许多综合性的系统可供选择，用来辅助iPhone、iPad和Android原生应用。应当注意的是，这些综合系统需要整合到你的注册、用户资料和内容系统中，而这需要工程和IT方面的工作。诸如FreeRange360之类的综合系统有一个基础平台，可以使这类个性化相当直观。

虽然HTML5已经有所发展，但是其体验还是不如原生应用。Financial Times和Playboy等发行商在HTML5中投入巨额资金，使其功能性贴近原生应用，由此来绕开苹果30%的应用商店费用。但是，目前没有可用的JavaScript库提供高效点击和离线阅读等功能。

也就是说，提供高效的手机网页体验相对简单。jQuery和Sencha等移动库提供了绝妙的HTML5 iPhone式用户界面控制，在PHP和Ruby等现代web框架中，已经足够察觉何种设备正在请求内容并针对特定屏幕尺寸传播个性化页面。这是项繁杂且沉重的工作，但是能够实现，而且控制和灵活性都很棒。

对于主要包含文字和图片的资产，你可以考虑混合HTML5和原生应用的方法。虽然这听起来像是个理想的解决方案，但是这种方法还有待完善，而且将HTML5制作得与原生应用相似还需要大量的工作。

总得来说，在考虑移动发展战略时，站点流量类型决定了是使用HTML5移动网页还是原生应用，然后根据你的预算来决定是达成实用性还是个性化目标。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

HTML5 vs. native apps: How to pick the right path

Peter Yared

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-style tablet interface. WordPress includes mobile plugins that work great on iPhone and 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.

While HTML5 has come a long way, it is still not up to par with the native app experience. Some publishers, such as the Financial Times and Playboy, have come close to native app functionality by investing heavily in HTML5 in order to bypass Apple’s 30 percent app store subscription fee. However, there are no turnkey JavaScript libraries that provide functionality such as efficient swiping and offline reading.

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. (Source: Games Beat)