peter

Have apps really passed mobile web? Not really.

I’ve been seeing a lot of play on the newswire from the recent Flurry article on the ongoing native app vs mobile web debate titled “Mobile Apps Put the Web in Their Rear-view Mirror”. Flurry is a great native app analytics provider — but I have to take issue with their data analysis and conclusions.

First — let’s discuss the statistical sample. As described in a well-written post by Jeffrey Gluick at Skyfire there are significant problems with the study from the perspective of sampling.  Read Gluick’s article for all the details, but key problems involve which types of users they’re measuring (the data report divides web browsing minutes over non-smart phone users and compares them to pure smart phone users in Flurry’s data set) and failing to accont for apps that are also web browsers  such as Skyfire, Opera, Firefox and Dolphin.

But let’s play along and ignore these problems for now.  Even with Flurry’s interpretation of the data, we see some interesting trends if we remove games and social networking from the equation:

Time spent on mobile, web vs apps excluding games and social networking

Whoops.  If you’re not a game or a social network — better bet on mobile web!

Read More

So, who got a Nexus S for Christmas?

At Mobify, it’s always exciting to see new devices making a splash on our network! We’re also always excited to post statistics from our network – yup, we’re a bunch of geeks. We hope you’ll find this interesting too, though!

The Nexus S is especially easy to segment right now, since it’s the only Android 2.3 phone out there on the market. Here’s the growth in Nexus S activity we’re seeing on our network:

Read More

Mobile browser click-to-call format detection on most phones isn’t what it could be

Plenty of numbers get selected, including addresses, ISBN numbers, and a variety of different types of numeric data that aren’t phone numbers. Further, many well formed phone numbers are never detected, or aren’t detected reliably.

Form detection woe

The problem has led to the use of the metatag below, which disables format detection on most WebKit based phones.  This prevents false-positives in format detection, but also means implicit click-to-call support is disabled.

 <meta name="format-detection" content="telephone=no">

The most reliable solution for click-to-call is to wrap the number in an A tag with tel: scheme as per RFC 3966. If you have CSS styled telephone numbers in your mobile site, an easy way to make them into a tel: style tag is with a bit of javascript. I’ve provided a snippet below to do just that. Given a CSS query selector (the selector must wrap the telephone number, and ONLY the telephone number), it will create an anchor tag with the tel: scheme as the href for the phone number, adding in a prefix you specify. (For example, if the number embedded in your site is 310-222-2222, you might want to prefix it with +1 for international callers.)

(function(){
    function $(selector) {
        if (document.querySelector)
            return document.querySelectorAll(selector);
        // we could fall back better using something like sizzle
        return [];
    }
    function telefy(selector, prefix) {
        prefix = prefix || '';
        var aEls = $(selector);
        for (var i=0,ii=aEls.length;i<ii;i++) {
           var nEl = aEls[i];
           var nText = nEl.firstChild;
           if (nText.nodeType != 3) continue;
           var sPhone = nText.nodeValue;
           // create the new element
           var nA = document.createElement('a');
           nA.innerHTML = sPhone;
           nA.href = 'tel:' + prefix + sPhone;
           // replace the old element
           nEl.replaceChild(nA, nText);
        }
    }
    window._telefy = telefy;
})();

Now we make it go! Let’s say our phone numbers are wrapped in a tag such as:

<span class="phone">310-222-2222</span>

We could call the telefy code above like so, to wrap it in a manner supported by most handsets:

_telefy('span.phone', '+1-');