I recently sat down with Samuel Iglesias, tea-enthusiast (nerd) and first-time iPhone developer to discuss his journey in creating an app called “Tea.”
Who helped you with the app?
Tea is the result of a collaboration between me (@siglesias) and designer Mac Tyler (@mactyler). I came up with the concept after being frustrated by my scattershot, do-whatever approach to making tea–sometimes it would taste great, other times not so much, and I would never be exact about how long I steeped it, just sort of let it sit there until my intuition told me it was ready. After learning that good tea methods can’t be guessed at in any reasonable amount of time without systematically logging notes, I decided that something had to change. What I really needed was a smart note taking tool tailored for the different variables that go into brewing tea: water amount, tea amount, time, temperature, and some measure of how tasty it is.
One of the most awesome powers programmers have is the ability to solve their own computational problems by creating custom solutions for themselves.
Usually it works out that these solutions can also be marketed to other people who likely share the same problem. When I had the concept for a tea app, I was a senior in college, about to graduate, never having coded before, but also deeply interested in technology. This project finally pushed me to learn how to program.
Why did you choose iPhone as a platform?
I chose iPhone because it happened to be the platform that I owned, thus was most familiar with, and secondly because we were still in early 2009 when I had the idea to do this, and the best Android phone, as I recall, was the G1, so the decision between platforms wasn’t even close. I still think iPhone is the superior platform for users and developers today for reasons that have been extensively and laboriously articulated elsewhere.
What frameworks / IDEs did you use during development?
Tea is built using the standard Cocoa Touch frameworks, started in Xcode 3, but completed in Xcode 4 in early April 2011. Switching to Xcode 4, which I hadn’t used before, was something of a risk mid-project, but ultimately it proved to increase my efficiency by raising errors and so on without the need to compile. Also, the built in documentation panel is rather useful.
How long did it take you? What snags did you come across during development?
The idea for tea was developed in April of 2009, so two years ago, but I didn’t start writing it until November of that year. The first major hurdle to overcome was the tiny problem that I didn’t know how to code. In this industry, there are two ways to clear this hurdle: learn to code, or find and convince someone to code it for you. Naturally, many would-be entrepreneurs choose the second path, as I myself had several times for other ideas, getting burned badly each time. We think we can just find the nerd in our college, spin a grandiose story of riches and fame, and get them to code our project for us while we, I dunno, make phone calls to VCs and craft business plans. Doesn’t work for two reasons: 1) the local nerd usually has his or her own pet project that always gets priority and 2) early startup work is rarely ever a 50/50 split between engineering and business stuff; you think it is, but the nerd knows otherwise. There was another practical concern, which was that in 2009, college students who were programming were programming web applications, which were hot, and not doing mobile yet.
The guys doing mobile, specifically iPhone development, in 2009, were veterans of Cocoa who were in their 30s, 40s, and 50s, not college students. I figured that the best way to go to get this app done was to bite the bullet and contact a Cocoa developer to teach me iPhone development and/or to mentor me through this first app idea. I contacted the Meetup iPhone group in Raleigh with a blast email asking for a tutor. I got a reply from an ex-Apple engineer, and we worked out a deal of four lessons a month. We started with three months of rigorous C, then dove into Objective-C, which was a jarring transition because it’s kind of a paradigm shift with no clean strands connecting former and latter. Most literature on object oriented programming don’t do a very good job of even explaining what objects are; they just kind of refer to them like it’s obvious what they are. Other literature makes embarrassing analogies with ducks quacking, swimming, flying, and inheriting from birds–cute, and in hindsight somewhat apt, but not useful at all for a beginner. The Apple docs on object oriented programming remain in my mind the best place for beginners to go to figure out what it’s all about.
The biggest snafu I hit, though, was internal, and that was regarding Tea’s design. It’s very tempting early on to try to be macho and do both the design and coding for the app. To go this route, it’s usually optimal to use as many default components as possible and to go for a minimalist interface. By the end of summer 2010, I had settled on a design for the brew screen that had little squares flipping over as the counter counted down, sometimes flipping over white, other times flipping over red, in a grid like pattern. The pattern that would emerge of red on white would be cellular automaton, popularized by Stephen Wolfram.
The initial parameters would be a row of cells with red cells distributed across white cells in proportion to the tea to water ratio. A stronger brew would seed the cellular automata with more red squares in the beginning. Hitting “brew” would start the automata process using Rule 30.
I was really in love with this idea because I felt that the process of a cellular automaton program meshed nicely with the idea of tea leaves unfolding. It would also give the user something to enjoy as the counter was counting down. The problem was, of course, that most users would have no idea how or why the squares were unfolding in the way that they did. This problem kept nagging at me, but I ignored it. Finally, when I was reading Apple’s iOS Human Interface Guidelines, the following line hit me:
Focus your solution on the needs of 80 percent of your users. When you do this, the majority of users do not need to supply settings because your application is already set up to behave the way they expect. If there is functionality that only a handful of people might want, or that most people might want only once, leave it out.
While I had put a great deal of effort into developing code for cellular automata as well as learning the odds and ends of Core Graphics shading and Core Animation, reading this passage was enough to push me to start over from scratch on the interface and seek a professional to help with design. It was at this point that I started browsing a design site that Sophia Teutschler had tweeted about, Dribbble, and that’s where I found the work of Mac Tyler. I contacted him with my idea initially as a freelance job, but eventually it evolved into a partnership.
Mac has done some incredible work on Tea’s design overhaul. Interestingly, despite our close and successful collaboration, we’ve never met.
Tell me about the process of getting your app accepted in the app store…
Tea took about a week to be approved in the App Store after we submitted it early April, but we decided not to release it immediately. Why? Mainly, we learned of the incredibly hard time Color (which had been recently released) was having with its blank state problem. The night before we expected Tea to be approved, Mac sent me a DM on Twitter with Mike Rundle’s article, “How Color Already Blew It.” Although we had spent an entire month beta and usability testing, we missed warning signs that Tea also had a blank state problem of its own. Some testers would simply not respond to emails, while others commented that they didn’t know what was going on when the app was first launched, but grasped quickly when we explained it to them. The few users who did understand Tea immediately gave us a false sense of usability. The rationalization was that users would do research on the app before purchasing it, and hence they would know how to use it. But thinking deeper into it, lots of iOS purchases are impulse buys. Little, if any research at all is done by consumers before deciding to buy. This quote by Jason Fried was the nail in the coffin:
Ignoring the blank slate stage is one of the biggest mistakes you can make. The blank slate is your app’s first impression and you never get a second…well, you know. […]
It explained the strange behavior of some of our beta testers (we had blown our first impression) and prompted us to search for a solution that would appease all users, not just the ones who “got” the interface right away. Mac and I resolved to preload the app with example entries and instructional popovers, and launched Tea a week after we had planned to. (Pictured below, before (left), after (right))
How did you decide on the price point for the application?
Pricing is a very tricky matter, and half of the battle is communicating how much value the product provides. Tea is not an app that you buy once, play around with, and never use again. Our customers are consistently telling us: “we love this app and we use it every day.” You can read that in the reviews. It’s the secret to getting the most out of all of your teas, and good teas run $20 each! You don’t want to mess those up by preparing them incorrectly. When you put your tea related costs into perspective, we think that $3 for the ultimate tea app is a great deal.
How are sales?
Couldn’t be happier with sales. We’re fast approaching our 4,000th copy sold. Just a week into launch Apple featured us in the 5th slot under New and Noteworthy, which was an absolute privilege. Currently we’re in What’s Hot for two weeks running, and are wrapping up an international version of Tea that will be compatible with 6 languages. Pretty exciting!