Project:Food Rescue/Features

This pages lists and describes accepted and proposed features of the Storage Life Insights project. Features that deserve more detailed discussion or planning are additionally linked to their own sub-page.

Accepted Features

In order of acceptance.

[TODO]

Proposed Features

Roughly in order of importance. Here, features should only be described functionally, from a user perspective, yet without details about how they would be implemented.

1. Showing per-product expiry duration. This is a low-hanging fruit as the OFF database contains expiry dates but they are not yet shown anywhere in the OFF Android app. The information should be shown as minimum duration, and that information will already help to rescue some food. Example: when crisp bread is meant to last 18 months and it is 2 weeks over the date, it is very probably safe to eat.
2. Showing per-category expiry distributions. From per-product expiry dates, diagrams for each category can be created that show shelf life durations of all other products in the same category, and where the currently analyzed product falls in. That should already allow users to know when they can be more relaxed about a specific product, and would allow them to rescue some food items.
3. Edibility information per category. Open Food Facts has detailed categories of products already, and it seems that they are applied like tags: each product can be in any number of categories. By attaching the expiry information to these categories, it will be simple to provide all food items with relevant expiry-related information. This information should come in multiple levels of detail, from a one-glance label that indicates if a food item's storage life is "problematic" or not, to summaries, to all the details incl. references to journal articles etc.. The multi-level approach allows to write about the most general methods ("smell and taste") in the most general categories of food items, and that information will then be displayed along more specific information (if available). The app would show the most specific content first, then moving to content from the more and more general categories. This way, a user can stop reading when encountering information that they have seen before. The articles would contain:
   • Instructions to assess the edibility of expired food items, including a risk assessment in case of mistakes, and an assessment of how simple or difficult the assessment of a certain category of food is. This (risk and simplicity) should be displayed in a fast-to-understand way, using a kind of self-defined categorization scheme. The idea is that the "risk-free and easy" cases should be encouraging for new users to try, to then work their way up to the others over time.
   • Instructions to detect edibility / toxicity issues with non-expired food items due to decay. Example: the problem about mould inside hazelnut kernels and inside pistachio, and the dangers posed by that.
   • Information about what parts of food items are edible and not. For example, cherry kernels are toxic, while the stalk of broccoli is edible.
   • Information about how to prepare usually non-eaten but edible parts of food items. For example, the core of broccoli stalks can be eaten raw and tastes like celery.
   • Information about special dangers for small children, elderly people or pregnant people or other groups in case of eating spoiled food items. Because that seems to be a concerns of many consumers (inspiration here).
4. Storage information per category. Similarly to the edibility information and probably in the same place, informing consumers about the right storage conditions is also an important method to avoid food waste. These articles would contain:
   • How and where to store various vegetables and fruits in the fridge.
   • How long seafood, raw meat prepared meals and other perishable items are storable in the fridge under what conditions. Basically, how does storage time combined with temperature ("degree hours") affect the storage duration of food items that need cold storage.
5. Waste salvaging information per category. Even when food was spoiled, throwing it away is not necessarily the only option. The same applies to inedible parts of food items, spent coffee grounds etc.. Similarly to the edibility information, articles would inform about potential uses. Any additional use before ultimately throwing away something is waste avoidance and resource protection. Examples include: using spent lemon halves for washing dishes (avoiding soap); using coffee grounds as fertilizer etc.; home-composting all kitchen scraps and food waste.
6. Referencing authoritative sources. For the per-category information articles about edibility, storage and waste salvaging, Open Food Facts will require the information contained there to have "fact status". A simple and proven way to achieve that would be to apply the Wikipedia authoring standards about use of authoritative sources, neutral tone etc.. Because both kinds of texts are about established facts, and not about opinions, original research and the like.
7. Web accessibility of the per-category information articles. The per-category information articles about edibility, storage and waste salvaging will in many cases be the world's best freely accessible articles about these topics. Consequentially, when making them available on the web and not just inside the app, it can be expected that search engines will bring a lot of traffic to them over time. By hinting from these articles to the app, they can become a major publicity instrument for spreading the news about this app.
8. Collecting expiration dates and other printed-on information. The data to collect would include:
   1. Picture of printed-on information. Most food items have only one location where manufacturers print something on the individual, already packaged food item. This includes an expiration date and often other codified information about batch, production location, production date and time etc.. So it makes sense to introduce one more picture data type to let users collect this information, making it available for later transcription and reverse engineering by others.
   2. Field for expiration date (already existing).
   3. Field for the entry date of the expiration date (not yet existing, which is a current data quality issue).
   4. Field for type of expiration date (best-before, use-by, sell-by).
