I have the same question. For me at least, the issue it is trying to solve doesn't exist. I can't see it existing for many other people either, at least not to the extent that they need something like this.
The advantage with the standard is that my phone proposes from itself what it would do when I click a "tel:" URL or "mailto:" URL. And what I do most is just long-press and copy to clipoard. As this uses the native UI from my mobile OS, this just feels better then a HTML-rendered custom UI.
This is one of the old and golden web rules: Don't surpise the user with some UI he would not expect. Be consistent to the standards.
One thing I would like on Desktop (maybe it exists and I'm missing it) is to have Chrome's context menu show "Copy Phone Number" like it shows "Copy Email Address" because copying the link includes the tel prefix and it's annoying to remove for some workflows.
At least in Firefox, multiple websites/apps can handle mailto links, and you're presented with a modal to pick from them when clicking on a mailto link.
The fact that many people don't have the handling for it configured, especially on desktop.
If you use a provider like gmail or hotmail, there's a chance they're not set up as your mailto link handler. So in that case, some random email client you have installed will open up and bug you with its first time setup wizard.
Best case, the user is annoyed but still manages to copy the address manually. Worst case, they conclude the link is broken and don't use it.
> If you use a provider like gmail or hotmail, there's a chance they're not set up as your mailto link handler.
so, they should set themself up. what drives someone into invent yet another tool which accomplish something on a much higher cost, which is other programms' responsibility and those could less painstakingly fix it.
Gmail is doing this currently, at least for me (might still be in an A/B stage). It'll pop up the browser permission to handle mail links, then chrome will open the Windows 10 "default apps" page of settings to get you to change the mail app to Chrome.
This is an old feature. But it requires Gmail asking for a permission or maybe clicking on a setting somewhere and that means most users will ignore it or simply dismiss it without understanding what it even is. These days there are so many popups with warnings all the time (cookies, tos, notifications) you can't blame the users for just dismissing them without even reading
I agree in principle and will use mailto: and tel: links on any project where I have the luxury of doing things properly without worrying about the consequences.
But at the same time it's not easy to explain to a client that their email link might not work for a sizable portion of their visitors, especially if they've seen solutions that work all the time.
I also agree about avoiding unnecessary bloat and this seems like a decent tradeoff. It's just a tiny popup that includes the native option, so you could argue it sits between a plain mailto: link and a full-on contact form with a backend service for sending emails/texts.
I do not use a native email client and I don’t make calls with my computer. This means those links are not useful, so I have to copy them and then enter them wherever suitable.
Demo is a pretty good user experience, but from my experience most people are used to the standard behaviour, and would rather copy email addresses than click hyperlinks...
The problem that most people these days use webmail, and most don't have mailto: configured to open their webmail client, so clicking on a mailto: link results in the Outlook application that you never use taking two minutes to open.
I think it's nifty, and I'll probably implement it on my personal site.
I think this is a good solution to a problem, but the demo doesn't illustrate the more annoying version of the problem:
If I click an email address I expect the mailto behaviour (and to a lesser extent with hyperlinked phone numbers) but often you'll see the case where the hyperlink text actually just says "Contact" or similar and it opening my email client is completely unexpected
that's a very western centric view. in asia most people don't even use/know email except some professionals. they would be overwhelmed with those choices. also country specific would be the defaults. like japan is used to yahoo, thailand used to Line messenger (nobody uses whatsapp here) etc.
That shouldn't be downvoted. That's a great point, even if most probably misinterpret. In Asia people really don't use email as primary comms in B2C or social for many things. People use LINE, WhatsApp, WeChat and other mail providers like qq or 163.
Still it's a 'mailto:' link which might not translate to those media. But a 'tel:' link could possibly translate to "Connect with LINE" or other options.
Anyway I think this project is a very good idea. These sort of protocol links are very useful, considering on mobile you are always app switching to share something. Unfortunately, mobile browsers don't support "navigator.registerProtocolHandler" but there might be workarounds for PWAs.
Thanks. I didn't mean to discredit the solution. I mean from my point of view it's great. I use mailto: and tel: all the time. But I work in South East Asia and East Asia in Web and Application analytics and the people here are very different. The medium used for communication, the platforms, the way it's being used, the devices are all very different. Just wanted to give another perspective on this, to broaden the minds of the creators.
Great! This sort of "interactive link" is polite and what I wish more websites would adopt instead of cluttering their site with fixed positioned widgets.
A good example is chat widget. Instead of using a fixed positioned chat widget that annoys your users (esp those on mobile), why not stick to good old "Contact Us" link that opens your chat widget only when it is clicked.
Would be better solved with a user-agent implementation I think. Let local apps and webmails advertise support for mailto links, make the user-agent display a dialog and let the user pick one.
We're almost there, the only issue is that there's no declarative way to advertise support for mailto links, webmails need to ask the user.
Let any website register a handler for mailto links.
Get the OS/browser to show a list of registered handlers when a mailto link is clicked.
Order the list by frequency of use so random websites you visited 5 years ago stay nicely below the actual one you want to use. Also maybe unregister or hide anything not visited for 30 days, so yo'd have to revisit the site to reregister it.
Doesn't Firefox do it already? I've just clicked on a mailto link and it asked me whether I'd like to go to gmail.com or to launch the external program... but then again, normally I don't ever click on mailto links, because I don't usually write e-mails anyway, and when I do, I just select and copy the e-mail address, then paste it into the "To:" field.
Firefox has an option for the application (or website) to open a mailto link with. It's lacking Outlook OWA though.
You can find in the preferences panel where all default 'open with' settings are
I hate to not be constructive here, but I don't have anything positive to say really. A 7kb dependency for a non-standard popup. Maybe if you shrunk the size down I'm sure some might find some use for it. But this is a lot to add, for so little.
and not only the size what does matter here. i bet whoever whats to use it, he must time to time update the code, because some weird software bacteria tends to rotten nowadays programms, so you can not just have written the simplest few lines of code to solve one unit of requirement. no. you must update and upgrade ad infinitum, creep the scope, refactor, add n×3 dependency for every n feature. each update brings 2 new backdoors, breaks interface, etc, but you're obligated to update because it's labelled "security update", obviously.
I think the ideal solution would be to automatically copy the email into clipboard on desktop and use a standard mailto link on mobile. On desktop, most people use some kind of webmail, on mobile they have an app installed. Yes you can configure your browsers to open mailto links with a webmail, but almost no one does that.
I don't have any numbers, however there's a tool called hunter which finds relevant email addresses for websites, and it uses copy to clipboard rather then mailto. If even most people who know about and use such a tool don't have mailto configured, probably almost no one has.
I don't know what prompt your talking about. Maybe an uncommon browser feature?
I find the spam-less version interesting, the risk of spam is a reason in itself to not use mailto or tel links on your public pages, which is a sad in itself.
62 comments
[ 4.0 ms ] story [ 128 ms ] threadThe advantage with the standard is that my phone proposes from itself what it would do when I click a "tel:" URL or "mailto:" URL. And what I do most is just long-press and copy to clipoard. As this uses the native UI from my mobile OS, this just feels better then a HTML-rendered custom UI.
This is one of the old and golden web rules: Don't surpise the user with some UI he would not expect. Be consistent to the standards.
If you use a provider like gmail or hotmail, there's a chance they're not set up as your mailto link handler. So in that case, some random email client you have installed will open up and bug you with its first time setup wizard.
Best case, the user is annoyed but still manages to copy the address manually. Worst case, they conclude the link is broken and don't use it.
so, they should set themself up. what drives someone into invent yet another tool which accomplish something on a much higher cost, which is other programms' responsibility and those could less painstakingly fix it.
But at the same time it's not easy to explain to a client that their email link might not work for a sizable portion of their visitors, especially if they've seen solutions that work all the time.
I also agree about avoiding unnecessary bloat and this seems like a decent tradeoff. It's just a tiny popup that includes the native option, so you could argue it sits between a plain mailto: link and a full-on contact form with a backend service for sending emails/texts.
https://codepen.io/manzinello/pen/RmeQEr
Is it just me or are others facing the same problem?
I think it's nifty, and I'll probably implement it on my personal site.
If I click an email address I expect the mailto behaviour (and to a lesser extent with hyperlinked phone numbers) but often you'll see the case where the hyperlink text actually just says "Contact" or similar and it opening my email client is completely unexpected
Still it's a 'mailto:' link which might not translate to those media. But a 'tel:' link could possibly translate to "Connect with LINE" or other options.
Anyway I think this project is a very good idea. These sort of protocol links are very useful, considering on mobile you are always app switching to share something. Unfortunately, mobile browsers don't support "navigator.registerProtocolHandler" but there might be workarounds for PWAs.
A good example is chat widget. Instead of using a fixed positioned chat widget that annoys your users (esp those on mobile), why not stick to good old "Contact Us" link that opens your chat widget only when it is clicked.
We're almost there, the only issue is that there's no declarative way to advertise support for mailto links, webmails need to ask the user.
What's the alternative? You can't let any website register a handler for mailto without asking the user
Get the OS/browser to show a list of registered handlers when a mailto link is clicked.
Order the list by frequency of use so random websites you visited 5 years ago stay nicely below the actual one you want to use. Also maybe unregister or hide anything not visited for 30 days, so yo'd have to revisit the site to reregister it.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/r...
Numbers? I always clicked "yes" to that prompt when I was using GMail as my client. Maybe I'm weird?
I don't know what prompt your talking about. Maybe an uncommon browser feature?
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/s...
NB support is somewhat limited:
https://caniuse.com/web-share