Oddly, I had this expectation confounded just today, when Birkbeck’s submissions system didn’t send me any confirmations about the pieces that I submitted for assessment. ↩︎
And probably plenty of other mail clients. ↩︎
I just got an invite/reminder email about a service called OnMail. I must have signed up to be notified when it became available. Could have been months ago: they apologise for it taking so long.
They should apologise for being bad for the email infrastructure that binds the world together.
I’m exaggerating, but only a bit. Email remains the most important thing on the internet aside from the web. Whenever you sign up for a service, or order something online, you expect to get an email confirmation.1
Without reliable email, a lot of things would fall apart.
A while back I wrote about Hey, the new email service from Basecamp. There, I was bothered by it not being based on the standard, open protocols that underlie email, at least to the extent that you can’t get your Hey email using a third-party, standard client.
OnMail seems both visually and functionally similar to Hey, and it’s got exactly the same problem.
This trend is bad for email, bad for people who use email. It should be possible to give us the kind of powerful, automated controls over our inboxes that these services offer, without stopping us from using the apps we prefer. It is possible to do that, as companies like SaneBox show.
I do not like this trend.
This has been sitting around in my drafts folder for about a month, so it’s long past time to get it out there.
HEY (they always capitalise it, which I don’t care for) is a new email service from Basecamp, makers of fine (I’m told) collaboration software for teams. The video walkthrough lasts about half an hour, but/and gives you a good overview of what it’s like.
Hey was also in the news recently over the way Apple was treating it regarding App Store rules. Apple were clearly in the wrong, and things have been sorted out now.
But that’s all another story. I want to talk about Hey, and why I think it is bad for users. Even at the same time that it’s probably good for users. A company, a service, can — like a person — contain multitudes.
If you watch that video you’ll see that Hey looks like an unusually interesting and capable email client: good for organising mail, getting the unimportant stuff out of your way until you want to look at it, and making the important things highly visible. It’s both powerful at automatically helping the user, and attractive to look at.
But it’s built on a proprietary platform. Email’s biggest strength since its invention has been that it was built on open standards. Whether you were using a Unix command-line client at a university in the early days, or Gmail, Outlook, or another IMAP provider today — none of that matters. If you know someone’s email address, you can contact them, and they you. And more importantly for this discussion: if you want to use different email client software, you can.
That’s because email is built on open protocols: SMTP, POP, and IMAP. Not that you have to understand those – or even know about them – to use email, any more than you have to understand an internal combustion engine to drive a car.
More importantly, if you want to change from one email provider to another, you can do so. This is harder than it should be because the culture of people having their own domain never really caught on. All those
email@example.com type of addresses could, instead, have been
They still could be, in fact. And when they are, then you can change the underlying email provider without anyone other than yourself having to know or care. To take a not-made-up example,
firstname.lastname@example.org used to go by a complex combination of Gmail (for the spam filtering and search) and
5quidhost.co.uk and its eventual purchaser, TSOHost, because that’s what I used for web hosting, as much as anything else. But a few years ago I switched it to Fastmail. No-one I correspond with had to know anything about the change.
But Hey’s email service does not use the open protocols — principally IMAP — that makes all that possible. Instead they have their own proprietary system. If you move your email into Hey’s service, you might not find it too easy to move it out again.
Secondly, right now they don’t support custom domains, so your correspondents will certainly have to know. While
email@example.com might be available right now, if they have any success we’ll soon be back to appending birth years or random numbers to the end of common names, just like on Gmail, Hotmail, etc. Though they have said they intend to support custom domains, so there’s scope for a better solution there.
Andrew Canion had the same thought I did when I watched the video: you can do most of this in MailMate.1 At least the viewing, the ‘The Feed’ kind of thing. Though he had the added experience of using SaneBox to automatically file and sort your emails.
I had heard of SaneBox through its sponsoring of various podcasts, so I was familiar with the idea, but I hadn’t tried it. I’m now trying it out, along with some of Andrew’s suggestions, and it’s altogether a pretty good setup. Now, all that comes into my main inbox — the only things that appear on unread counts, and hence activate icon badges — are actual emails that I want to see. All the newsletters, receipts, confirmations, and other stuff that isn’t spam but that I don’t want appearing in my inbox, and especially in my unread count — those are all there, but tidily away in other mailboxes, where I can deal with them at my leisure.
That said, SaneBox is not free (though it’s cheaper than Hey), and I don’t get that much annoying email. So I don’t think I’ll continue with this exact setup when the free trial ends. But it’s worth knowing that there are good ways — and standards-compliant ways — to achieve similar functionality to Hey’s.
We Built This City on IMAP
What this all shows is that there’s nothing in Hey’s service that you couldn’t create by building on top of IMAP, except the user interface – and that doesn’t have to know about the underlying protocols in any case. It’s possible that is exactly what they have done: implemented it on top of IMAP. In fact, doing anything else would mean giving themselves a lot of extra work, as they would have to effectively reinvent IMAP in any case.
If I were going to build a service like Hey, I’d start with an off-the-shelf IMAP service, probably open source, and build the filtering rules and all that around it.
So I hope that’s what they have done, and that at some point in the future they make their service available to ordinary email clients via IMAP.