In general, on mobile, you should use device capabilities or existing instead of rebuilding features. This page discusses the use (including code examples) for the web. Similar behaviors are available from within native applications, usually with even better results.

I am continuing to expand my thoughts on this, but see this presentation on Slideshare for a good summary of it for now.

Methodology

These were all tested in the second quarter of 2012. See below the table for full details of the devices and browsers tested. A test page was created with various types and formats of links. Many additional links were tested, which had very low success rates. This is a summary of the most useful variations.

Browser identity was mostly confirmed with whatismybrowser.com. In some cases, additional UA string sniffing was used.

Yes: Works as expected. Sorta: Works with notable caveats. Generally not usable, but maybe it's all you need. See footnotes. No: Does not work, but not catastrophic. NO: Errors or other unusually poor results. ?: Could not be tested. For example, a tablet without voice.

Results

Nokia Asha 300 (Remote Device Access) OS - Featurephone, S40 Browser - Nokia Browser Phone - No. No link appears. SMS - No, but link appears. See email note Location - Yes, Browser Directions - No Email - Yes... but acts like Share link, offers options for SMS and Email. BOTH work perfectly, with body and everything.

Nokia C3-00 (Remote Device Access) OS - Featurephone, S40 Browser - Opera Mini Phone - Yes (auto connects) SMS - No (neither sms: or smsto:)l Location - Yes, Browser Directions - No Email - NO (Shows as link, but cannot be scrolled to)

Nokia 603 (Remote Device Access) OS - Symbian Belle Browser - Phone - SMS - Location - Directions - Email -

Nokia WINDOWS (Remote Device Access) OS - Windows Phone Browser - Phone - SMS - Location - Directions - Email -

BADA OS - Windows Phone Browser - Phone - SMS - Location - Directions - Email -

1) SMSTO actually supports sending the body link as well. 2) Also supported the body, but I have yet to determine a format that doesn't munge the recipient number as well.

Link Formats

Phone

Launches the Dialer, or allows access to the Contact List/Address book, sometimes tangentially (e.g. through the dialer). Usually does not dial immediately, but asks the user to confirm. But, no guarantees; some just dial right away.

Though mobile browsers tend to try to detect phone numbers and make them links automatically, by no means is this accurate or reliable. In an ad hoc survey, around a quarter of non-linked phones are not detected, or are detected wrong (the phone tries to dial an 8 digit number, etc.). Always use this link format. This also allows any text to be uses as the label, such as a shorthand mnemonic version (e.g. 1-800-Flowers) if your branding or marketing guys demand that.

• <a href="tel:816-210-0455">Call me</a>

If there is any chance at all that international users will encounter the number, include the country code. Remember, it doesn't have to be visible, and can just be in the link.

• <a href="tel:+1-816-210-0455">816-210-0455</a>

SMS

Though SMS links traditionally worked exactly as well as the tried and true mailto: email link, iOS barely supports it, so Android barely supports it, so now everyone barely supports it. The only reliable format for an SMS link is this:

• <a href="sms://+1-816-210-0468">Send us a message</a>

As you can see, there's no body. I have yet to find a use for this, but there it is. So, right now, my recommendation is to go ahead and keep building SMS sending pages for most mobile websites.

Note that SMS from within native iOS and Android apps works fine, and you can include the body easily. This is the code for including body content, if you want to try it.

• <a href="sms://816-210-0455&amp;body=Buy Designing Mobile Interfaces for me http://j.mp/pzECVt">Share this product</a>

As always, include country codes if there's any chance they'll be needed.

If that's not enough, there is another encoding method for SMS sending. Normally, do not use it, but if you have a specific device you are targeting, and have issues with sms: then try smsto:

• <a href="smsto://+3490322111?body=Test message from 4ourth Mobile">This number</a>

Note that the one browser that fully supported inclusion of the body, only did so under this format. It may simply be out of date, though, and the next update will remove the function entirely.

Map a Location

The codes above in the Location column refer to the method that works best. Geo: and Map: should be self-explanatory, but the "Browser" one means the conventional http: URI format. These are supposedly captured sometimes by mapping programs on Blackberry or other devices, but I only got them to work by opening in the browser. This does provide full capability, and generally works fine, though task switching can be lost (the user has to back out of the map, instead of switching between your browser page and the map).

• <a href="maps:q=5600+russell+ave,+mission,+ks+66202">See my house</a>

  <a href="geo:0,0?q=5600+russell+ave,+mission,+ks+66202">See my house</a>

  <a href="http://maps.google.com/maps?hl=en&amp;q=5600+russell+ave,+mission,+ks+66202">See my house</a>

The variations of each format difference are required to make them work, in my testing at least. Copy the format precisely.

Directions

Directions is very poorly supported. I only found it reliably working on iOS, using the code below. Again, this was only tested on Google Maps, as it is by far the most ubiquitous solution.

• <a href="maps://maps.google.com/maps?hl=en&amp;saddr=5600+russell+ave,+mission,+ks+66202&amp;daddr=LaMar's+Donuts,+5901+Johnson+Drive,+Mission,+KS">My house to Lamar's</a>

I generally do not find this to be a huge impediment. Most interactions that need directions are to give the user driving directions to a single location. You can therefore just load the link to the destination, and the user can easily get directions from any other point.

Email

I am sure you are all familiar with this link, but only use it under duress. Well, that's because desktops are stupid, and treat links without context. On the mobile, it's the opposite, so the preferred email method is not a form in the page, but linking to the email client.

• <a href="mailto:shoobe01@gmail.com?subject=Subject Line&amp;body=Message body follows and can be very long.%0A%0AYou can even put in linefeeds.">This address</a>

This is very robustly supported, and you can even include linefeeds, to format the email more usefully. Use the encoded values above, as other variations I tried were unreliable, at least sometimes.

Devices & Browsers

I have all the data, it's just tedious to get it in here.

"Browser" is whatever that OS calls it. So, I use their name. In general, I only get specific when it's not super clear.

Featurephone - UC Web (J2ME)

LG 500G (Tracfone) UC Web, J2ME version. UC Web is (well, so I hear) a big browser in China. It's also pretty good on a lot of platforms, and is very different. In this case, it's a third party J2ME browser, so the part where it acts somewhat different than the built-in (but probably still J2ME) browser is interesting. Yes, featurephone users do install apps, and browsers are a common one in countries where the default browser doesn't well support their language (mostly in Asia).

Featurephone - Access 3, VZW

Samsung Alias 2 Access NF3.0.22.2.17 Rev 1441 BUT identified as Firefox 2 on Linux, 1280x1024, by Verizon Wireless intermediary. This causes no end of trouble trying to get it to act like an Access browser, so it's only of so much value for any testing. But there are a lot of these out there, so be aware that good behavior on good phones doesn't mean a think if your operator screws everything up. A lot do.