BarNinja – An iPhone App Postmortem

The BarNinja iPhone app is a mixed drink application with over 730 drink recipes with additional features including a random drink selector, bartending tips, powerful search, and a shots per bottle calculator for party planning.

The Beginning

As far as we could tell when we started the BarNinja iPhone app, there weren’t any other apps like it on the Apple App Store. That was back in April of 2009. While I was in San Francisco back in March, I got a Facebook message from Jason asking if I was interested in doing an iPhone app. I had done a bunch of Mac development and even independently sold a previous application. I had also attended Apple’s developer conference (WWDC) on two separate occasions so I was quite comfortable with developing for Apple products. When I got back from California, we sat down at a local bar in Blacksburg and wrote down our ideas for the app he wanted to make. That was prior to iPhone OS 3.0 being released and we were counting on some key features in that release for our app. In the end, we ultimately failed when the features didn’t work out exactly as we expected. Luckily, only a little code had been written and that was enough to get me up to speed with the current iPhone development platform.

Instead of quitting, we got BarNinja, another local Blacksburg startup involved in another app idea. We wanted to leverage the shake feature (iPhones can detect when you shake them) that was relatively new and make a mixed drink app based around that.

Soon after we started, a few other apps starting hitting the app store with exactly those features. But the competition didn’t deter us, but instead pushed the bar higher for us. We now knew we couldn’t just make another mixed drink app with a shaker feature, we had to make the best mixed drink app with a shaker feature. We were also creating a 730+ recipe database (including ingredients and other drink information) that would hopefully give us an added advantage. Luckily, at the last WWDC (2005) that I attended, they announced a technology called CoreData which allows developers to place small databases easily within their applications. They also included it in the iPhone OS and I ran with it.

Problems and Solutions

The problem with having 730+ recipes is that it becomes nearly impossible to find a drink in a list. The list view we had, took minutes to scroll through and even tired out your finger having to swipe so much! We added an index on the side to quickly scroll through the list alphabetically. We also added a search to find a drink by name and even added a filter to sort out if the drink was a “mixed drink” or a “shooter.” But that still wasn’t good enough.

I could find drinks like “Vodka Martini,” but what if I wanted a drink with vodka as an ingredient? So we added in a search that would find ingredients too. That worked out well, but often times vodka isn’t named vodka, it’s also names just “Absolut,” which everyone knows is vodka, but the iPhone doesn’t, so we had to teach it what kind of alcohol those products were.

More progress, and we were rolling right along until we tested it out on the actual device; it was painfully slow. The user would hit a key on the virtual iPhone keyboard and the key would get stuck in the “up” position until the search was done and only then could you hit the next key. Searching 730+ recipes is easy, but searching on average 6 ingredients for 730+ (~730 x 6 = a lot) takes 4 or 5 seconds on an iPod Touch 2nd generation. So we had to get a little creative.

My solution was to split off the search into a separate thread (a simultaneous process within the application) and perform the search in the background. This introduced a few other problems that I had to fix but the responsiveness improved dramatically. Then, using Apple’s performance tools, increased the search algorithm by about seven times. Thanks to all those boring Computer Science classes I took at Virginia Tech I was able to speed it up and also make it appear to speed up.

Updating the table view, after finding each recipe that matches the criteria, is slow (thanks to the performance tools for reminding me of this). So I returned the first 5 results instantly because those are the only ones you can see initially on the screen and then the rest were updated in a decaying frequency as they were found until the search was done.

Iteration

The Final Product

Results

They say if you’re happy with your 1.0 version of your application, you didn’t release it early enough. While we definitely have plenty of work yet to do on this application, we didn’t release it soon enough. It did not take a year of programming to get this done. The programming was the easy part, it was all the other stuff that got in the way, distracted me and things I had to wait on that took the longest. Back in the day, when doing my Computer Science homework, the motto was “Start early, and start often.” That rings true for every long term task.

We didn’t run any real usability tests. This upsets me a bit, but we never really got to show it to too many people. Now LTZ has a few more developers working on more apps, so we have a larger pool of testers, but in the end, we still need to test it out on real human beings and put all those Human Computer Interaction (HCI) skills I spent a lot of time learning, to use.

I did try to apply those skills with the layout of the app. When the app launches, the first screen is the random drink screen, which you can tailor to your tastes in the options. We wanted to give the person using our app something to do right away. We didn’t want to over whelm them with a list of 730+ ingredients; it doesn’t impress anyone. In our limited testing everyone figured it out and got a kick out of the shake feature. With other apps, we noticed, they presented a huge list of options that just left you wondering what you should do next. It’s that classic “uuuuh” moment. With ours, right after the launch of the app you can start enjoying the functionality.

The next screen is the raw list of drinks, plain and simple. Our search is straight forward and easy to figure out and the index on the right helps users navigate down the list quickly. We also stuck to using as many user interface elements from the standard set of Apple iPhone as possible. Many other apps try to be creative and diverge from the standard set of UI elements and consequently from the Human Interface Guidelines that Apple has set forth. The result is a poorly designed, clunky looking application that takes time to figure out how to use. Since we’re using a standard search bar, people using our app know right away what that means and can start right away in using the search feature.

We also chose a dark theme for our colors, not because it looks cool, but because most of our users, we assume, will be using it in a bar, or bar like conditions such as a party, etc. But we also didn’t want to give it a depressing theme since it was suppose to be fun and helpful, so there are a few bright colors in there. The design will most likely change and be updated, but that’s the rationale for the initial release. We’ll see what our users think and how they use the app.

We know our app isn’t perfect, but we’re confident we know where to go from here to improve it and fix some of the problems we know exist in it. Through additional usability testing, we’ll slowly improve upon BarNinja to make it the best drink application on the app store. We know we’re not there yet with the initial release, but we look forward to adding great functionality that people will love.