Structuring a Cooking Website

Before reading this article, I recommend that you read my general article on information architecture.

In this example, we will lay out the information architecture of a cooking website. For the example, we will assume a website that allows users to submit their own contents.

Information hierarchy

The information on a cooking website can generally be divided into three types:

• Individual recipes. There can be hundreds, even thousands, of these. Many of these recipes can be for the same thing, but with different major or minor variations.
• Articles with background information. This can be everything from information on creating a balanced diet to best practices on how to store cooked food. Generally, there will only be one article on each topic.
• Additional database information used by the individual recipes. This can for example be the nutritional information of different ingredients, so that the website can automatically calculate how many calories are in each recipe.

Because the recipes and articles are inherently different in both quantity and nature, they will need to be analyzed separately. The database information will not be presented in itself, and will therefore not need an information hierarchy.

Recipes

Recipes are difficult to structure in a tree hierarchy.

One approach to sorting the information could be according to which time of day the dish would be served. This creates an immediate issue since many dished can be served for several courses. For example, pancakes can be both breakfast, brunch, dinner, and dessert.

Another approach could be according to the type, such as soup, cake, bread, beef, poultry. This merely shifts the previous issue, however. For example, is chicken soup categorized under soup or poultry, and is traditional lasagna categorized under pasta or beef?

A more general issue is that, because of the potentially very large number of recipes, going through long lists will not be a very user friendly approach.

Instead of a tree hierarchy that users browse, a cooking website can easily get away with using only a search engine as recipe. In order to improve this search engine, and to make it easier to users to find related recipes, the recipes can instead use a polyhierarchy.

Recipe polyhierarchy

There are two key considerations when creating a polyhierarchy:

• Which tag categories should be created?
• Should users be able to submit new tags?

Selecting the tag categories is similar to setting up a traditional navigation structure. It is easy to get carried away, and create a lot of detailed categories. While this will theoretically provide a lot of useful data, getting people to fill them out will often be difficult. This is especially true for a website where a lot of the content editors will not be very technically minded. Users searching for information can also become confused if there are many filters that they don’t need very often. Having four or five filters that are always filled out will be much more useful than 20 filters that are never filled out.

For this example, we will use three categories:

Ingredients, tagged directly from the ingredients list, with quantities added separately.

Meal type, with tags such as breakfast, supper, and dessert.

Diet, which can be tags that refer to both chosen diets, such as vegetarian and vegan, and allergies, such as lactose intolerant friendly and gluten free.

We may decide to add more categories in the future, based on user input. It is always easier to give users something extra, than to take away something they already have.

Now that we have the categories, we need to decide whether to allow users fill in their own, new tags, or if we want to limit their choices to existing options.

In out example, the Meal type and Diet categories will likely be fairly small, and will rarely require new additions, so we don’t need to allow user input here. For the ingredients, however, it would be a herculean effort to think of every possible ingredient, and we would likely get swamped with requests for new tags. It would therefore be wise to allow users to submit new ingredients. We can then go through the tags once in a while and merge duplicates. To avoid too many duplicates, we can use type-ahead, to that then a user starts typing, e.g., ‘flour’, a list of existing flour tags is shown for the user to choose from.

Articles

Because there will generally only be one article covering a given topic, it makes sense to allow users to browse through the articles using a menu with a traditional tree hierarchy.

In order to determine the menu categories, it will be necessary to ask users. This can be done by using card sorting, in which users group existing contents according to their preferences. This provides valuable input for determining how to create the web site’s menu structure so that it is as intuitive as possible.

For this example, let us assume that we have these three categories:

Cooking gear, for articles about how to best use cooking equipment.

How do I…, for tips and tricks, such as how to pickle things, how to handle different types of food, etc.

Dieting, for articles on how to follow specific diets.

Having a tree structure does not mean that the articles should now be tagged. Because of the inherently very varied subjects of the articles, simply allowing the author to enter the tags they find relevant into a single category (with type-ahead) will likely be the best solution. Users should of course also be able to search through the articles.

Templates

To ensure a uniform structure, a standard template for writing recipes into the database will be a necessity. In addition to ensuring a good data quality, this will also allow editors to focus on writing the recipe.

One possible template could be a simple form, with the following sections:

• Title
• Table of ingredients
• Step-by-step list of how to prepare the dish
• Tags

Again, such a template should be kept simple in the beginning, and then listed to the users’ feedback.

Wireframes

Front page

Search results

Article

Recipe