Mobile App/Core attributes: Difference between revisions
(Created page with "== Core attributes of the app == * People expect nonobtrusive experiences from Open Food Facts (access to information not blocked by login, but also, very easy path to sign-up...") |
No edit summary |
||
Line 11: | Line 11: | ||
* Scan requests should be specified as such to the server, with an HTTP header. They should use the fields= API to minimize payload. | * 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 | * Spec not yet developed in Scanning barcodes | ||
[[Category:Mobile]] |
Latest revision as of 10:18, 6 August 2024
Core attributes of the app
- 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). (See the plan to integrate OFF and OBF)
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