Background and Context

A few months ago we looked at a snapshot of Facebook’s sharing data on mobile and found that 57% of all sharing was through the mobile web, with all apps on all platforms combined – iPhone, Android and Blackberry – contributing 40%.

(Click for full size image.)

Combine that data snapshot with ongoing rumors of a full HTML-5 version of Facebook, fit for the mobile web and codenamed Project Spartan, and we can start to see the macro trend of Facebook’s business and users is to embrace the mobile web as essential.

Mobile Summary of S-1 Filing

In Facebook’s S-1 Filing, we saw more details on mobile usage, growth and revenues that caught our eyes.

(The S-1 is form companies use to describe their business when they go public. Here’s more background on S-1 filings.)

And a few of the mobile details that stood out in the coverage:

• Facebook reports 845 million Monthly Active Users (MAUs)
• 57% of monthly active users visit Facebook every day and are classified as Daily Active Users (DAUs)
• 425 million of those monthly active users (~50%) used Facebook mobile products in December, 2011
• Facebook does not serve advertising on its mobile experience so increased mobile usage actually hurts their revenues
• Facebook are nervous about mobile because “user growth and engagement on mobile devices depend upon effective operation with mobile operating systems, networks, and standards that we do not control”

As covered by ReadWriteWeb in Facebook’s Biggest Risks Explained, quoting Antone Johnson in point form:

“No revenue currently generated from mobile advertising; unclear how much mobile use could be monetized; failure to solve this puzzle combined with a dramatic shift toward mobile usage could be a serious problem for FB; and per the next risk factor, they don’t control the iOS and Android platforms.”

So mobile presents a paradox for Facebook: huge growth, no current revenues.

Mobile is how their users are increasingly choosing to access Facebook but they haven’t figured out how to insert their key revenue driver – advertising – into the experience.

Mobile: Engine of International Growth

Reading the Facebook S-1 and knowing a lot about international mobile traffic, we can see that a heavyweight driver of Facebook growth around the world is the mobile web.

From the Facebook S-1:

There are more than two billion global Internet users, according to an industry source, and we aim to connect all of them. We have achieved varying levels of penetration within the population of Internet users in different countries. For example, in countries such as Chile, Turkey, and Venezuela we estimate that we have penetration rates of greater than 80% of Internet users; in countries such as the United Kingdom and the United States we estimate that we have penetration rates of approximately 60%; Increased mobile usage was a key contributor to this growth. DAUs as a percentage of MAUs increased from 54% in December 2010 to 57% in December 2011.

And as move towards 2014, the year when mobile becomes the #1 way to access the web, mobile will increase its importance as the engine for international growth of online businesses.

Reading into the numbers, it’s apparent that Facebook see the popularity of the mobile web today and also a dominant future for the mobile web around the globe.

So it will be interesting to watch their evolution as a public company, as they are required to share more information publicly.

If early indications are accurate, mobile apps will be part to their mobile strategy and the mobile web will be essential.

What’s the right thing for them to do: mobile apps or mobile web?

Each client has their own situation, customer needs, goals and context. A blog post won’t do justice to answering the full question.

But this blog post seeks to provide some data on how people use the largest website in the world with their mobile devices.

Using data gathered by Dan Zarrella in his strong post New Data: 33% of Facebook Posting is Mobile, we broke down the 33% of mobile traffic posting to Facebook a little further to see how they were accessing Facebook.

(Click for full size image.)

According to the 70,000 samples Dan gathered, mobile web contributes 57% of the mobile posts to Facebook. All apps combined contribute 43%.

So when we hear rumors of Facebook’s Project Spartan now we can start to see the reasoning behind the investment and direction towards a full HTML 5 version of Facebook.

Reading into the numbers, I think we can guess that Facebook see mobile web’s popularity today and they also see a dominant future for the mobile web.

So while apps are part to their mobile strategy, the mobile web is essential.

(Thanks to Darren Barefoot for the coffee and conversation that spurred this post.)

Enter the age of mobile web. At Mobify, we believe that every link on the Web should present an amazing mobile experience. One way to do this is by making content management systems mobile-aware. When the CMS detects a mobile user, it launches an alternate rendering path and generates new HTML server-side. This new mobile web page is then presented to the user – for a great example check out WPTouch, the most popular mobile plugin for WordPress.

