...
Part of the difficulty for developing a comprehensive recipe selection system, however, is not just the sheer number of features (the . The list above is pretty complete and far exceeds most the number of the features offered on websites) but 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”.