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-');

Portrait orientation means the screen is 320 pixels wide, right? Not quite.

I've seen a number of tutorials and reference sites out there that are recommending using min-width media query rules such as the one below to provide custom styles for portrait and landscape orientations on smart phones.

@media only screen and (min-width : 321px)

Will every smart phone device always have a visible display width of 320px in portrait orientation?  Not at all. In fact, this code will force landscape orientation CSS rules for a Blackberry Torch in portrait orientation -- the usable display width of the Blackberry Torch in portrait orientation is 360px. We can expect even more diversity in mobile handset  display sizes during 2011.


The usable width of the browser for Blackberry Torch in portrait orientation is 360px. There are no guarantees on device widths or screen aspect ratio in the devices coming to market.

This is a fundamental problem with using media queries to solve the device orientation layout problem.  We recommend you look at a body class based solution such as the one provided by master-class by John Boxall instead!

Image credit: Isriya Paireepairit

Mobile Commerce - Apps vs. Websites

Mobile commerce is one of the most exciting new market segments on the Web today. There's a big opportunity not only in improving the way mobile purchasing works, but also in inventing new ways for discovering, sharing and promoting merchandise. Yet, [most of the e-commerce retailers are not prepared to serve their mobile users][], as our research showed. "Let's get an app" seems to be the strategy for many retailers - which is not nearly enough.

E-commerce has grown to billions of dollars per year thanks to taking advantage of Web fundamentals. Here are just some of the strategies that are crucial to long-term success of online vendors:

> SEO & SEM

> Affiliate Tracking

> Social Media Compatibility (through URL mapping)

All of which need to seamlessly work on mobile. It's pretty much impossible to fully support these strategies in native apps, which have the added requirement of being discovered & downloaded prior to use. Mobile web alone has what it takes to implement a complete mobile commerce portal and retailers seem to agree. It's going to be very exciting to watch this space develop in 2011.

[most of the e-commerce retailers are not prepared to serve their mobile users]: http://blog.mobifymedia.com/2010/10/26/current-state-of-mobile-e-commerce/

Mobify Weekly (09/10) - Opera Mini 5.1 for Windows Mobile Phones Released

Hello everyone and welcome to another issue of Mobify Weekly! Here are some great links that we've run across this week!

Boston wins Digital Government's "Best of the Web" Award We're very happy for our friends in Boston for winning this prestigious award. They were recognized for many of their achievements including prioritizing mobile web accessibility for their city's website. City of Boston's mobile website was praised for being fast, functional, and useful to its visitors. (Stay tuned for an interview with the Boston team on their experiences!)

Opera Mini 5.1 for Windows Mobile Phones Released Opera gave the Windows Mobile crowd a breath of fresh air this week with their new release of the Opera Mini mobile browser. This is very good news for users who are on expensive mobile networks as Opera claims to cut down the amount of data transfer by up to 90 percent.

Why Your Business Needs a Mobile Commerce Strategy Great article by Bill Zielke, senior director of Merchant Services at PayPal on how Mobile Commerce is already becoming the next big thing to hit the web. Is your mobile website ready for the holiday shopping season?

Speed Counts Recently published survey: your visitors will leave your site and may never come back if it loads too slowly. 32 percent of visitors leave a slow loading website within one and five seconds. 84 will give up on a slow loading site after trying it a few times. This really shouldn't be a surprise to anyone but it's nice to see some solid stats. Stats by Compuware.

UPDATE: Nokia Replaces CEO, Brings on Microsoft's President of Business Division This move is long overdue but Stephen Elop was inaugurated this morning at Nokia. Nokia's share has been threatened  ever since the release of the iPhone and Stephen is expected to reposition the company for a counterattack. At Microsoft, one of the things that Stephen was responsible for was Microsoft Office. Can he steer the hardware giant through the rough water? Only time will tell.

Wishing you a fantastic weekend and see you all next week!

Mobify Studio Update 2

We're excited to announce some new updates to Mobify this week!

We've created a simple way for you to insert a floating 'Add to home screen' bubble into your mobile site. This will help you tell your iPhone visitors how to add your site to their home screen as though it was an app!  Furthermore, apple touch icons will now work when a visitor bookmarks your mobile site to their home screen using an Android device.  Look for a followup post on the blog in the next few days on how to integrate this new feature into your Mobify site!

Add to Home Bubble

The Choose screen now shows selector information about the block underneath your cursor. This will help you pick stronger selectors for your mobile view.  Ideally you should pick blocks that have either classes or ids that you intend to keep even when you make updates to your site style.  For example, picking a div with class 'article' would be a strong selector if you plan on always having articles contained in a div with that class name.

We have significantly reduced the byte size of pages using unicode. Unicode is used for many non-English languages, and this improvement will make these pages load even faster.

We've made improvements to our content selection routines! Our block choosing system has always supported both CSS selectors as well as XPATH.  Previously our selection algorithms preferred the XPATH over CSS selectors when both were available.  Our testing has shown that the CSS selector is more likely to be correct, and our system now prefers CSS selectors if they are present.  This should reduce the chance of breakage of the source website HTML is modified as CSS classes and ids are generally preserved through incremental changes.

Performance monitoring - we've added some new features that will help us track performance bottlenecks in our system, and should help us create an even faster mobile experience in the weeks to come.

Subscribe to our blog

Get regular updates to help you create amazing adaptive web experiences.