tel:me.about.it.
Let’s talk about protocols. I’ve been repeating most of what is in this post in conversations for a while now, so I thought I should write it down. They are thoughts around what it means to add new protocols to the platform, and how we go about it in practice. The main extensibility mechanism that we have comes from the HTML5 era: registerProtocolHandler(). In this post I’ll explain where I think that’s kind of OK, where it falls (sometimes very) short, and some things I think we learned along the way. The purpose of this post isn’t to make suggestions, it’s simply to have a look at the space and the things I think we need to keep in mind.
Most of the URLs we type these days begin with https: - or before that, http:. We changed the main protocol of the web to be more secure. It’s not inconceivable we could want to have that level of change again, but there are plenty of things short of that where protocols develop and somehow find their way into the platform.
A few popular examples from the HTTPArchive data: Over 30% of websites include at least one mailto: link. Almost as many sites include a tel: link. There’s plenty of webcal: and fax:. geo: is used on over 20,300 sites. sms: is used on 42,600+ websites. These are just a few examples of protocols that are trying to do something useful.
Things That Go “Click”
When you click a link that has one of those protocol identifiers, the browser says “Do I know how to handle that protocol?” If the answer is no, it passes responsibility along to the OS. So, if you have Skype installed, and click on a skype: link, the OS might launch Skype for you.
Protocol handlers really are just built on the idea that over time, we build web-based services and it should be possible to say that the way to handle them can be by rerouting handling to a domain (say, gmail.com for mailto: links).
So, for those, things it works… Kind of.
The mistakes we made along the way…
On the surface, all of those protocols that turn up in the HTTP Archive data seem like success stories. However, I’d like to tell you why they haven’t been so great, and why we already have better solutions.
Consider the second most widely used of those, the tel: protocol. Not because this one is especially bad, but because it is very easy to illustrate many problems in a concise example.
Before tel:, authors would put some text in their web page, like:
Phone: (555)123-4567
With tel:, authors could now put something like this into their HTML:
<a href="tel:123.456.7890">Call now</a>
Yay! Except, no… wait… That is kind of terrible.
Sure, for some users, where all of the stars align, that will be a nice convenience. But there are just way too many cases where this is more of a barrier than a convenience. Let’s look at some of the failure modes of that line of code, starting with the simplest:
Hidden information
Because we’ve made it a link, it’s far too common that authors don’t actually display the phone number. They assume that the device I’m looking at is the device I want to dial from. There are many cases where that is not true!
Perhaps I’m on my office desktop and I want to dial with the handy office phone that is next to me, or the conference system, or even just my cell phone. Maybe I want to read the number out to someone else, or write it down for later. Just show me the !@$!@ number!
This isn’t a problem inherent to the protocol, but it’s still a problem.
Theoretically capable, practically incapable
Sometimes a device can be physically capable of dialing out, but currently not have that service available. This happened to me while traveling abroad in 2018, where I was able to use my cell with WiFi but couldn’t dial out (I didn’t have WiFi calling at the time).
This problem still comes up I use that same 2018 cell phone to control my media in my house, and occasionally to look something up, but since it isn’t on my cell plan, I can’t use any tel: links.
No registered handler at all
On some machines, there is no registered tel: protocol handler. What happens in this case? Unspecified. Each OS will do something a little different. For years tel: would often do nothing at all which is very confusing to users. Some operating systems will, to various degrees, offer to help you find something capable of handling the protocol, but even that can be confusing (see next point).
Registered a Complex Program
Some devices will launch a program that’s registered to handle the tel: protocol, even if it can’t currently dial. There are many examples of this. Apps like Google Hangouts or Skype were chat programs with some VoIP support. They could dial out if users paid a special recurring fee – but most users didn’t pay that fee. When those users clicked a link and it launched their chat program, or told them they have to pay to dial, that’s confusing and frustrating.
In fact, lots of users of those apps just use them for text chat. Not so long ago, many users on office desktops didn’t have cameras, mics or speakers. If users clicked a tel: link and it launched their chat program and implied that they could pay money to dial out, but actually couldn’t do that: This is very confusing to users.
The Un-Protocol…
Contrast that with this: Today, if you use your smartphone and you select some text - regular text - there are some built in ways to assist in order to do smart selection. That is, work has gone into making it easier for it to recognize that you’re trying to select a phone number or an email, as two examples. And if you select it, the context menu will offer “Call” or “Email”, respectively.
You know what’s wild? No author had to do anything special at all, and it works even on content written in the 90s. That’s… Pretty great. That’s not to say markup couldn’t help here, but it gets at whether it needs to fundamentally be a link.
The Web Share API splits things along a similar joint. It just shares an intent to share some content. It doesn’t need to know anything about which ways you have to available to share, or reason about things in the current time. Splitting things this way lets all of the ways to share develop entirely independently. If new social media comes along, or goes away, or we develop new physical ways of sharing involving USB or Bluetooth or HandWaveyMagicWand - it will all JustWork™.
Both of these seem to me generally better than many of the protocol based solutions. I’m not suggesting protocol based solutions are useless, I’m just suggesting that it seems like there is benefit in continuing to question why and how we’re approaching things.