The recipe table was conceived by our desire to develop a kitchen based recipe-search application. We all enjoy cooking and the idea of trying out new recipes is a frequent topic for conversation but it also came to our attention that we more often than never stop at this and these new recipes remain unrealised.
So how come we so rarely try out new recipes? Our answers to this question were pretty much along the same line:
Trying out a new recipe requires decision and planning ahead. It requires new ingredients – a trip to the store - which means investing time and money. The most common scenario, that kept coming up, was that we were often willing and even enthusiastic about cooking something new but less so about the organisation and the investments entailed - for example the buying of certain ingredients that are not part of our existent repertoire.
Coming up with recipes containing solely the pre-existing ingredients in our cupboards ended in vast searches through recipe books, compromising missing ingredients. Even the Internet failed to offer us satisfactory search results based solely upon our input. We found no way of answering a search for recipes by ingredients that did not assume extra ingredients!

And here was a problem we found interesting to solve. Not only a database of recipes listed by ingredients but also an appropriate search-method was called for.

Looking for a method to navigate this recipe by ingredients-search we agreed to distance ourselves from preconceived HCI methods. We aimed to come up with an intuitive, informative, efficient and communicative search method that can be fully integrated into the kitchen environment.

Product identification, both Barcode and RFID technology, offered us the perfect condition for implementing products, the ingredients themselves, as tangible navigation elements within a human-computer as well as an interpersonal interaction scenario.

We designated a section of kitchen workspace as the surface upon which interaction takes place. We have a recipe-database stored on a hard drive which can be updated over the Internet, this enables constant maintenance. In the best-case-scenario this database contains every existing recipe and access time is always immediate, the software recognises and can identify every existing product within the workspace either via a camera that recognises Barcode or RFID scanners for RFID tags. Produce and otherwise untagged ingredients are in this case tagged / or can be tagged by the user/s.

The recipe table reacts when ingredients are placed within the workspace by identifying these and searching its database for recipes containing solely these identified ingredients plus editable basics such as water, salt, oil..
matching recipes are displayed on a touchscreen to the right of the workspace seamlessly built into the counter top to minimise dirt and damage.

The products within the workspace are used to navigate through the list of recipes. The recipes are listed in respect to ingredient relevance. Ingredients nearer the user/s are more important to the user and those further away are less important meaning that the ingredients within the recipes also receive an importance.
For example (water, oil and salt are given):
There are eggs, flour and tomatoes within the work surface and the tomatoes are near the user, the flour in the middle and the eggs furthest away a top-ranking recipe might be >breaded tomatoes<. If the tomatoes and eggs exchange positions the recipes list reorganises itself and >stuffed eggs with a tomato paste< might be a top ranking result. And if all ingredients are central then >home-made noodles in tomatoes sauce< might make the top of the list.
Navigation proceeds until the user decides on a recipe from the list. Products can be removed or added to the workspace at anytime and changes result in immediate feedback via the touchscreen.