Mobile App/Classic App Features: Difference between revisions
No edit summary |
No edit summary |
||
| Line 7: | Line 7: | ||
=== Feature proposals === | === Feature proposals === | ||
* | * People expect nonobtrusive experiences from Open Food Facts (access to information not blocked by login, but also, very easy path to sign-up, login and X device sync, which we don’t offer). | ||
* We also want the app to feel very reliable, and it should never feel unresponsive, slow, of disconnected. | |||
* People expect value added deciphering, in context, and they need to feel the advice is personalized for them. | |||
* This advice should be available in any condition, especially if the product has been scanned. A modicum of all the database should be available offline, and everything that has been seen before should be stored for instant viewing, with mechanisms to purge. | |||
* The app should make provisions to accommodate non-food products in the future (cosmetics, others). [https://docs.google.com/document/d/1A2_7pmQsf0tgZtc-wFyIatmAp1B1Vx4HWjPV-YhB-KE/edit?folder=0AKlNOF6mg0SMUk9PVA#heading=h.sxfdhqwwmjz9 Enabling cosmetic scan in Open Food Facts] | |||
=== Scan === | |||
* Scan should be continuous, and instant (with a local copy of the essential information available offline), in all directions, and work in bad conditions (low light, bad camera, 90 angle, broken main camera) | |||
* The result should display what it currently does on Android: Nutri-Score, NOVA group, CO2, # of additives (along with a first time explanation to scroll up the scan card for more details and explanations), diets if not disabled, and allergen warnings if enabled | |||
* Scan requests should be specified as such to the server, with an HTTP header. They should use the fields= API to minimize payload. | |||
* Spec not yet developed in [https://docs.google.com/document/d/1nxjyZD8NKM28w1J5LPhMybIRiw1t-31gB3mq39XtFxw/edit#heading=h.i30n16ffe7z1 Scanning barcodes] | |||
=== Product addition === | |||
[https://docs.google.com/document/d/11tonHzTULR1U6Uw9g4nrB0lZPHUVJCAOdBER1rvombk/edit#heading=h.nu8whmfkeagw Product addition] | |||
=== Ingredient analysis (vegan, vegetarian, palm oil, and more in the future) === | |||
[https://docs.google.com/document/d/1vYiuBULPkH1ubc9IOotWeVC6pdNySvFntSGItVO8U2I/edit#heading=h.8w5kgur0z0ne Ingredient analysis specification] | |||
[[Category:Mobile]] | [[Category:Mobile]] | ||
Revision as of 19:00, 2 May 2021
Current features
- Product scan
- Ingredient analysis
- Scan history
- Editing
- …
Feature proposals
- People expect nonobtrusive experiences from Open Food Facts (access to information not blocked by login, but also, very easy path to sign-up, login and X device sync, which we don’t offer).
- We also want the app to feel very reliable, and it should never feel unresponsive, slow, of disconnected.
- People expect value added deciphering, in context, and they need to feel the advice is personalized for them.
- This advice should be available in any condition, especially if the product has been scanned. A modicum of all the database should be available offline, and everything that has been seen before should be stored for instant viewing, with mechanisms to purge.
- The app should make provisions to accommodate non-food products in the future (cosmetics, others). Enabling cosmetic scan in Open Food Facts
Scan
- Scan should be continuous, and instant (with a local copy of the essential information available offline), in all directions, and work in bad conditions (low light, bad camera, 90 angle, broken main camera)
- The result should display what it currently does on Android: Nutri-Score, NOVA group, CO2, # of additives (along with a first time explanation to scroll up the scan card for more details and explanations), diets if not disabled, and allergen warnings if enabled
- Scan requests should be specified as such to the server, with an HTTP header. They should use the fields= API to minimize payload.
- Spec not yet developed in Scanning barcodes