Difference between revisions of "Project:Food Rescue/Features"
Jump to navigation
Jump to search
(initial content) |
(adding features; improving descriptions) |
||
| Line 7: | Line 7: | ||
== Proposed Features == | == Proposed Features == | ||
| − | Roughly in order of importance. | + | 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. |
| − | # ''' | + | # '''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. |
| − | # '''Comparison of | + | #*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. |
| − | # '''Asking questions about food edibility to experts.''' | + | #'''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. | |
| + | #'''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. | ||
| + | #'''Collecting expiration dates and other printed-on information.''' The data to collect would include: | ||
| + | ##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. | ||
| + | ##Field for expiration date (already existing). | ||
| + | ##Field for the entry date of the expiration date (not yet existing, which is a current data quality issue). | ||
| + | #'''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 [https://world.openfoodfacts.org/product/4001686386613 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 [https://openfoodfacts.slack.com/archives/C17324N0L/p1462730965000039) here]). | ||
| + | # '''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." 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. | ||
| + | # '''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". | ||
| + | # '''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. | ||
== Footnotes == | == Footnotes == | ||
<references /> | <references /> | ||
Revision as of 22:01, 5 March 2020
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.
- 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.
- 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.
- 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.
- 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.
- Collecting expiration dates and other printed-on information. The data to collect would include:
- 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.
- Field for expiration date (already existing).
- Field for the entry date of the expiration date (not yet existing, which is a current data quality issue).
- 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).
- 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." 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.
- 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".
- 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.