The key to making icons of communication applications actually work on a website, and open communications (whether text, voice, or video) are special kinds of URLs that launch those applications. This post is third in a series.
By simply expanding "URL" beyond Uniform Resource Locator to also mean Uniform Resource Launcher, we refer to these special URLs inclusively without a new TLA. No matter how tempting it may be to introduce new terminology or cute new abbreviations, better to avoid the errors of "URI" and "IRI" whose introduction caused more confusion than usefulness.
From the mockups:
In the order presented from left to right, top to bottom, here are example URLs for each of the icons, with expected actions, test results notes from iOS & Android, and links to more info:
sms:user@example.com
Action:
Start a new txt message to user@example.com
iOS:
It opens the "Messages" SMS/texting app directly into a message to the AppleID user@example.com (and existing conversation if any). You don't need a phone number to text. Note: avoid using ?body=hello, as that causes iOS not recognize the address.
Android:
It opens the SMS app with a new message, which the app then sends as email through the provider (e.g. T-Mobile's tmomail.net).
More info:
Wikipedia URI scheme sms
fb-messenger://user-thread/4
Action:
Start (resume) a Facebook Messenger conversation with FB user id 4, which is Zuck's. Find yours at graph.facebook.com/username
iOS &
Android:
If the Facebook Messenger app is installed, it opens with a new message window e with to: prefilled, message input box selected.
More info:
Stack Overflow: Facebook URL scheme to post a new message
gtalk:chat?jid=user@example.com
Action:
Start (resume) a Gtalk conversation with user@example.com
iOS &
Android:
Failure even with Google's "Hangouts" app installed. "address is invalid" and "can't load page" errors, respectively. It appears Hangouts does not handle "gtalk:" URLs, which, as the replacement for Google Talk, it should. I've reported bugs to folks at Google. Avoid "gtalk:" URLs until they're fixed.
More info:
Wikipedia URI scheme gtalk
aim:goim?screenname=tantekc
Action:
Start (resume) an AIM conversation with AIM user tantekc
iOS &
Android:
If the AIM app is installed, it's opened as expected. If not, the browsers give an unfriendly error like "address is invalid" or "can't load page".
More info:
Wikipedia AOL IM URI scheme
skype:echo123?call
Action:
Start a Skype call with Skype user echo123
iOS &
Android:
A skype call is immediately initiated without prompting, if the Skype app is installed. If not, the browsers give an unfriendly error like "address is invalid" or "can't load page".
More info:
Wikipedia URI scheme skype
https://mobile.twitter.com/t/messages
Action:
View conversation, start a new direct message to Twitter user @t
All platforms:
The browser will simply navigate directly to a new Twitter direct message page, if the user is logged in. If not, Twitter will first redirect to a login page.
More info:
None. I discovered this URL for directly creating Twitter direct messages with my own iPod experiments.
facetime:user@example.com
Action:
Start a FaceTime call with user@example.com
iOS:
Presents a dialog
that requires the user click/tap the "FaceTime" button/link to initiate the call.
Android:
No support for FaceTime. Error: "can't load page". Thus this link should be hidden from non-iOS users (since mobile comms are the goal, it's ok to hide it from MacOS users too)
More info:
Wikipedia URI scheme facetime
And that's it for the communication applications in the mockup. However, there are some variants of those URL schemes worth considering.
URL Scheme Options
There are a couple of options for the above URL schemes, e.g. Gtalk can be used for making calls (instead of just instant messaging), and Skype can be used for instant messaging (instead of just calls):
gtalk:call?jid=user@example.com
Action:
It should initiate a GTalk call.
iOS &
Android:
Again, even with Google's "Hangouts" app installed, it fails to register to handle the gtalk: URL scheme. And again the same errors: "address is invalid" or "can't load page". Same conclusion: avoid gtalk: URLs for now.
More info:
Wikipedia URI scheme gtalk
skype:echo123?chat
Action:
Starts a Skype chat with user echo123.
iOS &
Android:
A skype chat is started if the Skype app is installed. If not, the browsers give an unfriendly error like "address is invalid" or "can't load page".
More info:
Wikipedia URI scheme skype
While the Gtalk variant is not immediately useful, the Skype chat option could be useful during:
Default sleeping hours. You could configure your server with your default sleeping / do not disturb hours and have it use the "chat" option during those times.
Event busy times. Your server could automatically check your online calendar and use the "chat" instead of "call" option when your calendar indicates that you're busy and/or in a meeting.
Do Not Disturb. A more advanced option would be to have your mobile device's "Do Not Disturb" action automatically notify your server, and have it switch from "call" to "chat" accordingly, until switched off or perhaps your next waking time.
These same contexts could also be used to conditionally show or hide a FaceTime: URL (in addition to showing them only for iOS browsers).
20th Century Schemes
There's also tel:18008765309, fax:18008765309, and mailto:fail@example.com URLs for phone calls, faxes, and email. However:
Pricey phone carriers. Though providers in many countries offer free or nearly free domestic calls, international and roaming calls tend to be pricey. International SMS to actual phone numbers is also often costly as well (when it even works!), sometimes between carriers in the same country!
Fax machines maybe ... for businesses. I don't know any individuals with phone numbers set up to receive faxes. Perhaps there is an underground network of hipsters with fax machines and landlines, and they're just too obscure for me to have heard of them.
Email Efail. Email, beyond the unnecessary cognitive load of subject plus message body, encourages excessively long messages and has numerous other problems. Better to avoid it for personal communications, and use it for working hour (not personal) communications.
Thus I discourage using these, but they're there if you're feeling nostalgic for 20th century communication tools, services, and regulated national oligopolies.
What About WebRTC?
WebRTC is perhaps the biggest absence from this list of communication methods, and unfortunately that's because despite the interoperability at the API level, at a high level, WebRTC does not have a simple URL solution unlike the others above. There is no "webrtc://" URL scheme with parameters that will automatically open a WebRTC call to your mobile device. WebRTC needs a simple URL scheme like that to "just work" like the alternatives above - without needing any script. Robert O'Callahan blogged some thoughts on WebRTC and I look forward to seeing this figured out.
What About FirefoxOS and others?
Lastly, I haven't yet had a chance to see how well these URLs could work on FirefoxOS (unknown schemes appear to do nothing in the browser), nor found applications that explicitly register support for Web Activities
for those URLs.
For now, try experimenting with the URLs in the above list on your own devices, operating systems, and browsers, and report your own results.
Thanks to help from:
Ryan Barrett for Android testing
Kevin Marks & Bret Comnes for iOS Safari testing
Aaron Parecki for iOS Chrome testing.
If you have different results or results for additional platforms, let me know!
Next Steps
The next building block will be figuring out minimal semantic markup for representing these communication actions.
However, as is often the case when figuring out the individual pieces of a problem, the analysis of these URL building blocks has revealed at least one or two more to figure out:
iOS client detection - for conditional FaceTime links at a minimum. Perhaps just minimal client platform detection for platform dependent URL schemes in general.
Contextual tests - a potentially open ended set of building blocks, for time of day, calendar busy checks, client "Do Not Disturb" notifications, etc.
I've added these to the building blocks post accordingly.