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 :)
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.
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).
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 [email protected] for the email, I can already suggest http://close.io if you start typing in a website address.
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>" [email protected] 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.
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 [email protected] 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 [email protected], 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 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?
[+] [-] jkubicek|13 years ago|reply
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.
[+] [-] philfreo|13 years ago|reply
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 :)
[+] [-] jeffclark|13 years ago|reply
defaults write com.apple.mail AddressesIncludeNameOnPasteboard -bool false
[+] [-] timjahn|13 years ago|reply
[+] [-] joeblossom|13 years ago|reply
[+] [-] mseebach|13 years ago|reply
[+] [-] oneeyedpigeon|13 years ago|reply
[+] [-] positr0n|13 years ago|reply
[+] [-] twistedpair|13 years ago|reply
[+] [-] rogerbinns|13 years ago|reply
For example I should be able to paste in any block from this page http://www.oracle.com/us/corporate/press/publicrelationscont... and have it figure out names, email addresses, phone numbers etc.
[+] [-] mseebach|13 years ago|reply
https://en.wikipedia.org/wiki/Named-entity_recognition
This seems to be a product for it: http://www.alchemyapi.com/api/entity/proc.html
[+] [-] UnoriginalGuy|13 years ago|reply
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).
[+] [-] philfreo|13 years ago|reply
http://blog.close.io/post/46905541008/the-close-io-lead-clip...
https://chrome.google.com/webstore/detail/closeio/cmhcoonbgf...
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] maddddddddddddd|13 years ago|reply
[deleted]
[+] [-] iamjonlee|13 years ago|reply
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 [email protected] for the email, I can already suggest http://close.io if you start typing in a website address.
[+] [-] philfreo|13 years ago|reply
[+] [-] swanson|13 years ago|reply
[+] [-] jontas|13 years ago|reply
http://www.regular-expressions.info/email.html
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>" [email protected] style string, I probably wouldn't use a regex (unnecessary overhead) and just split on > and trim or something silly like that.
[+] [-] philfreo|13 years ago|reply
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.
[+] [-] oneeyedpigeon|13 years ago|reply
[+] [-] huhtenberg|13 years ago|reply
[+] [-] jrochkind1|13 years ago|reply
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.
These days, sending email while remaining in the good graces of all the ISPs receiving email is awfully hard. cf http://sendgrid.com/docs/User_Guide/warming_up.html
[+] [-] philfreo|13 years ago|reply
[+] [-] nhm|13 years ago|reply
[+] [-] X4|13 years ago|reply
@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.
[+] [-] philfreo|13 years ago|reply
I'm not sure about this in a world with number portability.
> email address and website url are differntiatable too
Yep, we do this already.
> auto-import feature LinkedIn/Facebook/Google, that searches for the contact's
We'd like to pull in social data. It's not trivial, though services like FullContact.com can help.
[+] [-] untog|13 years ago|reply
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.
[+] [-] biot|13 years ago|reply
Was there clear data which prompted you to implement this format? If so, I'd love to see the testing methodology.
[+] [-] hnriot|13 years ago|reply
So I email [email protected] 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.
[+] [-] __david__|13 years ago|reply
Unless your domain is setup to use strict SPF and then this will fail randomly (depending on if the recipient checks SPF or not).
And do people really give their IMAP credentials to a web app?? I would never dream of doing that. That's the keys to the kingdom, right there...
[+] [-] philfreo|13 years ago|reply
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.
[+] [-] 10char|13 years ago|reply
Along the lines of entering "Phil Freo, Director of Engineering, office [email protected], mobile 650-555-1234"
[+] [-] hayksaakian|13 years ago|reply
This is a great tip for a validated concept, but at the MVP stage, I wouldn't consider it priorty #1.
[+] [-] philfreo|13 years ago|reply
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.
[+] [-] skrebbel|13 years ago|reply
[+] [-] JimWestergren|13 years ago|reply
[+] [-] weixiyen|13 years ago|reply
[+] [-] UnoriginalGuy|13 years ago|reply
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...
[+] [-] awj|13 years ago|reply
[+] [-] thomas-st|13 years ago|reply
[+] [-] bryne|13 years ago|reply