We love Sparrow. With its clean interface and seamless integration with Gmail, it's our favourite email client for both Mac and iPhone. The Sparrow team (which was recently acquired by Google) managed to build something that's incredibly useful and a pleasure to interact with. How did they do it, and what were the challenges along the way? We caught up with Sparrow's co-founder and CTO Hoa V. Dinh to find out.
If you're not familiar with Sparrow, check out this video about how it works (via iStartMacRumors):
Where did the idea for Sparrow come from?
Before 2004, I used to host my emails on my own server at home. I started using a Mac around 2004 and initially Apple's Mail.app worked fine for me. When I was tired of managing my own server and wanted to focus on building software, I migrated everything to Gmail -- it was the only email server that would let you store a decent amount of emails.
However, the Mail.app was flaky with Gmail: no archive, weird mapping for labels, it became slow, and it would find duplicates while searching. Therefore, I stopped using it and started using Gmail's web interface even though its integration with the desktop was not great. In 2007, iPhone was released. It had an email application built-in that was simpler than any email application that we could find on the desktop. Also on their desktop, some people were even using a second application to read email: an email notifier.
At this point, I found two problems I wanted to solve: creating a very good Gmail integration on the desktop and making email as simple as on a mobile phone.
After you came up with the idea, what was the next step?
I started prototyping and built several behaviours in order to come up with something I thought would provide a very good user experience. My first goal was to develop to the point where I would be able to use it instead of any other email application and never have to open the Gmail website.
The second step was to have a few close friends use it. As a matter of fact, since my close friends and I weren't users of labels on Gmail, the very first beta we launched didn't have labels. But luckily, we figured out how to introduce them without interfering too much with the UI design.
Pictured above: The view from Sparrow's office in Paris.
How did you choose which platforms to target and which to ignore or wait on?
I set out to build an email application for my personal use. Therefore, it was targeted for the Mac. Since I hadn't used Windows for a long time, I didn't know what the expectations of those users would be. So we decided not to build something for that platform.
What was your biggest roadblock and how did you overcome it?
The biggest roadblock was that most of the email applications are free and installed by default on every single platform. We had to come up with something really great so that people would be willing to buy it to replace their default application.
What was launch like for you?
When we launched the public beta, we didn't really expect a massive number of downloads or website hits. The website wasn't available because of the high load. I had to fix it quickly. People were talking about Sparrow on Twitter every few minutes and it was exciting -- we had very good feedback from users. Articles on major tech news websites were also talking about us, while we launched from Paris. It was amazing.
How do you handle user requests and criticisms effectively?
We made it a priority to reply very quickly on Twitter, and through the support contact email, to users who were having issues. It was part of the user experience -- people enjoyed seeing their issues solved so quickly. When we could see a common pattern, we would take some time to think about the right thing to implement to solve their issues.
Pictured above: Hoa's late night workspace.
Now, how do you split time between developing new features and managing existing ones?
Given an approximate timeframe for release, there were two steps: we would first implement the new features we planned. Then, we usually dedicated a few weeks for bug fixes or small improvements of existing features. Then, we would ship. The split was usually 75 per cent on new features, 25 per cent on improving the existing ones.
What advice would you give to others that want to take on a similar project?
User experience is not about building something beautiful. It's building something that people are happy to use.
Lifehacker's new Behind the App series gives an inside look at how some of our favourite apps came to be -- from idea to launch (and beyond).