9. Comparison of declared shelf life between products. The "Shelf Life" (German: "Haltbarkeit") tab of the OFF app would contain an article explaining edibility, proper storage etc. and below that an auto-generated section summarizing results inferred from best-before and use-by dates of products in this category. That would include a comparison of the scanned product with other products in the category, showing if there are "better" ones (lasting longer, also without preservatives). This is basically small advertising for products that are not labelled to be thrown away, hopefully nudging manufacturers to provide more real best-before dates. The OFF web interface already has a nice architecture for product comparison with product in the same category. Comparison of the expiration period can be added there easily. See for example here at "Comparison to average values of products in the same category: …". This idea has been discussed before by OFF: "[…] a user inputting production and consumption dates for the same product at the same time would enable us to make averages over time […] that could help see producers which are too conservative […] assuming that all products rot at the same pace (all products that are similar)" (@teolemon here).
10. Counter for rescued food. Basically a feedback form at the bottom of the knowledge article about a food item's storage life, saying: "Did this help you to decide if your food item is still good to eat?", with the following options to answer: "Yes, and I saved it." / "Yes, but I had to throw it away." / "No, I'm still not sure." But of course with better wording and some good gamification – it should make people proud if they rescued food, but also accomplished if they went through the app's information and then decided to play it safe. From this, detailed statistics about the rescued food can be made, including the weight, caloric energy content, approximate market price and approximate embodied carbon emissions of the rescued food. This makes it simple to argue for the success and continuous development of this feature.
11. Usage tracking to estimate rescued food. The "counter for rescued food" feature above required user input to work, which will not come in many cases. To better estimate how much food gets rescued, one could also make an estimate based on usage data from the food rescue features, registering when somebody goes to the "Shelf life" tab, and how much people scroll and read there. This kind of tracking however has a bad reputation for a reason, so either there should be a surefire way to anonymize these statistics, or data should be collected in a different way. For example, people might have to fill the feedback form of the "counter for rescued food" feature for a former food rescue attempt in order to see the "Shelf Life" information for another product.
12. Fast selection of barcode-less products. Options include image recognition or (probably faster and more accurate) to enter the food item as text, such as "banana".
13. Using expiry dates for shopping list planning. Another way to fight food waste with the help of the OFF app and expiry information would be a feature that warns about shopping list items or shopped items if they are in danger of rotting away before being eaten. That estimation would be made based on a configured number of people and meals and perhaps with feedback of what had to be thrown away during past shopping trips. Not everyone writes a shopping list before shopping, but (1) people can just very quickly select their usual items from past shopping lists and (2) people can also add to the shopping list during the shopping by simply scanning the item. The inspiration is from here. Probably, this feature has no place in the current OFF Android app. But perhaps there is an existing, open source, OFF based shopping list app where it can fit in. Another problem is that this feature proposal could be too tech-centric. People might just not use it as it might never be comfortable enough to use. It might find its niche in purchasing operations for small restaurants, maybe.
14. Asking questions about food edibility to experts. This would take the form of a feedback form below the articles on edibility and storage life where users can input unanswered questions. Users will then be notified in their app when somebody researched and entered the answer. The list of currently unanswered questions would be shown below the article, to make it clear what research and authoring work contributors are welcome to do.