If we have a bunch of drinks in a database, how do we find certain recipes within it? After all, this is computer software and it’s supposed to have advantages over other media, such as books, right?
Ubiquitous apps like Contacts, Calendar, Mail and Music are also “databases”. These mostly provide two options for navigating their contents: either scroll through all the entries or use a basic search field to narrow down the list. The search field actually works great if a simple text match will get you what you want. In fact, that’s what we did with our Cocktails+ and Tiki+ apps: by typing in the search field, you could filter recipes by title or by matching part of an ingredient name. Better than nothing!
The Music app in iOS goes a little further than the others by providing tabs that organize the music database across a few different axes: album, song, artist, genre and playlist. We actually tried adapting that model for Cocktails+ and it didn’t work well. In fact, tabs worked so poorly in Cocktails+ that even I ignored them. So, when Tiki+ 2.0 came along in 2010, we ripped all that out and were left with nothing but basic search. Still better than nothing!
Speaking for myself, I know from my experience with Cocktails+, Tiki+ and CocktailDB.com that I want to be able to easily get answers to multivariate questions like these:
- Which drinks contain both gin and Benedictine?
- Which rum drinks do not contain lime juice?
- What are some stirred drinks that are relatively light on alcohol content?
A simple search field isn’t going to suffice.
The answers I seek are the sort typically produced by database queries. For most people who know the term, “database query” either evokes bad memories of wrestling with elaborate web forms or composing stuff like this:
SELECT * FROM Recipes JOIN IngredientMembers ON Recipes.id = IngredientMembers.recipeID WHERE IngredientMembers.ingredient = “Benedictine” ORDER BY Recipes.title;
However cool you might think SQL is, it’s not something I want to have to type into an iPhone.
So, here in 2013, when I embarked on this new recipe project, I figured that—surely—somebody has come up with something better by now. Right? Nope!
Where are the awesome database interfaces for iOS?
For such a mature and “revolutionary” platform, apps for iOS seem to have seldom gotten past the rudimentary when it comes to databases. I’ve looked high and low and found so little inspiration. It’s almost as if this ground has been ceded to web sites. Meanwhile, web site-based databases tend to be miserable to work with on a touch device unless you’re merely following hyperlinks around.
Well, I have concluded that, given a narrow-enough scope (drink recipes) and a couple compromises (below), we can have an interactive, visual database query interface that is efficient, easy to learn, and useful. Indeed, I think that’s what we’ve implemented, and I think it works pretty well. So well, in fact, that you can use it even when you’re not trying.
Is it “awesome”? Maybe not, but it does what I want it to do. To take one of the above examples:
This query was created by tapping once on a button that says “rum base”, once on a button that says “lime juice”, and then a second time on “lime juice” to negate it. Three taps to whittle 295 recipes down to 16. This system is more powerful than anything I’ve yet seen on iOS and there’s seldom any typing required (sometimes you have to look up an ingredient by name). Moreover, it’s reasonably “discoverable”. I’d call it an intermediate feature, rather than a beginner feature. Perhaps as importantly, it is completely optional: the app works fine even if you never learn how to create multivariate queries.
For those of you who are familiar with boolean logic, the main limitation of our approach is that, while we support negation, we don’t attempt to support disjunction (OR). To do so would dramatically complicate the visual interface and I think the gains would be more academic than practical. The other limitation—I suppose—is that the query choices are “a bit canned”. However, it is only by prescribing what you can query that the visual interface is possible. Besides, I think we’re anticipating the most valuable cases, and we can always add more options in the future.