Recipe Selection

Recipe selection essentially is a feature based filtering task. There are many features that can be used to select a recipe. Perhaps the list of features that can be used is endless. This makes this particular task already very different from a traditional slot filling task. Where in such tasks the system can ask for information to fill a slot that is still missing, in a recipe selection task the system at best can suggest a feature to a user. The user then can decide whether to follow-up or not on such a suggestion. In this sense, the task is much more user-driven than the typical system-driven approaches for tasks with a fixed and limited number of slots (e.g., like planning a bus trip, where destination, origin, time, duration, and price are typical slots to fill).

Recipe websites offer many different ways of navigating the recipes that they offer. For example, the well-known recipe website All Recipes offers just two ways of selecting a recipe: by means of a visually displayed list of types of recipes and by means of ingredients. The Food Network forces a user to first select a type of recipe based on a list of various but also very restricted number of features and then provides three additional features in its advanced search capability including difficulty (easy, medium, hard), and preparation and cooking time. Both websites compensate for only offering this limited number of features by also offering a generic keyword based search mechanism. Yummly offers various recipe selection strategies on its website, including one focused on personalization based on user characteristics on its main page (features include favorite cuisines, allergies, diets, ingredients to exclude, cooking skills) and a pantry-based selection strategy based on the ingredients you already have available in your pantry (you can enter a list of ingredients you have). The website Epicurious offers keyword search for ingredients and drop-down menus with filters for selecting recipes (including categories such as ‘popular’, ‘meal & course’, ‘dish type’, ‘dietary concerns’, 'ingredient', 'cuisine', 'holiday', 'technique'). Finally, Tasty offers something very similar but with a different set of filters (including categories such as ‘popular’, ‘right now’, a short list of ‘ingredients’, ‘diet’, ‘meals’, and ‘holidays’); at the bottom of the main page it also offers an index-based ingredient filter for recipe selection with a long list of alphabetically sorted ingredients.

One of the key issues of using a website is that they the type of features they offer for guiding the search process is fixed and cannot be changed by a user. Ideally, a speech-based system should lift this type of restriction as it is hard to make transparent for a user which features such a system supports for searching a recipe. This poses a challenge, however, as the list of features seems endless and a speech-based system will very likely end up sometimes not understanding one of the features a user would like to use for recipe selection. In such cases a repair mechanism needs to be available. To address the challenge itself a list of possible features is needed as well as an approach for filtering recipes based on those features. Some of the features that can be used to select a recipe include:

• type of ingredients (to include and/or exclude),

• availability of ingredients (“what's in your fridge” search, this may include checking your pantry as well as the local and seasonal availability of ingredients),

• number of ingredients (a proxy for the simplicity of the food to be cooked),

• type of course or meal type (e.g., appetizer, dessert, lunch, cake, etc.; often related to the time of day the food will be consumed),

• cooking style (slow cooking, make-ahead, leftover, etc.),

• difficulty of the recipe (what levels should be distinguished here? or: what levels could a user possibly choose to use?),

• techniques used in a recipe,

• length of a recipe (e.g., number of steps as a proxy for duration or difficulty; one difficulty here is how to count the steps in a recipe as many instructions contain one or more simpler steps that may need to be performed),

• preparation and/or cooking time,

• a keyword,

• budget,

• type/availability/number of utensils (e.g., a one pot recipe),

• origin of the recipe (e.g., author, region, cuisine),

• fit with event (e.g., season, holidays such as Christmas, etc.),

• fit with wine or other drinks,

• nutritional value, or nutritional requirements,

• user characteristics such as e.g. following a particular diet (e.g., vegetarian), having allergies (e.g., lactose intolerance), cooking skills (which obviously is linked to the difficulty of and techniques used in a recipe listed above), etc.

At spoonacular you can also find a list of items to sort recipes on and a list of meal types.

Part of the difficulty for developing a comprehensive recipe selection system, however, is not just the sheer number of features. The list above is pretty complete and far exceeds the number of features offered on the websites we discussed earlier. But perhaps more so the almost endless list of values for each of the features that such a system should be able to recognize. To mention just one less common but yet also very difficult feature to implement is the type of grape used for making a wine that a recipe should match with. It is not clear in this particular case whether there is a database available that would support resolving such a search query… Clearly, in any case, multiple databases that include very different types of information would be needed to come even close to being able to adequately respond to particular feature requests for recipe selection from a user.

Finally, there is the issue of how a user can navigate the recipe selection task. Websites often fix the order of the features that can be used to search for a recipe. Such an approach is not so natural for a speech-based assistant. However, if we want give a user more control over the order of features chosen to search and refine a list of recipes, we need to ensure that it is transparent to a user which features can be used to do so. Moreover, we need to support a user by displaying the feature instances that have been selected thus far as it is not reasonable to assume that we can rely on a user’s memory. Finally, it is important to allow a user to remove or change a feature instance, for example, because there are no recipes that match with all the chosen feature instances thus far. This is in line with the 6th golden rule of Shneiderman which states that good interface design “permit[s] easy reversal of actions”.