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.

Apps

There are far too many of these to cover in detail. In general, they all have great support for all these features, and more. Maybe I'll at least list them sometime.

Custom URI Schemes

This gets it's own category as it strongly blurs the lines between apps and the web. In short, installed applications monitor specific http addresses, when linked to from a browser or application. If they see a match, they launch instead. This means you can build a series of apps for your organization, and have them all link together into an ecosystem of related tools.

Of course, being http requests, if there is no app installed, then the user just gets the web version of the same tool instead. It can be made pretty seamless.

• Android: I find the dev.android documentation to be slim and confusing. this discussion at Stack Overflow is a better starting point.

• iOS: here is the developer.apple version of this information. Scroll down till you see "Communicating with Other Apps" or search for "Custom URL." Google searches for this work well also. Several others have good discussions of it.

• Blackberry: Blackberry and Stack Overflow discussions of this.

Web

Here, things get tricky. And they change over time enough that two year old resources aren't good enough. So, I've started my own research and recording of capabilities. The rest of the page is about this.

Device Detection

This is all moot without knowing what device, browser and so on you are building for. This is not a client side sniff and re-style responsive design thing. It requires real device detection, and the server responding with different code per platform.

This is worthy of a whole article, so we have one. I'd go read that before you go any further.

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. Sometimes, remote test devices are just being buggy the day I tested.

Results

Samsung Wave 3, GT-S8600 (RTL) OS - Bada 2.0 Browser - Phone - SMS - Location - Directions - Email -

Need to test or re-test. Anyone who has these devices can do it for me.

• Touch screen Blackberry
• Windows Phone
• Symbian Anna/Belle email linking

Footnotes:

1. SMSTO, not SMS. But then supports sending the body link and everything.
2. Also supported the body, but I have yet to determine a format that doesn't munge the recipient number as well.
3. SMS and SMSTO are not supported on S40, but if you use the MAILTO link, it opens a dialogue asking if you want to send via Email or SMS. This even supports putting body content in the SMS. So, the function is there, just not the same as everyone else does it. Due to length issues with SMS, this is not a great thing for our purposes, generally.
4. See note 3. Works, but user has to select Email again, vs. SMS.
5. ONLY works without the two slashes after the tel: type.
6. Cannot tell as Nokia makes it SO hard to set up an email account. And, it refuses to just go there without full setup. But I think it works from other reports.
7. Auto connects. As in, doesn't say "Do you want to call..." but just starts dialing. This may or may not be the expected behavior, so think about it, or make it more clear that the user will 'dial the phone' not just link to the dialer in this case.
8. Only opens the SMS tool, with a recipient number, but will not pass body content. Usually, fails to fire the link correctly if body content is included at all. My current solution is still to build an SMS sending web page, and pay for your own SMS gateway.

Link Formats

These, in general, are formatted as a protocol, then addresses. Just like http://web.address but replaced with other protocols.

Formats are key. Very minor changes can be critical. For example, almost every device demands two slashes after the protocol, as http uses. But S40 will interpret these slashes as part of the address, so they have to be removed. See notes on the table above.

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>

If auto-detection is causing non-phone number strings on the page to be links, you can use this:

• <meta name=”format-detection” content=”telephone=no” />

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. This also means you need to pay for your own SMS gateway, and other tedious things.

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.

Symbian Belle - Web

Nokia 603 (RDA), NokiaBrowsers/8.2.1.20

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.

Featurephone - S40, Nokia Browser

This is combined testing on a Nokia Asha and Nokia C2-01, both via RDA. Bugs in the remote tester made it more reliable to test the two and combine. A few features wouldn't work for me on one of the handsets, but there are no other reports of them not working so I combined the two instead.

Featurephone - S40, Opera Mini

Nokia C3-00 (RDA)

Other Resources

Maximiliano Firtman, who wrote Programming the Mobile Web has some articles about some of these from a few years ago.

• http://answers.oreilly.com/topic/2166-how-to-send-a-text-message-from-your-mobile-website/page__p__4005&#entry4005

• http://answers.oreilly.com/topic/2135-how-to-initiate-a-phone-call-from-your-mobile-website/page__p__3956&#entry3956