The problem is, most content delivery networks don’t bother telling the origin server about mobile users, serving whatever is cached for the URL. And why should they? The whole point of CDN cache is reducing the time it takes to access web content. Plus, when not done properly server-side mobile rendering can actually be worse than the desktop website, as this comic illustrates.

So, what to do? Akamai allows limited code execution right on its edge nodes with EdgeComputing, but this is counterproductive for today’s agile web companies. Mobify’s Studio service relies on JavaScript to detect mobile users, redirecting them to the “m-dot” version of the same URL which is cached separately (see it in action by going to wired.com or newyorker.com on mobile; both use Akamai). In the future we’re going to see even more mobile rendering shifted into the browser, powered by JavaScript and HTML5. This brings the best of both worlds – responsive client-side apps that can be stored on a CDN for optimal performance (we use Amazon Cloudfront).

In my next post, I’ll try to guess why Matt Mullenweg doesn’t use WPTouch on his beautiful personal blog and share some of the things we learned about Drupal 8 from Dries’ DrupalCon keynote. Stay tuned!

This is a great example of using client-side technology in order to improve the mobile web experience. Our first impressions are below.

Surprisingly, GIP fails to encourage users to visit some of the best mobile experiences out there – rich HTML5 mobile websites, like Google Maps. Here is the mobile preview for the “Google Maps” query:

Instant Preview for Google Maps Mobile

Compare this to the actual, much prettier Mobile Google Maps:

Any site requiring a login will have a very weak preview (this is a limitation of the image thumbnailing technology used by Google):

Facebook Mobile Preview

Best previews are available for mobile websites with liquid layouts:

Sometimes GIP follows mobile device detection redirects…

New Yorker Mobile Preview

…and sometimes it doesn’t:

Twitter Mobile Preview

Overall, the experience is fast, non-intrusive and valuable for a lot of web content out there. To take Mobile Instant Preview to the next level, Google needs to index and promote AppStore and Android Market apps related to the search query/URL. This would solve a huge issue with discovery and retention of many useful native apps out there. 

In past three years, devices with high-quality browsers captured most of the market. iPhone, Android, and Blackberry 6 browsers are now competitive with desktop ones in correctness of Javascript and CSS implementations. Meanwhile, increased use of mobile social networking, as well as bookmark sharing and synchronization, made use of m.yoursite.com a problem. Today, a URL can pass through multiple services used by both mobile and desktop users.  Making sure that user ends up on correct URL for their platform is becoming more and more difficult. In addition, having a separate mobile domain introduces SEO concerns, requires additional SSL certificates and DNS configuration, and gets even more complicated when more device types are added  (tablet, TV).

These changes made us revisit the original assumptions. Our toolkit is now expanded to include complex JavaScript processing, and use of m.yoursite.com can hinder deployment, URL sharing, and use of SSL encryption. So, we started thinking about serving a single copy of website to both desktop and mobile users, and using JavaScript to transform it into mobile form. This approach can remove a whole lot of issues, in exchange for a single big one: how can we make this work correctly and quickly?

The most obvious way to transform a website on the client-side is by using override stylesheets for CSS (possibly delivered through media queries), and JavaScript content rewriting for HTML. The difficulty with this method is that all resources (images, scripts, stylesheets, frames) start loading as they are parsed, and browsers give us no reliable tools for preventing or canceling HTTP requests. So, if one was to modify the page after its markup finishes parsing, the resulting mobile page will load all the desktop resources, all the mobile-specific ones, and spend CPU time on extra processing. Since mobile browsers load few resources at a time and suffer from higher network latencies (especially on 3G), this is a recipe for unacceptably low performance.

To maintain reasonable performance, our client-side solution would need to exercise control over which resources are loaded before rest of the browser can see the resource and start an HTTP request. This requires overriding default browser behavior of fetching every resource as soon as its HTML tag is parsed in the document. We have figured out a way to accomplish this in the new Mobify product.

The webpage includes Mobify script snippets that lie dormant most of the time, but initialize and capture page content as text if they detect a mobile browser. As a result, the captured content is not processed by the browser, preventing it from issuing HTTP requests or executing unwanted Javascript. Now, transformation code can build the mobile page out of fragments of desktop one, and load just the pieces that are needed. Finally, the newly constructed markup is injected into page itself and has the desired external resources re-enabled, resulting in the complete mobile page.

As a result, mobile and desktop pages can live at same URL despite using drastically different markup and resources. We already do have some websites using this technology, such as http://alibris.com, http://kiwicollection.com, and http://threadless.com. In future posts in this series, we will describe the lower-level technology used to perform content escaping and transformation, and provide details on tools that the mobile page author can use to control inclusion of HTML and external content.

