I generally like mailto: links. But I feel like I can smell a mailto: link without even inspecting or clicking it, like some kind of incredibly useless superpower. I know that if I’ve got my default mail client set, clicking that link will do what I want it to do, and if I want, I can right-click and the browser will give me a “Copy email address” option to grab it cleanly.
That’s cool and all, but Adam Silver and Amy Hupe recently enumerated the problems with how these links behave:
Firstly, mailto links make it hard to copy the address, for example if you want to share the email address with someone else.
Secondly, some users use more than one mail app, and the link just uses whichever has been setup as the default, without giving them the option to use the other.
And finally, many users don’t have an email application set up, which means the link can take them to a dead end or down a rabbit hole.
Their UI experimentation ended up using a mailto: link, but putting the entire email address as the link which makes it especially obvious what the link does, while also offering a Copy button for a little UX bonus.
tel: links are weirder in the sense that a good many devices looking at them don’t have any phone-calling functionality. If they do, it’s a lot like email links in that multiple apps could do that work (e.g. WhatsApp, FaceTime, or the default phone app).
The hard part of the UX of all this is offering users choice on what they want these special link types to do. That’s what mailgo is attempting to solve. It’s a little JavaScript library that offers UI when you click them.
Live demo:
I kinda like it. I wouldn’t mind at all if that popped up when I clicked a link like this, especially since it has that “open default” option if I want that anyway. Seems to check all the boxes for the problems these types of special links can have.
Interesting. I wonder how that works with spamspan or is there some other way to block bots from grabbing the email address?
That’s great!
I can’t say I’m a fan of this approach. Generally a user has a default option for each of these links and would expect the link to open rather than a pop-up which would be annoying to deal with every time.
This is an issue that should be dealt with at a browser (or OS) level and I don’t think it is a good idea to override the default expected behavior. In the example above I’m asked both by the in browser popup and in the app picker on android what app I would like to use which is obviously not a great UX. Some options for apps I have installed also take me to the website instead which is obviously not what I want.
The issues described here are pretty much a non-issue as every platform I’ve ever used has an option to easily copy either the address or number directly or to copy the link which is then easy enough to manually edit.
I dunno. First of all, I don’t have Outlook. They shouldn’t assume anyone does. I’m reading it on an iPad, so all those options don’t make sense. I like the Copt part. Haven’t looked deeply at the code, but does it allow you to customize these?
While an interesting discussion about how browsers could or should work, just don’t do this. Please don’t try to replicate browser behaviour using JavaScript (and this is a general rule that should be stuck too in all situations). It never works well and always causes a wide range of problems either immediately or later.
Allowing the choice of what to do with a protocol link is the job of the user agent/browser or operating system and not the website designer. All that really happens in this example is that a user often gets two prompts when after selecting one of these links. The first is the JavaScript pop-up listing options that are not available, the second is the user agent/Operating System providing the real options.
Great idea, and nice and clean implementation. Seems strange that this type of feature has not been built into the browser natively on some form.
But then again, browser implementations tend to lack consistency or customisability. You’d have hoped that by 2020 we’d be able to move past using JS to fill in browser inconsistency and styling shortfall. The shadow DOM seemed so promising, but those date inputs are just almost beyond repair in some browsers.
I thin it needlessly breaks native implementation
if someone cares about mailto links they have their favorite client set up as default (unless they are Apple slaves, but it was their own decision), if they do not the native copy is still just a click away so adding extra pop-up is only slowing down, degrading the expected UX
I don’t like an idea of additional popups.
I don’t like an idea of having third party library (or additional bloat code) in your project just to solve a minor problem.
It’s users responsibility to configure their devices.
Worst case scenario: user can always copy data from one app, then open another app and use copied data there.
I might be wrong here.
That is awesome! Is it accessible, like keyboard and screenreader friendly?
I am [email protected]! Thank you so much for your article! Mailgo is available also as Chrome extension and Firefox addon. It is an Open Source project, I take this opportunity to ask anyone who wants to contribute or give suggestions for mailgo is welcome. Thank you again.