b'\n\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\tAndrew Lilja • Build-a-Meal\n\n\n\t
\n\t\t
\n\t\t\t
\n\t\t\t\t

Build-a-Meal

\n\t\t\t\t

There was a lot of excitement surrounding Swift — a dynamically-typed language that left behind a lot\nof the cruft and legacy of Objective-C and dramatically reduced things\nlike boilerplate code and hacky solutions1. I always found Objective-C\nconfusing, so when I had the opportunity earlier this year to start\nlearning Swift, I jumped on it. I began working on an app called\nBuild-A-Meal (name still subject to change) which would allow the user\nto figure out what ingredients work well together and which ones don\'t.\nI couldn\'t find anything like it — the closest were apps that let you\nfind recipes based on what\'s already in your fridge. I didn\'t\nwant recipes, I wanted to know what flavors fit together to use as a\nstarting point for creating new recipes.

\n

This app is still a work in progress. You can see the progress and run\nthe app with a limited data set\nhere.

\n

I knew generally how I wanted it to work. It should provide a clear at-a-glance indicator of how well\nfoods fit together, be easy to pick ingredients and see what goes with\nwhat you already have2, and keep track of your previously used\ncombinations. My very first thought was a giant flavor wheel that would\nbe organized into the five main flavors3, with foods arranged\naccording to how strongly they fit into a given flavor. For example a\nlemon is very sour with some bitter flavors, so it would be closer to\nthe bitter side of the sour foods.

\n

The first sketches for the app.

\n

There are a ton of problems with this design. First of all, to fit all\nthe foods necessary, the wheel would have to be enormous. Foods that\nhave several flavor profiles couldn\'t be easily categorized. Foods that\nhad flavors that were on opposite sides of the wheels wouldn\'t be able\nto fit easily on it. There wouldn\'t have been enough room to list all\nthe matching foods, and that would have created a secondary interface\nfor the same data set. After trying out some ideas (and even\nprototyping one) it became clear that this was\nnot a good way to go.

\n

I started thinking about how I would use the application and what sort\nof features I needed access to quickly and easily. I should be able to\ncome in with either some sense of what I wanted or with nothing at all\nand rapidly build a set of matching flavors. The UI needed to rapidly\nshow me how well things fit together and then making immediate changes\nbased on that information. It didn\'t matter whether the foods were salty\nor sweet or sour — I wasn\'t even going to be thinking of it that way\nwhen it came to building the ingredients. I would be thinking about\nindividual ingredients and then wanting to get a sense of how well\nthey\'d fit together and what kind of other foods would be good\nadditions.

\n

Doug Engelbart talked about the computer as a vast information space,\nwith the computer providing people knowledge in useful ways to help them\naccomplish their job. I tried to shape the app in that same sense: it\nknows how well things fit together, it\'s just up to you to give tell it\nwhat items you want to check. And since it knows how things fit\ntogether, it should provide you with information about other things\nfit well. I don\'t want to have to think about fit, I want to spend my\ntime thinking about designing new recipes and what I can put in them to\nmake them even better. The computer should be the other side of a\nconversation about food, someone who never gets bored when I ask how\ndifferent ingredients fit together, and politely tells me what other\nthings I should try that might be interesting.

\n

What it should never do is make me actively consider things that aren\'t\nfood-related, like navigating the interface or finding a specific item\nburied in a list. With this in mind I consciously stayed away from a network model.\nThis was pretty tempting: a network of relationships between food items\nseems like a home run. But I didn\'t like the idea of all that panning on\na small phone to find what I was looking for4, nor the distinction\nbetween the search set and the collected set. I don\'t care about\npotential connections between all the items out there, I\'m only\ninterested in the relationship between the items I have now. The search\nset should be a big nebulous cloud that contains the foods I\'m curious\nabout, but only that — who cares if bearnaise sauce goes well with\ncrepes if I\'m curious about what to use to replace fish sauce with in my\nbanh mi.

\n

This got me thinking about card-based applications,\nwhere every food would be represented as a card. It would show\ninformation about flavor profiles and what foods matched that, on each\ncard. You could add cards to a bin, and tapping a matching food in a\ncard would put that flavor in the bin. Of course, some foods are blank\nslates and match many other flavors, so you\'d need some sort of search\nfeature to look for them. But wait — if you\'re going to have a per-card\nsearch feature, why not just make it a global search that looks for\nfoods in both the cards and the flavors on each card? I thought about\nhow to deal with the same flavor appearing on more than one card in\nsearch results, and realized the solution was to get rid of cards\nentirely and have the interface essentially function as a front-end to a\ndatabase. You enter the food you\'re looking for, and it tells you how\nwell it matches the other foods you have.

\n

I was lucky enough to have a fairly robust dataset from Culinary Artistry,\nwhich provided a long list of foods and their associated matching\nflavors5. When discussing my app with a friend, I mentioned this\none-to-many relationship, and he said that "it sounds like the flavors\nand foods are begging to talk to each other." I took his advice and\neliminated the distinction between foods and their associated\nflavors. Now, everything was connected both ways. Beef goes well with\nred wine, and red wine goes well with beef.

\n

Once I ditched the wheel, I shifted over\nto a three-part UI.

\n

I began sketching and wireframing. The app would have three parts: the\ntop bar would contain the search field, just below that would be the\nfoods you were currently matching, and the bottom would would contain\nflavors you hadn\'t added but that might fit well within your current\nflavor profile. You could enter some foods and see how well they fit\ntogether visually and then immediately see what else you could add. The\npotential flavor set would be populated by taking all the flavors\nassociated with the foods being matched and ranking them by how many\nfoods they shared in common. If four foods were being matched and they\neach went well with cream, that would appear higher than a flavor that\nonly went with two of the matched foods.

\n

Showing how well flavors fit together was tricky. I developed an\nalgorthim that matched foods based on how well they fit together, and\nthen displayed how well they fit using a traffic light\nmetaphor. A green display means that flavor\nfits well within the group, while a red color indicates a bad match.\nMost people have a clear sense of "green means good and red means bad,"\nso I thought this color system would make it easy to understand what was\ngoing on without having to resort to numbers or icons. At a glance, you\ncan see how well everything fits together and immediately identify where\nyour problem areas are.

\n

In order to get an app to feel right, there\'s a lot of details that have\nto be handled. Autocomplete was a must for the search bar. You need to\nknow what\'s available to you, and showing a list of potential foods\ncombats the anxiety of just being face with a blank screen. I had wanted\nto show how well each food would fit in to your existing set before even\nadding it, but unfortunately, this slowed the app down too much. It\'s\nmuch faster (and less distracting) to just add a food and see how it\nfits than to wait a few seconds to see how everything fits, when all\nbut one of those items aren\'t what you want.

\n

Don\'t put foie gras in your tomato sauce\nrecipe.

\n

This application is still a work in progress. A huge part of its success\nor failure will hinge on the data in the backend, and right now, I only\nhave around 40% of it implemented in machine-readable format. I also\nneed to run user testing — both on myself, and on people who would find\nthis useful. I have a wish list of features I hope to implement, like an\nauto-match feature that will automatically build a flavor profile from\nscratch or add new matching flavors based on what you already have. If\nthis sounds interesting and you\'d like to play around with it, you can\ndownload a copy from GitHub.\nDownload all the sketches here.

\n\n\n\t\t\t
\n\t\t\t\n\t\t
\n\t\t↩︎\n\t
\n\n\t\n\n'