With the iPhone raising the bar for mobile experiences, it wasn’t enough for websites to just “work” on a phone anymore. Navigation, content and forms were expected to be laid out logically to fill screen. Content had to be built from the ground up for delivery over low bandwidth connections to slow devices.  Most importantly with the collision of the mobile and desktop webs there needed to be URL mapping between the two so that no matter how a viewer arrived on a page, they always got an experience tailored to their device.

We built Mobify Studio to enables designers to build the fantastic mobile experiences that viewers demanded. Three years later, the fundamentals behind building great mobile experience haven’t changed but the mobile devices themselves have.

Smart phone traffic dominates today’s mobile web. Over 80% of our network traffic could be classified as “Smart Phone”. These powerful devices connect to the web using fast, reliable 3G and Wifi connections. This shift in the device landscape has caused us to re-evaluate the design decisions we made in 2008 while building out current version of Mobify Studio.

Decision made in 2008: The mobile web is not ready for JavaScript.

Mobify Studio’s content optimizations alter the DOM. JavaScript is bound to specific DOM representations. Our modifications subtlety break existing JavaScript in unpredictable ways. In 2008, mobile browsers have incomplete or incorrect implementations of specifications crucial to JavaScript. With the goal of delivering sites with a minimal footprint, we can’t afford to serve JavaScript content to devices only to have break. We designed Mobify Studio to strip JavaScript from pages.

Decision made in 2008: Mobile websites should live at mdot.

To receive a page optimized by Mobify Studio, a browser must make a request to Mobify’s webservers. Sites made with the Studio live at a different domain than the desktop website. Using DNS CNAMEs we made it possible to deploy mobile views to an mdot like m.yoursite.com. This had the helpful side effect of sharing HTTP Cookies, allowing for simultaneous login between mobile and desktop sites. However it also created a need to redirect mobile traffic from the desktop website to the mobile view. To do that we developed three methods for handling redirection at either the webserver, application or client side level.

Smart phone dominance challenges these decisions. In the next post we’ll outline how we’re adjusting our core technology to build the next generation of great mobile experiences.

Mobify Studio homepage circa 2008!

Recently we’ve been looking at the link between email marketing and mobile revenue. Turns out that a good email strategy quickly contributes to mobile purchases. Here are some of the early findings:

Email newsletter from Threadless

1) Email is often checked first thing in the morning – from a mobile device. Are you guilty of typing up an urgent reply while still in bed? As smartphone adoption grows, email is increasingly accessed on the go. When receiving digest emails from their favourite fashion brands, many mobile users will click the product links, heading directly to the e-commerce site.

2) Email often brings exclusive and time-sensitive promotions, creating a sense of urgency. Mobile shoppers are a lot more focused on purchasing a particular item. If something is on sale and limited in quantity, mobile devices will often be preferred.

3) Mobile e-commerce greatly benefits from email awareness campaigns. Many online shoppers still have poor expectations for the mobile web. Letting the audience know about a fully transactional mobile store is key for driving traffic and repeat customers. Newsletters are a great channel for this type of promotion.

Email is crucial for driving growth in mobile e-commerce and should be included in every retailer’s mobile marketing plan.

I think that we’ll continue to see more companies <…> who put us [Groupon] to shame a couple years from now with their rate of growth.

According to Andrew, Groupon grew so quickly thanks to its social features. What’s going to drive web hyper-growth in 2012? The mobile web – but it’s not ready yet.

Consider Instagr.am, the darling of early adopters this winter. It’s up to a million users, growing through Twitter and app downloads – which is awesome. However, many are lost at every stage of the acquisition funnel – clicking the AppStore link, installing, learning the native UI. What if you could start taking photos & applying filters via the mobile browser – right after clicking that very first instagr.am link? They’d probably be at 5-10 million users by now. Today, the Instagr.am website isn’t even mobile-friendly.

Universal JavaScript APIs for mobile cameras are on their way (you can use PhoneGap in the meantime) – but not today, limiting growth opportunities for mobile-centric web services.

Another good example is online advertising (search or display), where every mobile click leading to a desktop page will convert at a disastrously low rate. This inhibits a lot of mobile innovation in pay-for-performance advertising – especially in e-commerce.

Mobile web has to get more mobile in order to facilitate business models of tomorrow. Let’s do our part to make it happen!