Here at SeatGeek, we recently launched version 2.0 of our Android app, a major update to the version we launched a little over a year ago. The new release includes features such as authentication with your SeatGeek account, the ability to track performers and events, and notifications for deals or newly announced events. It also includes a major face lift from version 1.0 to offer a cleaner and more refined UI that is more consistent with the experience we target here. The most impressive thing about this release, however, was that it was executed almost entirely by a team of two engineers, with one of them only focused on Android about 50% of the time. This is only possible because of the things that SeatGeek has that I believe you need to build a successful Android application at a small scale.
Choosing the Right Tools
We use a number of tools on a daily basis to build the SeatGeek app. A non-exhaustive list looks something like this:
Git, Github, Jenkins CI, Gradle, Android Studio, Crashlytics, Google Analytics, Dagger, RxJava, Retrofit, Otto, Picasso, Mockito, JUnit, Roboelectric, Spoon, Hackpad, and Mao Mak Mak (our internal kanban board, built on top of Github issues)
We know we’re not the only ones using these tools, but we know that our use of them allows us to iterate faster and avoid common errors that come with application development. Developer productivity, sanity, and satisfaction almost always take priority as we’re building out new features in the application. We are very proactive about accepting new tools as part of our workflow; if we can prove that there’s a productivity increase, that’s usually enough for us.
We’re buyers on RxJava. Netflix’s port of .NET’s Reactive Extensions has simplified and enhanced many parts of our app. We started with porting our networking-layer code over to RxJava with Retrofit during the 2.0 release, and we’re very close to having all of our network requests served through it. The powerful composition tools and high-level stream manipulations have made producing some of the most complex views in our app much more concise by reducing state management and simplifying the data paths. RxJava may not solve all of Android’s complexities with concurrency, but it’s the best tool we’ve used yet.
We’re also fans of Dagger. Square’s lightweight dependency injector made DI a viable pattern to use in Android apps by reducing the runtime overhead seen in other injectors. We love Dagger because it makes getting all the useful classes you need into your Activities, Fragments, and Views incredibly easy. As an added bonus, by following the patterns promoted by DI, our application’s components are more decoupled and easier to test. The latter point has been instrumental in helping us with our growing test suite for the application.
Hiring The Right Team
I don’t think this is a particularly insightful point, but it is the most important. In order to do anything successfully at at any scale you need a team of people capable of executing on a shared vision. At SeatGeek, we focus on hiring a team of product-minded engineers that are capable of wearing multiple hats. Our Android Lead, Dallas, is just as comfortable in Photoshop as Android Studio, and there’s a reason for that. In order to build an application experience that users are going to find delightful and exciting, you need a particular type of engineer that is conscious of the UX of the things that they are building and is willing to be autonomous in polishing it. Dallas is often relied upon to drive product and design decisions around the Android app, and he has the skill set to do it.
Dallas is not a one man show, though. We have our in-house designers that work closely with the Android team to iterate on features and help provide structure to the design process. Over the course of the 2.0 release, the design team collaborated with the Android team to build a Style Guide that can be reused throughout the application. With our Style Guide in hand, Dallas and I can make safe assumptions about our design decisions without running risk of violating over-arching design principles in the application. Our Style Guide draws heavily from the Android platform’s Style Guide and it helps that our chief mobile designer, Mladen, is as in love with Material Design as we are.
Finally, we have a product development team that’s committed to producing not just a quality product, but a quality Android product. To SeatGeek, that means staying true to the Android platform’s design guidelines; monitoring our application’s performance in terms of network usage, battery drain, and error rates; and targeting Android devices running Ice Cream Sandwich and higher. We understand that there may be Android users still running a version <4.0 of the OS, but we care much more about developer sanity and productivity than potential user base – plus, SeatGeek is killing it with users running Android 4.4.
Being Whimsical
If you spend any time around our Android team, you may hear the word “whimsy.” You may even hear it a few times. Alright, you’ll probably hear it a lot. “Whimsy” is our descriptor for what most people would call “delightful design details.” We love whimsy around here, because we believe that those little details are part of what keep our users coming back. Also, they’re fun to build.
One of our favorites is the empty state indicator in our My Performers section of the app. When an authenticated user visits this screen, usually they’ll see all the performers they’ve tracked for event updates and notifications. But if the user is new, they may not have any performers to show yet. Since people love their favorite performers, we knew that a heart was the perfect icon to display here. The problem is, a static heart icon lacks “whimsy” (and life). To correct this and make our heart more lifelike, we decided to make it beat:
In making the heart beat, we probably could have used a simple, repeating scale up-scale down animation. We decided to be a little more accurate than that. We wanted to model a real heart beating, so we dusted off our old anatomy textbooks and studied the T-wave produced by an ECG machine. We plotted out one full period of the wave and extracted mostly-accurate timings for each phase of the wave (for a mathematical breakdown of the ECG Fourier series, this is a good start). We popped these timings into our code and the result did not disappoint. It’s the little details like a heart beating that we strive to get right to take our app to the next level.
Final Thoughts
We believe we have all the right pieces for building a successful Android app at a small scale here at SeatGeek. We have great tools, the foundation of an incredible team, and our app is packed full of “whimsy.” If you’re working on a small Android development team and you’re looking to improve your process, look no further than investing in your tools, improving developer sanity, and evaluating your team’s commitment to building a product your users will love. Your developers will thank you, and your users will follow–whimsically.
Oh and by the way, if any of this interests you, we’re hiring.