Well it's the standard format for displaying both the user's name & email address together (and part of the SMTP spec). But yeah - typically you just want the real address part.
In Gmail at least you can get what you want with some careful highlighting - but Apple Mail doesn't let you copy that portion at all. Hence this feature :)
I'm going to go ahead and be pedantic: that format is not part of the SMTP spec. It's part of the Internet Message Format RFC (5322 in its latest incarnation), which describes what's in the body of the email.
The SMTP spec (RFC 5321) which describes what goes on the wire between an SMTP client and an SMTP server uses addresses in a '<to@example.com>' format.
Me neither. OS X Mail has a hidden option that you can enable, so that Mail copies just the email address. Copy this into your Terminal and restart Mail:
If only copy+paste worked with structured data, rather than just plain text, we'd have this behaviour everywhere. Sure, it's not a trivial problem, but there must be something possible along these lines.
Possibly tangential, but you can copy and paste and get different results based on context (eg. copy image file, paste into HTML doc, get image tag; paste into terminal, get path; paste into mail client, get attachment; paste into image editor, get the image itself). It definitely works in OSX, but IIRC it's supported in Windows too.
I last tried this around 18 months ago, in a Firefox extension. Was a bit fiddly but I could do what I wanted.
It works on virtually all desktop systems (Linux, OSX, Windows) and has for a good long time, it's just a matter of whether or not the application has implemented support for it.
You're more limited in what you can do in a web application though.
Is there any particular reason you don't just have a multiline text box, and allow anything to be entered/pasted, and then just figure it out? Why should a human have to parse out bits of contact information and separately add each one to your form? (Your computers have billions of cpu cycles, bytes of memory and storage - surely they can do it.)
Is that a common scenario? I am mostly moving single pieces of information rather than entire blocks of text like you're proposing.
If we take your specific example, how would a computer even with "billions of cpu cycles" figure out which piece of information is someone's name and which is their job title? Or which is an address Vs. job title?
Sorting data and understanding it is a "hard problem" and relatively speaking computing power plays a very small part of that. What plays a much larger part is just having MASSIVE databases of already sorted data to compare against (e.g. Siri).
> Is that a common scenario? I am mostly moving single pieces of information rather than entire blocks of text like you're proposing.
You most likely have the information as a single block especially if copying it from somewhere else. And it is certainly far easier if the user has to do one copy and paste versus once per field.
In this particular case they have a user sitting there so the answer doesn't have to be perfect every time - they just have to make sure that if the heuristics mess up that it can be corrected (eg let the user drag and drop elements into the right arrangement/field names).
> Or which is an address Vs. job title?
The former is likely to occur in a geocoding database and the latter isn't.
close.io focusses on sales so that immediately narrows down the likely possibilities for contact information. I'd be pretty sure naive code would have an 80% success rate, and analytics plus ongoing development would ensure ever improving success rates.
I don't use close.io, but here's what I'd also recommend if you haven't done them already:
1) allow the user to enter their phone numbers in whatever format they want: 4081231234, (408)123-1234, 408-123-1234 and format it after they click 'save' to (408)123-1234 or however you want it.
2)Cache the domain of the email address for autocomplete suggestions if they enter a website. For example, if you type in phil@close.io for the email, I can already suggest http://close.io if you start typing in a website address.
Bikeshedding on #2, set up a blacklist of very obvious non-business domains. Very few people with @gmail.com or @hotmail.com actually own the business on that domain.
I've yet to run into a problem with it. If you want to extract an address from a larger string, then you need to slightly modify the regex to capture the email address from the string. This is going to depend somewhat on the language you're using, but probably involves wrapping everything between the first \b and the last \b in parentheses.
I guess if I were certain that the target text was a "<name>" user@domain.com style string, I probably wouldn't use a regex (unnecessary overhead) and just split on > and trim or something silly like that.
But we're using it for more than just this scenario. If you're just concerned with this specific case you could come up with a simpler/shorter solution.
> We already know your email address when you signed up, and we use our own Mailgun account to send email as/from you, so that it just works.
Hmm, isn't this asking for trouble? Having the emails you send put in spam queues, or eventually having your MTA IP address blacklisted even. When you're sending out emails from @somewhere.tld, even though you aren't in control of somewhere.tld or it's MX server, and sending out multiple emails from the same mail server.
The number of messages we allow per day for accounts without their own SMTP credentials is very low. But yes, this is something we need to keep an eye on.
On mobile I've become used to phone/email specific keyboards when filling out forms. This idea wouldn't easily allow for that. Then again not enough websites use the input type feature yet anyway, so this is still an interesting improvement.
If you're at it, why not auto-detect the type of information?
Landline and Mobile phone numbers are differentiatable, email address and website url are differntiatable too. I would even go so far and add an auto-import feature LinkedIn/Facebook/Google, that searches for the contact's "name(+address)" online and returns the "possible" results into the right fields automatically into your database. ;)
@close.io team I don't use SaaS services except GitHub regularly, but if you would sell license your applicatoin I would buy a copy. I believe this is a good strategy when you've already a "satisfieable" amount of customers. But your mileage may vary.
wow, I hoped, but didn't expect that someone actually listens to my tiny voice in the vacuum of the great Interspace. :)
I honestly do highly appreciate that, it's a really great move by you and I'm grateful that you care about perfecting your product :)
Most companies think they cannot afford listening to their users, those who do earn my deep respect.
Btw. I'm from Germany and "mobile phones" can be differentiated easily here. Not only that, you'll even know which network the other number is signed up with.
D1 T-Mobile: 0151x, 0160, 0170, 0171, 0175
D2 Vodafone: 0152x, 0162, 0172, 0173, 0174
E-Plus: 0157x, 0163, 0177, 0178
O2: 0159x*, 0176, 0179
Locating positions of landlines phone numbers is even easier, because there are databases. The picture in the german wikipedia article explains how the association with a location works (no need to read the entire article). http://de.wikipedia.org/wiki/Telefonvorwahl But here you can get a free Database containing all landline numbers: http://www.vorwahl-nummern.de/vorwahlen/download.php
In the US, thankfully, pro-consumer laws require telcos and wireless carriers to let you take your number. With some restrictions, a number from anything can end up on anything.
So no, not possible to detect using rules. It is possible using a telco routing lookup.
You cannot know the carrier because you can keep your number when changing them. I'm with Vodafone and have a 0176 dialing code carried over from my previous contract. But as others pointed out, in the US mobile numbers get normal landline dialing codes so you cannot see a difference.
So, in a way, yes, it's possible for some customers to automatically detect that, but then you need to question how many of them come from countries where there is a difference and whether it's really a good use of your time and money to implement something that might only benefit a percent of your users. As for me, even though I'm conscious of UX, I wouldn't care much if I had to classify my phone number once. What they described in the article already goes way beyond what most other signup forms do.
(Fun fact regarding area codes and figuring out a city from that: The village I lived in previously was pretty much halfway between two smaller cities and it had the area code from one but administratively belonged to the other. So not even that is easy ;-))
Landline and Mobile phone numbers are differentiatable
They aren't. At least not consistently- the UK (where I suspect you might be given you use of "mobile phone") prefixes them all with 07, but in the US and Canada there is no such difference.
Have you A/B tested the "phone/email in any field" feature and found it results in easier data entry than telling people where to enter that information? I ask as it goes against the principle where giving people less choice can sometimes result in increased conversions. Here, you are asking users to make a choice (albeit, a tiny one) where to enter the information rather than having it consistent every time.
Was there clear data which prompted you to implement this format? If so, I'd love to see the testing methodology.
One suggestion, you have track feature for imap clients, but that will only track emails from people in your contacts list. If you built a list of all the sent/received email addresses and added autocomplete to your input it would help.
So I email person@example.com then go to close.io and start to add them to my contacts. As soon as I type per... the autosugest expands to the full email, and of course fills in the name too.
> Unless your domain is setup to use strict SPF and then this will fail randomly
Sure - but most people don't have this, and the goal is to get people to put in their SMTP credentials at some point anyway. Just doesn't have to be in their very first email.
> And do people really give their IMAP credentials to a web app?
Yep. We take security seriously and only end up tracking emails that match up with sales/leads in Close.io. For an entire company, their CRM data is often more important than an individual's inbox anyways - and we want to reduce the data entry necessary in common sales processes.
I wonder if you could do some kind of NLP-based input for contacts. Sort of like what Fantastical/Google Calendar do, maybe with some Graph Search-esque autocomplete to "teach" you the syntax?
Along the lines of entering "Phil Freo, Director of Engineering, office phil@close.io, mobile 650-555-1234"
We're beyond the MVP stage... and I think when you're competing with well established players in a big space your best option is to compete on product quality rather than marketing, cost, etc.
It's also worth noting that this is a form that can get filled out dozens of times a day by many of our users. It's not some obscure settings page.
I think an MVP has got to be as few "features" as you can get away with -- but each feature has got to be as HIGH QUALITY as you can make it, to stand out from the crowd. It's not year 2000, or even year 2010 anymore -- you probably have competitors, you need to differentiate somehow.
Don't buy a pickup truck, a trailer, and 3 of those orange ride/stand-on mowers -- but the ONE mower you buy, make it the BEST DAMN MOWER you can afford, well-thought out best for precisely the kind of mowing jobs you plan to focus on. (And this is only a great analogy to software if your customer is going to be actually USING your mower themselves!)
If your value proposition is "I've got a better mower", sure. If not, work on your value proposition, the rest is fluff. Unless close.io's business model is "allowing you to enter information easily" (it might be, I don't know what they do), they shouldn't bother with it for the MVP.
If you are in a crowded space, UX differentiation is a feature. In the case of close.io, they are competing against well entrenched market leaders. Making a high quality, easy to use sales communication tool is their MVP.
I have a very hard time taking any UI advice from a web-site which puts a static bar at the top of the page which you cannot remove. It is like being sent back in time to iFrames and makes using your page with a vertical device horrifying.
I actually used the Chrome developer bar to Display: none it away. I guess that is the way you expect your users to use your site? Remove annoying counter-intuitive UI elements by eliminating them...
Let me see if I can get the same tone as your comment: I have a hard time taking any complaint about vertical devices seriously when the page content is responsive and the bar is not static at lower resolutions. Perhaps rotate your monitor the other way if the loss of 69 pixels is causing you such heartburn?
Why would email clients copy a string like this? In my entire history of email copying and pasting, I don't think I've ever wanted that text.