What’s Next for Mobile Now That Adaptive Web Design Has Failed?

This post was also published in VentureBeat.

This article was written for business readers. Due to an outcry from the responsive design community, I added the word "web" to the term "adaptive design" to avoid confusion with progressive enhancement, and updated the text to read that Facebook uses "a precursor to" responsive design, even though very techie trades like RWW say that Facebook uses responsive design. Obviously, the outcry has more to do with the content than the terminology, but it's always good to be pedantic. Read on!

Analysts commenting on Facebook’s IPO have highlighted a major issue in mobile computing: that it’s incredibly difficult to monetize on mobile devices. Like many other engineering-led cultures, Facebook has embraced adaptive web design, a precursor to also known as responsive design, where essentially the same code can render itself down from a desktop browser to a tablet to a diminutive mobile screen.

Adaptive web design is an elegant solution to the thorny technical problem of having to deliver a content experience on multiple devices. And engineers love more than anything to apply the same hammer to multiple nails.

Unfortunately, users do not agree. Desktop web browsers, tablets, and mobile devices are fundamentally different and are used in very different ways. Across our properties at CBS Interactive, we have experimented with a variety of adaptive and direct designs and are learning the hard way that a one-size-fits-all solution delivers a subpar user experience.

Turn those mobile pages

The app has defined the mobile form factor. Users expect to see menus with only a few relevant options that do not require scrolling, titlebars with back buttons, and do not mind paging through content as long as it loads fast. In contrast, when a full size web page is adapted down to a mobile form factor, it forces a lot of vertical scrolling – even if some components are removed and others are made smaller.

Narrowing a mobile experience down to the essentials of what a user wants while mobile is critical. Tight menus and quick page loads compel users to turn more pages, which is essential in the small mobile form factor that has limited ads. Some ad units on mobile are worth more on mobile than desktop — for example, someone reading a product review on a mobile device in a store is likely contemplating buying that product.

Content publishers can learn a lot from airlines and banks, which are usually technology lagards. The mobile sites of United Airlines and Wells Fargo are tight, focused, and substantially different from their websites.

Tablets are for swiping

The tablet is essentially a magazine form factor, and users have been trained by numerous popular apps ranging from iBook to the New York Times to Flipboard that they should swipe right to left to page through content an a tablet. Users are perfectly happy to swipe through an article that is split into several pages, since this is what they did with magazines.

Rather than adapting a web page down to the tablet form factor and requiring users to scroll vertically, publishers should embrace swiping. Users are not perturbed at all to see a full page interstitial ad stuck into the mix while paging through content, making the tablet extremely monetizable.

Swiping is very difficult to code for mobile web. Fortunately, there are turnkey solutions such as Pressly and OnSwipe that make it easy for simple sites to create swipeable tablet editions. Extensions to jQuery Mobile and Sencha Touch make it easy for programmers to add swiping features to their mobile HTML.

Let websites be websites

Website design is proven, monetizaton techniques work well, and users expect sites to function the way they currently function. There is no pressing need to substantially change how they work.

The trend of “iPadification” of websites is more about adding simplicity and whitespace rather than a complete restructuring of how a website should work. Some types of services, such as Twitter, provide a tablet-like experience on their website. Twitter’s website offers a clean design with white, rounded content areas and no dynamic menus. Users are comfortable scrolling vertically on tablets to see streams, so the same design works well for desktop web and tablet.

It is painful for engineers to have to support three different use cases for three different form factors. However, particularly for content sites, the effort bears worthwhile fruit in terms of mobile monetization.

Big Data May be Hot, but Little Data is What Matters

This post was also published on CNET.

Big Data is in vogue, with a glut of startups and numerous large installations appearing in corporations. At CBS Interactive, we process almost one billion events a day that flow from our Web and application servers over message queues to a cluster of 80 twelve core Hadoop nodes that then feed a Teradata data warehouse.

Processing and analyzing such a large volume of data helps us ask important questions: Which pages on which properties are most profitable? Who goes where across our various sites? What types of content generates the greatest number of advertising conversions?

But here's the thing: Most of our conversations with product and business managers are spent discussing what I like to call "little data."

Little data constitutes the nuts and bolts metrics of running a business. For a Web property, that means getting a handle on issues such as the bounce rate, SEO session starts, social session starts, funnels of how users flow through a property, and page views per session. Too many people lose sight of these simple but critical metrics.



Monitoring and actively managing a Web property to these "little" metrics creates significant lift in page views and conversions, and that helps revenue. Even something as simple as actively managing the hoops you make people jump through to register for your site and the sorts of emails you send when they do builds and grows a loyal following.

