UI Challenge Part Deux

One of the most demo-able features of KitchenPC is the ability to take a set of available ingredient amounts and automatically determine a set of recipes that will utilize those ingredients, leaving the fewest amount of surplus.  I’ve been calling this concept “meal modeling”, though I doubt that’ll turn into any sort of marketing catch phrase.  In the computer science world, we call this an NP-Complete problem.  More analogously, this problem can also be referred to as a 0-1 knapsack problem.  The basic idea is that the only way to figure out the exact set of recipes you would have to make to result in the fewest number of leftover ingredients would be to actually iterate through every combination of possible recipes and keep score.  This might be fine with a small set of recipes, but if the site takes off and the database acquires hundreds of thousands of recipes, the computational requirements would start to become quite substantial.  To add another layer of complexity, we don’t want to assign the same “weight” to every recipe.  Ideally, we should prefer recipes that the user is more likely to enjoy cooking based on an analysis of their previous ratings, their ingredient blacklist, their favorite recipe tags, etc.  Now this becomes a fun problem to solve.  However, this post is not about that because I’m sure not gonna be giving away those secrets!  However, I do want to talk about the challenges in creating the user interface in front of this “meal modeling engine.”

First off, the user needs to be able to define the criteria they wish to use to create a model.  It’s up to them how many recipes they want to have in their plan, which tags they wish to allow (by default, this is set to Dinner, Main Dish, Side or Dessert), and whether to use their saved pantry or manually type in ingredients they have available (as not everyone wants to use the pantry, remember?)

At the bottom of the page is a sliding scale containing five radio buttons.  The left-most radio button has a caption that says, “Find recipes that use my ingredients most efficiently.”  The right-most radio button is labeled, “Find recipes I’m most likely to rate highly.”  The middle option, and default, is simply titled, “Balanced.”

This simple scale is not just there to give the user the illusion of power; this information is taken into account by the meal modeling engine when considering various recipe combinations.

The results page is slightly more challenging from a usability point of view.  I initially considered just using the standard search results template to display the resulting recipes, but this felt like a cop-out for various reasons:

• There’s no visible correlation between the desired run criteria and the resulting recipe list.  In other words, as far as the user is concerned I just spouted out some random recipes and they’re supposed to trust that this is the best meal plan for them.  Yeah right.
• It lacks the ability for the user to judge the results as a potential fit for their available ingredients.  The user may ask themselves, “Ok, if I make all of these, am I going to use up that asparagus that’s been sitting in my fridge for a week?”
• It doesn’t provide the ability for the user to partially select a subset of the results and receive visual feedback on the efficiency of their selection.  “If I only want to use 3 of the 7 recipes suggested, will I need to buy more cheese or do I have enough?”

Ok, so how do we address these issues?  It seems a bit lame to build such a cool meal planning engine and not build an equally cool interface to use it.  I’m still mocking up a wireframe in Balsalmic, but I’d like to share my initial thoughts on this layout.

This results page will share a lot of similarities with the search results page, as users should recognize this user interface and know how to use it already.  For example, the results will be listed vertically with the same information provided (picture, title, description, rating, etc.)  The meal calendar will also be available at the top of the list and fixed on the screen statically so the user can scroll through recipes and still drag any recipe onto the meal calendar.  So far, this design is exactly identical to the search results page.  However, on this page, recipes will also contain a checkbox to check or uncheck individual results.  Checking the box will visually light up the row to make it very obvious this recipe is now part of a group selection.  By default, all rows will be checked.  Furthermore, when a user drags a recipe, the entire selected group will be dragged along with it.  Visual cues will indicate this behavior.  This allows a user to “check” a bunch of recipes and drag them all at once onto the calendar.  When multiple recipes are dragged on to the calendar, they will be spread out starting on the date the user dropped them on to.  Each day after will receive up to one main dish, one side and one dessert.  The user can then arrange these recipes in any way they like by dragging them between dates.

The other UI element on this page is something I’ve been calling an “efficiency graph”, but will probably just be titled “Ingredient Usage.”  This will be a tall, skinny box that lists all ingredients being used by the resulting recipes along with the total amount of that ingredient required to make these recipes.  For example, if one recipe required 3 eggs and the other required 2 eggs, the efficiency graph would contain an entry for “Eggs: 5”

The graph would also be color coded.  At the top of the list would be a section with a green background.  If an ingredient appears in this section, the total required amount would be less than or equal to that which the user has available.  In other words, you have enough of that ingredient to make these recipes so there’s no need to worry.  Below that would be a “yellow” section.  This would contain ingredients that you have some of, but not enough to make all of the desired recipes so you’ll have to buy more.  But at least you’ll use up old stuff!  Below that would be a “red” section indicating you don’t have any of this ingredient and you’ll need to go buy some.  I’m considering providing additional detail using tooltips, which would answer questions such as how much would still be leftover in the green section, or how much you’ll need to buy in the yellow section.  Another “bells and whistles” feature could be when you hover over a recipe, the ingredients light up in the efficiency graph.

As the user checks or unchecks recipes, the efficiency graph would update in real time.  This would give the user a visual representation of what ingredients they’ll be using and what kind of shopping they’ll need to do.  Here, they can play around with scenarios and get instant feedback until they find a set of recipes that works for them.

Ideally, if the user selects the “Use my ingredients efficiently” side of the scale, they should get all green ingredients in the efficiency graph and not have to buy anything.  If they select the “find recipes I’ll like” side of the scale, they’ll see more recipes they would in theory rate higher, but they’ll be more yellow and red items.  Seeing the data represented in this way will allow the user to go back and make changes to their meal plan criteria if they’re unhappy with the results.  Also, since it’s fairly obvious that very few users will keep an extensive pantry stored online, they’ll be able to quickly scan over the red section and double check if they actually have those items on hand.

A poor college student could very quickly find a week’s worth of meals with the ingredients in their fridge and see what they’ll need to pick up at the store.  Other people might not care so much and just use the results as a quick look at what they’ll need as they check off recipes that sound good to them, or just enter the ingredients they want to get rid of and make sure those ingredients end up in the green section.

This is definitely an area that I’m anxious to get real feedback on from beta users during the coming months.  It’s definitely not an easy user interface to design, but my attempts are based on the customer scenarios that I envision for this feature.  It’s also a good example of a design that caters to the “mature” meal planners, who keep an accurate inventory of their pantry online at all times, while still providing some power to the more casual KitchenPC user.  Either way, I’m happy with this as a “first stab” at solving a user interface paradigm that, to my knowledge, no one has really done yet.