Why quantity and item are separate fields

Storing "3 tbsp white miso" as one line makes a recipe readable. Splitting it into three fields makes it searchable and editable. Here is what that buys.

A recipe extractor can stop at the line. Most do. You get 3 tbsp white miso as a string, it renders correctly, and it looks finished.

It is not finished, and the difference shows up the first time you ask a question.

The question a line cannot answer

What have I got with miso in it?

Against a list of strings, that is a substring search, and a substring search on ingredient lines gives you every recipe containing the letters m-i-s-o somewhere. It also cannot tell you that 3 tbsp white miso and 1 tablespoon miso paste are the same ingredient in different amounts.

Against three fields – quantity, unit, item – it is a question about one column, and the answer is exact.

What the split gives you

Search that means something. The ingredient is its own value, so miso matches the ingredient and not the word appearing in a method step. When a result comes back, Curate can tell you it matched in the ingredients and quote the line, rather than leaving you to find the word yourself.

Editing that does not punish you. When extraction gets a quantity wrong – and on a photograph of a curled page it will – you tap the quantity and change the quantity. You do not retype the whole line, and you do not risk breaking the item while fixing the number.

Facets that are real. Once ingredients are values rather than prose, the app can offer you the ingredients your recipes actually contain, counted. Not a guess at what you might search for: the list, from your own library.

Where it gets interesting

The third field is the one people underestimate: the note. Unsalted butter, softened. Acorn squash, seeded and cut into wedges. The preparation belongs to the item but is not part of what the item is, and keeping it separate is what lets butter match without softened getting in the way.

The cost, honestly

Three fields per ingredient is more work at extraction time and more surface for an error. A parser that only has to produce a line has fewer ways to be wrong.

We think that trade is obviously right, because a wrong quantity you can tap and fix costs you four seconds, and a library you cannot ask questions of costs you the entire reason for having one.

The rule we hold to

Nothing scanned is ever saved unseen. However confident the parse, the editor opens first, and saving is something you do. A machine reading a photograph of a cookbook page is going to be wrong sometimes, and the honest design is to assume it and make the correction trivial – not to assume it is right and make the correction someone else’s discovery three weeks later, halfway through cooking.