Custom columns, serving-size-aware food search, and food comparison

When logging food, I would love more control over the search results table.

Right now, when searching for foods, it can be difficult to compare items quickly. I often want to know things like:

  • kcal per 100 g
  • protein per 100 g
  • carbs per 100 g
  • fat per 100 g
  • category
  • fiber
  • sodium
  • selected micronutrients

It would be great if users could customize which columns appear in food search results.

Even better, Cronometer could let the user enter a serving size directly in the search view.

For example:

Search: “Greek yogurt”
Serving size: 400 g

Then the search results could show each item’s nutrition for that entered amount:

Food kcal for 400 g Protein Carbs Fat Source
Greek yogurt A 240 40 g 16 g 0 g NCCDB
Greek yogurt B 380 32 g 22 g 18 g CRDB
Greek yogurt C 300 36 g 20 g 8 g USDA

This would make it much easier to compare foods before adding them to the diary.

In addition to custom columns, it would also be extremely useful to select two or more foods directly from the search results and open a detailed comparison view.

For example, if I search for “Greek yogurt” and find several similar entries, I could select two of them and compare their full nutritional profiles side by side. Not just kcal, protein, carbs, and fat, but also micronutrients, serving sizes, database source, completeness of data, and maybe even a “data quality” indicator.

Something like:

Nutrient Greek yogurt A Greek yogurt B
Calories 240 kcal 380 kcal
Protein 40 g 32 g
Carbs 16 g 22 g
Fat 0 g 18 g
Calcium 480 mg 390 mg
Sodium 140 mg 260 mg
Vitamin B12 1.8 µg Unknown
Data source NCCDB CRDB
Data completeness High Basic label only

This would be especially helpful when choosing between branded foods, generic database foods, and richer entries from NCCDB or USDA.

Right now, comparing multiple entries can involve opening one item, checking the details, going back, opening another item, checking those details, forgetting what the first one said, opening the first one again, questioning your life choices, and eventually just picking the one with the nicest name.

A built-in comparison feature would make Cronometer much faster and more useful for meal planning, ingredient comparison, and choosing the most accurate food entry.

It would also pair really well with the first feature request about finding better replacements for scanned foods. If Cronometer suggests a richer NCCDB or USDA match for a barcode item, the user could compare the scanned product and the suggested replacement side by side before deciding whether to use it or enrich the original entry.