One of the most critical metrics we are tracking comes from the gaming world: the ratio of daily active users to monthly active users (DAU to MAU). When the ratio is low, say around 0.03, it means that your unique users are coming only once a month, and you're essentially running a fly-by tourist site. When the ratio is high, such as Facebook's estimated 0.60, it means that a majority of your users are using your site on a daily basis and that your property is a key part of their online lives. (I can't share the DAU to MAU for our sites, as they're confidential.)

Taking control of little data

There are a variety of inexpensive little data tools that are easy to implement. SimplyMeasured is excellent at managing social traction -- i.e., how much impact your site is making on various social networks. KISSMetrics is world class at managing "conversion funnels," the path a user follows through a site before "converting" to a sale. Google Analytics, which is free, does a great job of managing metrics such as bounce rate and SEO session starts, measures of how "sticky" your site is and how well you're doing at attracting new external visitors. Implementing such easy-to-use tools encourages product and business managers to actively manage their sites with "little data" metrics in mind.

Managing a site by the numbers shouldn't be taken to the extreme, however. Sites need to look good and say something relevant to readers; they shouldn't just be optimized within an inch of their lives to drive revenue. We don't, for instance, want to make CBSNews.com look like GoDaddy, which is -- understandably enough -- completely optimized to drive revenue.

Growing up to big data

Once the use of little data becomes pervasive in an organization, big data can then begin to help decision making, since a culture of data-driven decisions is ingrained. Moving beyond just simple web metrics, big data can provide an integrated view of a business by integrating financial metrics, answering questions you hadn't even thought of when initially setting up a site, and deciphering trends across disparate sets of data.

Big data is hard to do, and can be very expensive and time consuming. Integrating revenue and cost data in order to manage end-to-end business models is a complicated and time consuming task. Some organizations decide to outsource to companies like Omniture and Webtrends (where I used to be a GM), which can help figure out how to tag and manage the process, in addition to storing the vast amounts of data required for meaningful analysis.

If your organization has enough volume and the technical competence to do your own implementation, keep in mind that it's easy to get lost in the process of building out big data infrastructure and lose sight of the fact that, in the end, big data needs to be usable. This might sound straightforward, but in practice it can be anything but. It requires highly skilled data scientists and strategists that understand business problems and can distill the data into simple, actionable metrics.

In effect, the magic of big data is turning it into little data.

How Expanding Twitter's Pledge Could End the Patent Wars

This post was also published on CNET and VentureBeat.

Twitter's momentous announcement yesterday that it would only use its patent portfolio defensively was received with wide acclaim by the tech world. With two small changes, Twitter's Innovator's Patent Agreement (IPA) could actually completely change the landscape of software patents.



1. Share patents defensively with any other company that signs the IPA

Allow any company that is a signatory to the IPA to use each other's patents defensively. To qualify, a company would have to have at least 10 patents to contribute and no active patent litigation. The minimum of a 10-patent contribution creates a virtuous circle that incents even startups to innovate with patents, as they will get an umbrella of patent shielding from all other companies that have signed the IPA.

With this small change, Twitter could spur a wide following of companies that follow suit, as they will all mutually benefit from joining the IPA. While there are no guarantees that will avoid all patent claims and trolls, the combined patents of all of the signatories would provide numerous claims that could undermine predatory patents.

Currently, companies can only obtain broad patent coverage by paying defensive patent rollup companies like RPX Corporation. While RPX has a broad array of excellent patents that can undermine many patent claims, RPX is expensive and only accessible to larger corporations.

2. Make the IPA patents perpetually defensive

The software equivalent of hammers and nails are patented today, and developers can't make anything that doesn't violate numerous patents. When I left Sun Microsystems in 2003 and started a company, I had to violate my own patents to do what at that point had become widespread methods of building Web applications.

Fortunately, Sun, like Twitter, only used patents defensively. However, it is a case in point that such patent promises can be transitory. Since its acquisition by Oracle, the Sun patents are being used to sue Google for its use of a proprietary Java virtual machine in
Android.

The IPA provides an encumbrance to prevent future assignees from using the patents offensively, but the language seems weak and lacks real teeth. This could be solved by automatically reverting the patent to the original author or a nonprofit holding company.

This commentary has absolutely no reflection on CBS Corporation's stance on use of patents and is focused on patent strategy for startups.

How RIM Could Save Itself: With a “Super Feature Phone”

This post was also published on CNET and VentureBeat.

Research In Motion is reportedly attempting to sell itself after rejecting the former co-CEO's plan to open up its network to carriers. But for some reason it is not pursuing the creation of a lucrative category between smart phones and feature phones -- the super feature phone.

Less than a smartphone, but far more than a feature phone

What are you left with if you take a smartphone and remove the ability to install apps? It's far more functional than a feature phone, with built in apps for e-mail, Facebook, and a camera. But it's definitely not a smartphone like an iPhone or
Android device. RIM's range of devices are fully capable, with integrated apps and cameras, but suffer from a paucity of apps other than an attempt to integrate Android apps.

