Well over two years ago, I was bitten by the “email is broken” bug. You know that one - your inbox is clogged and exploding, you’re tired of the text, you hate labels and folders and you just want it to stop screaming at you. Or maybe you’ve never been bitten by that bug - you’re a Gmail ninja, an Outlook pro, are super-efficient or buy nothing and have no friends.
Nonetheless, I assumed that I wasn’t alone in feeling this, so my co-founders and I set out to change the world for my 3.5 billion email using brethren. I’d say that’s pretty noble of us. Well, I’ll spare you the suspense and tell you that perhaps a new client ISN’T the answer. But while I wrote about the challenges from a user perspective, I’m proud to say that we were able to hack together a pretty robust client using some nice new technologies and thinking creatively about how we handled certain issues. And, we must’ve been on the right track, considering AOL decided to flatter us by releasing an almost identical product five months after we launched (us and them).
A Little Background on Email Messaging
Email is one of the oldest protocol’s on the internet and not much has changed since Ray Tomlinson sent the first ARPANET message in the early 70s. With the rise of IMAP, email service providers made it easy for customers to retrieve emails from any address to any email client that supported it (see this easy primer on IMAP v POP3). So, for us innovators, we can access the goods without requiring users to change their email addresses. All we have to do is build a better front-end experience. Easy, right?
To Rails or Not To Rails?
We all know and love Rails for its ability to prototype new projects in weeks rather than months. We chose Rails, because all we had was a concept and it was imperative that we build something substantial and quickly that would allow us to justify our first entrepreneurial plunge. Working part-time with 1.5 developers during nights and weekends, we built a working prototype with Rails in just over 30 days that would fetch IMAP messages from Gmail and Yahoo and automatically filter the messages against a rudimentary database of matchers (with Charlie as our brand logo stand-in).
The prototype was a big success for us, leading to us raising an initial round of outside funding. Perhaps equally important, it also demonstrated that we had a lot to learn about email. With a database chock full of our personal email messages and a Ruby-based daemon constantly fetching new mail, we were introduced to the dual challenge of ensuring email security and application scalability from Day 1. New users would certainly expect that we would be passionate protectors of their data. Furthermore, every new user who would sign up, even if she never signed in again, would become an active, concurrent user of our application. We had raised money, but we were still on a budget and horizontally scaling Ruby by itself was not going to be cost-effective.
We Know What We Node(.js)
In October 2011, we migrated our email daemon to Node.js. Contrary to what some may say, it is not a Rails killer, … but it kicks some righteous ass at performing thousands of concurrent calls to a remote IMAP server and gracefully handling those responses asynchronously. A single server instance of Node 0.6.x series literally gave us the fire power that we needed to support thousands of concurrent Gmail, Yahoo and AOL users with refresh cycles occurring every 5 minutes, which could have been pushed to every 1 minute if we didn’t have to worry about hitting too many concurrent connections from a single IP address.
To be fair, it wasn’t all sunshine and rainbows. Callback soup was a bit of a pain in the ass at first and finding mature libraries who could act like grown-ups (POP3 we’re looking at you) was a bit hit or miss. But life in server-side JavaScript land was quite productive once we solved those problems with JQuery Promises, experimented with what was out there on Github, and politely told Hotmail users that we felt terrible about not being able to support them (not really).
After 6 months of working with it, our belief is that Node is like having a pair of vise grips in your toolbox. You certainly won’t use them as often as your hammer, but they are really useful in specialized applications.
The Devil’s In the Details
In a little over 6 months, we built a comprehensive, sleek, and powerful email client that could sync up to 10 accounts from Gmail, Yahoo, and AOL; allowed the user to compose, send, receive, reply, reply all, view sent messages and drafts; synced read/unread messages with the underlying email client; supported attachments; and, of course, offered our differentiated, value-added filtering and visual icons. And wouldn’t you know it, they wanted MORE! And why shouldn’t they? Because who thinks about the importance of supporting email signatures - an easy add - or archiving messages - an easy add - or chat - a medium add - or threading - a tougher add - or….well, you get the point. And then mobile, calendar, tasks and a lot of easy “adds” add up to a level of development complexity that means you’re running full sprint just to make it to the starting line. It reminds me of what Andrew Wiles said when he was working on his solution to Fermat’s last theorem (I’m quoting from memory here), “It’s like trying to fit a carpet that is too big for the room. You go push down one corner, only to see another corner pop up. So you deal with that corner, and the corner you just set, pops up.” The email ecosystem is so complex and so important to the user in so many different ways, that you better be ready to tackle a lot of corners.
Mama, I’m Coming Chrome
Fortunately, building a new email client is not the only option for innovators. Anyone who attended this year’s Inbox Love conference in Mountain View would have learned about a number of exciting new enhancements to email. Sure, there’s Outlook.com and AOL’s aforementioned Altomail, but there is also an entire suite of web apps (such as OtherInbox and Sanebox) and browser extensions (such as Rapportive and Boomerang). With PhilterIt, we’ve taken the Chrome extension path (and will soon add other browsers), leveraging our node.js back-end and using backbone.js on our front-end. We’re extremely pleased with how seamlessly we’ve been able to integrate our visual filtering within Gmail, and how much control/functionality the user retains. Also, if you’re building a new email product, check out Context.io, recently acquired by ReturnPath. You could even win some money.
So best of luck to Minbox, Mail-Pilot, Glider.io, Contur and all of the other inbox warriors out there. It’s going to be a ride.
Nonetheless, I assumed that I wasn’t alone in feeling this, so my co-founders and I set out to change the world for my 3.5 billion email using brethren. I’d say that’s pretty noble of us. Well, I’ll spare you the suspense and tell you that perhaps a new client ISN’T the answer. But while I wrote about the challenges from a user perspective, I’m proud to say that we were able to hack together a pretty robust client using some nice new technologies and thinking creatively about how we handled certain issues. And, we must’ve been on the right track, considering AOL decided to flatter us by releasing an almost identical product five months after we launched (us and them).
A Little Background on Email Messaging
Email is one of the oldest protocol’s on the internet and not much has changed since Ray Tomlinson sent the first ARPANET message in the early 70s. With the rise of IMAP, email service providers made it easy for customers to retrieve emails from any address to any email client that supported it (see this easy primer on IMAP v POP3). So, for us innovators, we can access the goods without requiring users to change their email addresses. All we have to do is build a better front-end experience. Easy, right?
To Rails or Not To Rails?
We all know and love Rails for its ability to prototype new projects in weeks rather than months. We chose Rails, because all we had was a concept and it was imperative that we build something substantial and quickly that would allow us to justify our first entrepreneurial plunge. Working part-time with 1.5 developers during nights and weekends, we built a working prototype with Rails in just over 30 days that would fetch IMAP messages from Gmail and Yahoo and automatically filter the messages against a rudimentary database of matchers (with Charlie as our brand logo stand-in).
The prototype was a big success for us, leading to us raising an initial round of outside funding. Perhaps equally important, it also demonstrated that we had a lot to learn about email. With a database chock full of our personal email messages and a Ruby-based daemon constantly fetching new mail, we were introduced to the dual challenge of ensuring email security and application scalability from Day 1. New users would certainly expect that we would be passionate protectors of their data. Furthermore, every new user who would sign up, even if she never signed in again, would become an active, concurrent user of our application. We had raised money, but we were still on a budget and horizontally scaling Ruby by itself was not going to be cost-effective.
We Know What We Node(.js)
In October 2011, we migrated our email daemon to Node.js. Contrary to what some may say, it is not a Rails killer, … but it kicks some righteous ass at performing thousands of concurrent calls to a remote IMAP server and gracefully handling those responses asynchronously. A single server instance of Node 0.6.x series literally gave us the fire power that we needed to support thousands of concurrent Gmail, Yahoo and AOL users with refresh cycles occurring every 5 minutes, which could have been pushed to every 1 minute if we didn’t have to worry about hitting too many concurrent connections from a single IP address.
To be fair, it wasn’t all sunshine and rainbows. Callback soup was a bit of a pain in the ass at first and finding mature libraries who could act like grown-ups (POP3 we’re looking at you) was a bit hit or miss. But life in server-side JavaScript land was quite productive once we solved those problems with JQuery Promises, experimented with what was out there on Github, and politely told Hotmail users that we felt terrible about not being able to support them (not really).
After 6 months of working with it, our belief is that Node is like having a pair of vise grips in your toolbox. You certainly won’t use them as often as your hammer, but they are really useful in specialized applications.
The Devil’s In the Details
In a little over 6 months, we built a comprehensive, sleek, and powerful email client that could sync up to 10 accounts from Gmail, Yahoo, and AOL; allowed the user to compose, send, receive, reply, reply all, view sent messages and drafts; synced read/unread messages with the underlying email client; supported attachments; and, of course, offered our differentiated, value-added filtering and visual icons. And wouldn’t you know it, they wanted MORE! And why shouldn’t they? Because who thinks about the importance of supporting email signatures - an easy add - or archiving messages - an easy add - or chat - a medium add - or threading - a tougher add - or….well, you get the point. And then mobile, calendar, tasks and a lot of easy “adds” add up to a level of development complexity that means you’re running full sprint just to make it to the starting line. It reminds me of what Andrew Wiles said when he was working on his solution to Fermat’s last theorem (I’m quoting from memory here), “It’s like trying to fit a carpet that is too big for the room. You go push down one corner, only to see another corner pop up. So you deal with that corner, and the corner you just set, pops up.” The email ecosystem is so complex and so important to the user in so many different ways, that you better be ready to tackle a lot of corners.
Mama, I’m Coming Chrome
Fortunately, building a new email client is not the only option for innovators. Anyone who attended this year’s Inbox Love conference in Mountain View would have learned about a number of exciting new enhancements to email. Sure, there’s Outlook.com and AOL’s aforementioned Altomail, but there is also an entire suite of web apps (such as OtherInbox and Sanebox) and browser extensions (such as Rapportive and Boomerang). With PhilterIt, we’ve taken the Chrome extension path (and will soon add other browsers), leveraging our node.js back-end and using backbone.js on our front-end. We’re extremely pleased with how seamlessly we’ve been able to integrate our visual filtering within Gmail, and how much control/functionality the user retains. Also, if you’re building a new email product, check out Context.io, recently acquired by ReturnPath. You could even win some money.
So best of luck to Minbox, Mail-Pilot, Glider.io, Contur and all of the other inbox warriors out there. It’s going to be a ride.
Avi Levine is co-founder and CEO of PhilterIt, a Google Chrome extension for Gmail. You can find him on Twitter @alevine0.
No comments:
Post a Comment