(Proposal) Compatibility with Open Beauty Facts and others

[teolemon]

What

This is an early proposal to establish compatibility with Open Beauty Facts and others, at the most minimal cost possible.

Phase 0: establishing a feedback loop by deploying clones to internal

• Prepare GitHub Actions pipeline for internal build for OBF, OPF, OPFF #3923
• Add icons and visuals for all variants to the source code

Phase 0.5: ensuring the Dart package behaves well

• Ensure that when the base URL is on openproductsfacts.org we don't crash on lacking nutrition, ingredients… (that shouldn't actually be an issue)

Phase 1: tweaking core behaviours based on a forced project type

• Add a DEV mode switch to return a force project type for all products for testing/development purposes ( "off", "obf", "opf" and "opff")
• Override Open Food Facts mentions by Open X Facts based on project type
• Change the base URL based on the DEV mode project type

Phase 2: tweaking the UI to handle multiple project type at the same time

• Database migration to add a project type to all current products in the local database ("off")

• Add a project switcher to history (based on project type "off", "obf", "opf" and "opff")

• Add a project switcher to search (and store the type on each product opened "off", "obf", "opf" and "opff", and for any search we store locally)

• Add a project switcher to scan (and store the type on each product scanned "off", "obf", "opf" and "opff")

• Add a project switcher to Food Settings (we might want to disable customization completely for other projects, since there's no much value to bring to the users, and to save time)

• We probably do not need to add anything to lists (as they can potentially contain items from any project)

• Search results / ListView

  • Disable Eco-Score and Nutri-Score display if project != off

• Make local Open Food Facts specific behavior conditional to the product type

  • This can be done over time

• Strings

  • Add overrides to strings (let's avoid editing existing strings to avoid loosing translations)

• Make the edit mode of the mobile app compatible with OxF #4540

  • Compare to category should invoke the right search type, in line with the product type
  • Links to promotional content or to the user's profile should not be changed. Not enough value, and we can potentially add shortcut or additional paragraphs on the web-side
  • Add Period after Opening support for obf

Mockup

[VaiTon]

What if we do the scan part automatically, without having to ask the user? We could create and endpoint on the server that checks every db for the matching barcode.

The history one could be done with ease if we have them categorized in the db but maybe we could implement it like a filter field among other ones like "sort order", "date of scan", ecc..

[VaiTon]

Also linked to #1254

[teolemon]

This is a solution that assumes 0 engineering time on the server side while doing the job. Further down the line, it does not preclude a tighter integration to increase speed/magic.

[teolemon]

@VaiTon @g123k @PrimaelQuemerais @monsieurtanuki I've edited the proposal and added mockups with the new identity

[monsieurtanuki]

@teolemon Beyond the fact that I wouldn't be interested in an app that manages food, cosmetics and pet food at the same time (who would?) (I mean, it's a niche) (especially pet food 😸), some more technical points:

1. indeed we could add a source text column in the local database product SQL table, as anyway so far we store the barcode, the raw data as blob and a timestamp. 'off' blobs would be decoded as "off Products" (like now), and so on.
2. I don't know if there's such thing as pet food preferences, but if so that may cause confusion for the end user (and for us developers too)
3. for the moment there are no obf-dart and so on projects, are there? We need them if we want to display properly a "obf" Product or to run obf queries

[M123-dev]

@teolemon Beyond the fact that I wouldn't be interested in an app that manages food, cosmetics and pet food at the same time (who would?) (I mean, it's a niche) (especially pet food 😸), some more technical points:

I can agree with @monsieurtanuki but I totally understand the point but from a user standpoint I don't want to switch between those and I don't want to be promted with all the options on multiple pages when I am just interested in one of the open x facts services.

I know it needs much work on the backend but I would rather prefer this to be done automatically.
When I scan a barcode or search something I expect a answer and not another question namely what category it belong to.

Another option would be to keep it as in v1 with multiple apps but that again causes other problems.

[monsieurtanuki]

Or put in the preferences the off/obf/o_f choices, and open a dialog: "hey, you seem to like food at lot, have you ever considered dog food?", with a "no way!" button.

[teolemon]

• The main target would be cosmetics + other products. The idea is to turn the app into something that can handle any barcode, as smoothly as possible @monsieurtanuki
• There's also a moderation consideration for product addition. If we can route the products to the right project, we reduce moderation work down the line (moving products). Currently users are adding Cosmetics from Open Food Facts to Open Food Facts
• As you guessed @M123-dev , The clunky implementation where we leave the user in charge is a way to avoid requiring any server changes, and server-side re-engineering. It would be in my view a transitional measure, especially for scan (we probably want to keep cosmetics and food separated for other features like history)
• Another option could be to flavor the codebase, and generate separate builds. That would allow us to retire Open Beauty Facts (Cordova) for iOS, Open Beauty Facts (Native) for Android, and potentially Open Pet Food Facts and Open Product Facts (native) for Android and replace those by Flutter based builds, properly flavored. I probably would not launch Open Pet Food Facts and Open Products Facts flavors for iOS, but rather wait for a proper sandwiching of the apps to be done.

[monsieurtanuki]

@teolemon Unexpectedly, my very recent PR #2609 would be helpful. In short, it says "product lists are barcode lists, then you ask the card widget to display the product associated to that barcode".

That mean we could have smoothly (haha) products from different sources, lists will be barcode lists in all cases, and it's the job of the product card widget to

• load from that barcode the product json data and the (to be created) product source (e.g. off, obf) from the database
• create the correct object from it (Product for off, BeautyProduct for obf)
• display slightly differently a Product and a BeautyProduct, as a card and as a page

As I said before, the first step is to create obf-dart. Which will probably be as stupid as off-dart: in short, just build URLs with parameters and decode the json.
off-dart and obf-dart could completely be independent projects (modulo the user / login / register methods?): all we need is at some point to be able to query a beauty product and to decode a beauty product json into a beauty product. And we'll decide which to call depending on the source column in the local database (read) or the user choice (create).
Anyway, there's no server-side re-engineering induced. Each server will continue to work on its dedicated field, and it's just Smoothie that wants to potentially use several (similar) servers at the same time.

[teolemon]

@monsieurtanuki @M123-dev @g123k
https://fr.new.openproductsfacts.org/
https://fr.new.openbeautyfacts.org/
https://fr.new.openpetfoodfacts.org/

[monsieurtanuki]

@teolemon Currently we don't rewrite the subdomains very often. Typically it would be when we link to a product page on the website.
If we had to add a .new. item when we rewrite the subdomain, we need to change slightly the code for some domains (e.g. openpetfoodfacts.org).