|
Size: 3047
Comment:
|
Size: 10357
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 27: | Line 26: |
| || BlackBerry Touch || Browser || || || || || || | |
| Line 31: | Line 31: |
| '''These are devices I am testing now, and will put in the table in a little bit''' | |
| Line 32: | Line 33: |
| To Add: Windows Phone Symbian Belle Bada Anyone got a dumbphone virtual tool for free? |
Nokia Asha 300 (Remote Device Access) OS - Featurephone, S40 Browser - Nokia Browser Phone - No. No link appears. SMS - Sorta (3) Location - Yes, Browser Directions - No Email - Yes (4) |
| Line 38: | Line 42: |
| Nokia C3-00 (RDA) 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) |
|
| Line 39: | Line 51: |
| 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. |
Nokia 603 (RDA) OS - Symbian Belle Browser - Web (NokiaBrowsers/8.2.1.20) Phone - No SMS - No Location - Yes, Browser Directions - No Email - ? Cannot tell as Nokia makes it SO hard to set up an email account. And, it refuses to just go there without full setup. 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 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. 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. |
| Line 46: | Line 85: |
| 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). | 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>}}} |
| Line 48: | Line 88: |
| {{{<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>}}} 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” />}}} |
| Line 52: | Line 96: |
| === Location === | 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. 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&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. |
| Line 54: | Line 123: |
| === Email=== | 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&saddr=5600+russell+ave,+mission,+ks+66202&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&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. |
| Line 58: | Line 136: |
| I have all the data, it's just tedious to get it in here. | |
| Line 59: | Line 138: |
| iOS 5.1 Mobile Safari (iPod Touch) | "Browser" is whatever that OS calls it. So, I use their name. In general, I only get specific when it's not super clear. |
| Line 61: | Line 140: |
| === 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 === |
|
| Line 63: | Line 148: |
| 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. | 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. == Other Resources == Maximiliano Firtman, who wrote <a href="http://www.amazon.com/Programming-Mobile-Web-Maximiliano-Firtman/dp/0596807783/ref=sr_1_1?s=books&ie=UTF8&qid=1337457760&sr=1-1">Programming the Mobile Web</a> 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 |
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 |
|
BlackBerry Touch |
Browser |
|
|
|
|
|
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 |
These are devices I am testing now, and will put in the table in a little bit
Nokia Asha 300 (Remote Device Access) OS - Featurephone, S40 Browser - Nokia Browser Phone - No. No link appears. SMS - Sorta (3) Location - Yes, Browser Directions - No Email - Yes (4)
Nokia C3-00 (RDA) 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 (RDA) OS - Symbian Belle Browser - Web (NokiaBrowsers/8.2.1.20) Phone - No SMS - No Location - Yes, Browser Directions - No Email - ? Cannot tell as Nokia makes it SO hard to set up an email account. And, it refuses to just go there without full setup.
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:
- SMSTO actually supports sending the body link as well.
- Also supported the body, but I have yet to determine a format that doesn't munge the recipient number as well.
- 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.
- See note 3. Works, but user has to select Email again, vs. SMS.
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>
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.
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.
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&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&saddr=5600+russell+ave,+mission,+ks+66202&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.
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
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.
Other Resources
Maximiliano Firtman, who wrote <a href="http://www.amazon.com/Programming-Mobile-Web-Maximiliano-Firtman/dp/0596807783/ref=sr_1_1?s=books&ie=UTF8&qid=1337457760&sr=1-1">Programming the Mobile Web</a> has some articles about some of these from a few years ago.