|
Size: 2344
Comment:
|
Size: 6289
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 3: | Line 3: |
Link to talk |
I am continuing to expand my thoughts on this, but see [[http://www.slideshare.net/shoobe01/really-using-your-device-capabilities-12625998|this presentation]] on Slideshare for a good summary of it for now. |
| Line 8: | 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 43: | Line 42: |
| List from the presentation... explain the description for maps | === 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 === 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&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. === 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. === 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&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. |
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
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&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.
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 linking to the email client.
<a href="mailto:shoobe01@gmail.com?subject=Subject Line&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
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.