The key to the super feature phone is the ability to use cheap data plans in the $10-per-month range, rather than the more expensive full data plans required by smartphones. Not everyone needs a smartphone with a data plan. RIM should focus its devices on the feature phone segment, especially for armies of corporate workers that need access to email but not much else. RIM can easily compete with the players in this space, including Samsung's Bada and Marvell's Kinoma.

RIM should also ensure that the carriers do not sabotage a super feature phone plan by forcing a full data plan, like they did to the ill-fated Microsoft Kin and instead leverage the BlackBerry network.



A lucrative mobile device management future

RIM has always held a core competence in integrating corporate Microsoft Exchange e-mail and calendar servers in sync with its devices. RIM has attempted to expand into the integration of
Google Android and Apple iOS devices with Microsoft Exchange with its Fusion product line, but those devices can now integrate out of the box with corporate e-mail and calendar systems.

Many corporations are implementing bring your own device programs where their employees can use off-the-shelf devices to access corporate resources. This shift has presented an opportunity for new mobile device management software (MDM) that ensure that corporate data can be wiped from lost handsets and terminated employees' devices.

RIM should acquire a few of these MDM vendors, including Airwatch, MobileIron, and Zenprise and roll up this space. Although RIM's stock has been hammered, it is still worth $7 billion and can afford to overpay for growing startups. This will enable it to have new, desirable products to sell through its enterprise direct sales force and channel partners.

Have some marketing fun -- BlackBerrys are better sometimes!

BlackBerrys may not equal an
iPhone, but it is a heck of a lot faster to type out a text message or call someone with a BlackBerry. There is a lot of potential for fun ads that show off that comparison with people in awkward situations that need to contact a friend quickly while their friends are still fumbling with touch screens. BlackBerrys could even become cool again.

Let's face it: Apple and Android are never going to provide cheap devices that don't require a data plan, and this is a huge opportunity for RIM.

2012: The Year of the App-ocalypse?

This post was also published on CNET and VentureBeat.

The Mayans were right about one thing. There is a looming extinction event this year -- of apps that fail to capture a mass audience.

In the past week, two high-profile mobile apps were effectively shut down and acquired -- Hipster by Aol and Oink by Google. Both had big PR buildups, rave reviews from the tech press, and strong usage from the digerati.

What they did not get was traction beyond that, and the teams went on to be acqui-hired. Even apps that seemed to define new categories, such as GroupMe for group chat and Foursquare for check-in, have failed to gain popularity with the general public. GroupMe sold to Skype and Foursquare is shifting from the check-in model to the reviews/discovery space dominated by Yelp. Highlight, the latest digerati darling, drained batteries and fizzled at South by Southwest.

Why do even well-funded apps with successful founders fail -- as happened to Peter Pham with Color, Kevin Rose with Oink, and many others? The reality is that even if you are a proven entrepreneur, consumer anything is hard -- be it Web sites, movies, books, music or toys. Consumers are fickle and have a ton of entertainment options; predicting what they want is incredibly challenging.

On the face of it, well-funded apps like Color and Oink should have had an easy time achieving app stardom. But in today's world, independents have as much chance of taking off as pedigreed players. Having a large Twitter following and getting written up in tech blogs gives you only a small leg up -- not a huge leap over the competition.

At CBS Interactive, we offer a bunch of apps, including very popular ones like 60 Minutes and CNET. Our apps are an additional channel for branded, popular content, and even we sometimes struggle to get traction.



Making an app successful is a two-part problem. The first part is getting people to install the app. You do that by promoting it on your Web site, advertising your app, and promoting installs on Android via offer networks such as Tapjoy. (Disclosure: I am on the advisory board of Tapjoy). It's also critical to nail the initial user experience so that the app gets good reviews.

But achieving a decent number of downloads is just the beginning. Apps need to be relevant in consumers' lives so that users return regularly. They need fresh content, useful features, and reminders for users in the form of notifications and emails. The vast majority of apps, especially games, see their usage plummet not long after download.

The iPhone and Android home screens have space for only 16 icons, and many of those spots are already taken by core features such as the phone, messaging, and map icons. Ask random, non-techie friends to pull out their phones, and chances are that their home screens will be populated by ComScore top 50 properties such as Yelp and The Huffington Post. Actually, I always ask techies pitching me an awesome new app to show me their phones, and usually they don't have anything other than ComScore 50 properties either.

So are apps over? Of course not. But the initial scrum is over, and apps are now just another form of entertainment vying for consumers' fickle attention. And just like other mass media, they area subject to a power law where a few apps get almost all of the attention.

Under the Hood: HTML5 or Native? A Guide

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
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.