Sweating the UI and UX details: Emails and Email Addresses | Hacker News Reader

Sweating the UI and UX details: Emails and Email Addresses

blog.close.io

94 pointsSteliE62 comments

> “John Smith” <john@example.com>

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.

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.

Curse you off-by-one errors!

When you copy from outlook, it copies that unless you first double click on the contact then select just the email address.

This is standard behavior for Outlook.

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:

defaults write com.apple.mail AddressesIncludeNameOnPasteboard -bool false

That works perfectly. Thanks!

This is most useful thing i've learned all week. Thanks.

Can't thank you enough for this.

Can't blame Apple enough for making this a hidden default one has to use the terminal to enable. WHY ?

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.

Lotus Notes :(

Newsworthy? So they decided to copy how Gmail's contacts form has been working for the last 4 years? Brainwave!

In GMail it's very easy to get a string like that, and it has the added benefit of giving you name and address together in a single copy-paste.

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.)

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.

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.

We've experimented with this concept for our Chrome extension, but I think it's worth exploring more.

http://blog.close.io/post/46905541008/the-close-io-lead-clip...

https://chrome.google.com/webstore/detail/closeio/cmhcoonbgf...

It's called entity extraction, and it's not very easy.

https://en.wikipedia.org/wiki/Named-entity_recognition

This seems to be a product for it: http://www.alchemyapi.com/api/entity/proc.html

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.

We already do #1, but #2 is a good suggestion, thanks!

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.

If you want to make international phone number entry work better, I've spent quite a bit of time thinking about that recently.

I've created a draft proposal you're more than welcome to follow up on at https://github.com/mtrimpe/jInternationalPhone

Interesting... looks promising. Using this would be tough while we share phone/email/urls fields though.

Hey - could you guys open source that "extract email from crappy Outlook string" code? I would love to use it in my own app.

You want them to open-source a regexp?

Sure - a basic version isn't super complicated or anything, but there are a lot of edge cases for various email clients, weird names, etc

We're using this library: https://github.com/andris9/addressparser

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.

Thanks - I'll check out that library. I assume you guys use https://github.com/Kicksend/mailcheck also?

Not sure what language you use, but it almost definitely supports PCRE. For email addresses, I always use this regex:

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>" 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.

Seriously?

> 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.

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

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.

> Landline and Mobile phone numbers are differentiatable,

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.

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

I really enjoy how metadata enriches actual data.

Direct link: http://www.access-paradies.de/download/pool/vorwahlen_deutsc...

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.

More details: http://stackoverflow.com/questions/744227/web-based-api-that...

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 ;-))

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.

> 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.

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...

> 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"

Keep in mind you want to avoid premature optimization of both the back end and the front end.

This is a great tip for a validated concept, but at the MVP stage, I wouldn't consider it priorty #1.

So you're saying that MVPs should be of mediocre quality?

MVPs should be the absolute bare minimum.

If you're starting a grass cutting business, don't go buy a pickup truck, a trailer, and 3 of those orange ride/stand-on mowers.

Get a spreadsheet out and start signing up your customers.

Is that mediocre quality? No. It's not prematurely optimizing for something that may never happen.

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 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.

Yes. They should be of minimally-viable quality. It needs to be stable enough and featureful enough to be useful. That's all.

Exactly. The clue is in the name :)

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.

Nice integration of Tumblr. Same header, same design.

Very nice. I think this could work for mobile as well. Select an input box, and have a tab for email, phone, or URL keyboards/pads.

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...

What is the specific problem with the top bar? It goes away for small window sizes.

Middlebrow dismissal at its finest. Which is a shame, the article actually has some nice little usability ideas if you could get over yourself.

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?

Reply on news.ycombinator.com