|
Size: 3242
Comment:
|
Size: 5179
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| In general, on mobile, you should use device capabilities or existing instead of rebuilding features. | 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. |
| Line 7: | Line 7: |
| 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. | 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. |
| Line 46: | Line 46: |
| {{{<a href="tel:816-210-0455">Call me</a>}}} | |
| Line 47: | Line 48: |
| {{{<http://>}}} |
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>}}} |
| Line 51: | Line 52: |
| === Location === | {{{<a href="</a>}}} Note that SMS from within native iOS and Android apps works fine, and you can include the body easily. === Map a Location === {{{<a href="</a>}}} {{{<a href="</a>}}} {{{<a href="</a>}}} 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). |
| Line 53: | Line 68: |
| 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=""></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. |
|
| Line 54: | Line 74: |
| 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 {{{<a href="mailto:">Send an email</a>}}} |
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
OS |
Browser |
Phone |
SMS |
Location |
Directions |
|
iOS 5 |
Mobile Safari |
Yes |
Sorta |
Yes maps: |
Yes maps: |
Yes |
Android 3.2 |
Browser |
Yes |
Sorta |
Yes geo: |
? |
Yes |
Android 3.2 |
Opera Mobile |
Yes |
Sorta |
Yes geo: |
? |
Yes |
Android 3.2 |
Skyfire |
Yes |
Sorta |
Yes geo: |
? |
Yes |
Android 4.0 |
Browser |
Yes |
? |
Yes geo: |
No |
Yes |
Browser |
Yes |
? |
Yes Browser |
No |
Yes |
|
Featurephone |
Obigo |
Yes |
Yes (1) |
Yes Browser |
No |
Yes |
Featurephone |
UC Web (J2ME) |
Yes |
Yes (2) |
Yes Browser |
No |
No |
Featurephone |
Access 3, VZW: |
Yes |
NO |
Yes Browser |
? |
No |
To Add: Windows Phone Symbian Belle Bada Anyone got a dumbphone virtual tool for free?
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).
<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
<a href="</a>
Note that SMS from within native iOS and Android apps works fine, and you can include the body easily.
Map a Location
<a href="</a>
<a href="</a>
<a href="</a>
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).
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=""></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.
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
<a href="mailto:">Send an email</a>
Devices & Browsers
iOS 5.1 Mobile Safari (iPod Touch)
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.