Product compatibility unknown for all cards

[jasmeet0817]

What

• [ ] Product compatibility unknown for all cards

Part of

• 506

Screenshot

[monsieurtanuki]

Yeah it's the new score algorithm, with just one possible result. Less confusing for the end-users. :) Let me have a look at that...

[monsieurtanuki]

What about 3245414637696? What are your parameters?

[jasmeet0817]

Yeah it's the new score algorithm, with just one possible result. Less confusing for the end-users. :) Let me have a look at that...

hahaha

3245414637696 also has unkown.

My prefs are default.

[monsieurtanuki]

The default was not that.

You changed the code 4 months ago in #603, and now the default is that all those attributes are "important":

• NUTRISCORE
• ECOSCORE
• NOVA
• VEGETARIAN
• VEGAN
• PALM_OIL_FREE
• LOW_SALT
• LOW_SUGARS
• LOW_FAT
• LOW_SATURATED_FAT
• LABELS_ORGANIC
• LABELS_FAIR_TRADE
• FOREST_FOOTPRINT

It used to be only:

• NUTRISCORE: very important
• NOVA: important
• ECOSCORE: important

I don't know what made you change to 13 important attributes instead of 3, but for instance including FOREST_FOOTPRINT was probably foolhardy.

[monsieurtanuki]

In my tiramisu, the problem seems to be with "vegetarian":

• reset the preferences
• check the tiramisu : unknown compatibility
• turn the vegetarian off
• check the tiramisu : good compatibility

[monsieurtanuki]

Basically if you see "? vegan status unknown" in the product card you'll get an "unknown compatibility" result. Probably your 5 level algorithm was less sensitive to "unknown" attributes than the 3 level version. I'll have a look at it.

[monsieurtanuki]

@jasmeet0817 The big difference I see between you and me (algorithm-wise of course) is that for you, if the status is unknown, it's not a problem unless the attribute is mandatory (in that case only: at best "UNKNOWN"). In my code, if the status is unknown then the result is at best "UNKNOWN", regardless of the importance of the attribute.

That means 3 things:

• your algorithm is more robust to the "unknown" - "this attribute is unknown but it's just important, not mandatory, so we shouldn't return 'unknown compatibility'" - is that good or bad?
• we probably shouldn't put the matching algorithm in off-dart, and rather let developers develop their own criteria
• there should be fine tuning in the smoothie score algorithm

[jasmeet0817]

@jasmeet0817 The big difference I see between you and me (algorithm-wise of course) is that for you, if the status is unknown, it's not a problem unless the attribute is mandatory (in that case only: at best "UNKNOWN"). In my code, if the status is unknown then the result is at best "UNKNOWN", regardless of the importance of the attribute.

That means 3 things:

• your algorithm is more robust to the "unknown" - "this attribute is unknown but it's just important, not mandatory, so we shouldn't return 'unknown compatibility'" - is that good or bad?

I think good.

• we probably shouldn't put the matching algorithm in off-dart, and rather let developers develop their own criteria
• there should be fine tuning in the smoothie score algorithm

Agreed

[monsieurtanuki]

I think good.

@jasmeet0817 Honestly I don't know. As an engineer and as a Frenchman I would say: it depends. If the end-user says "To me, gluten-free is important" and our answer is "this product is good for you, but actually we don't really know about gluten", that sounds ugly. On the other hand, as a vegetarian I'm a bit disappointed by the app because all the soy milks I check have an "unknown vegetarian status" - I expected most of them, if not all of them, to be vegetarian. If we could provide the end-users with a "fix this incertitude" button, that would be grand! We could code both algorithms (robust vs. accurate), and at first switch them on dev mode, what do you think?

[jasmeet0817]

Yeah, lets code both and get some feedback from users to see which one is better. @teolemon can probably help us get user reviews.

One thing though, in Switzerland since many items have a lot of data missing, almost all the products I scan are giving me "Unknown compatibility".

I also think there's a path to contribution from unknown, "We don't know if this product is good for you, help us find out if it is by entering some data, and also help other users in the process", but then again I think that would only work if a handful of products have unknown compatibility. So in France, your algorithm could work out well, but in Switzerland maybe not. Here's a crazy idea, how about country specific logic :D 🤷 But lets do some user validations with a switch in dev mode first 👍

[teolemon]

First: sorry for the delays related to a mobilization on Packaging and Origins related to Eco-Score

• We take time to review the algorithm with @stephanegigandet, in a cross platform manner, and probably add tests, as soon as we get the time
• For Unknown Matches, what about a product completion logic ? We could trigger a specific "Road to Scores" pipeline, directly on the scan card, when mandatory choices are missing (eg: ingredients…) @jasmeet0817
• Soy milks: we're going to have explainability of our unability to respond real soon @monsieurtanuki : https://github.com/openfoodfacts/openfoodfacts-server/issues/6365
• Gluten/Allergies: I'm a tad uneasy with the current handling. We need to be careful about the wording, and I think it should be even more "in your face" for allergens. I'll try to open issues, on allergen first use XP, and wording (and UI tweaks if necessary)

[stephanegigandet]

The default was not that.

You changed the code 4 months ago in #603, and now the default is that all those attributes are "important":

• NUTRISCORE
• ECOSCORE
• NOVA
• VEGETARIAN
• VEGAN
• PALM_OIL_FREE
• LOW_SALT
• LOW_SUGARS
• LOW_FAT
• LOW_SATURATED_FAT
• LABELS_ORGANIC
• LABELS_FAIR_TRADE
• FOREST_FOOTPRINT

It used to be only:

• NUTRISCORE: very important
• NOVA: important
• ECOSCORE: important

I don't know what made you change to 13 important attributes instead of 3, but for instance including FOREST_FOOTPRINT was probably foolhardy.

I think it would make sense to go back to a very small list of defaults (2 to 4 max). All the things like vegan, vegetarian, palm oil, fat/salt/sugar etc. can be opt-in instead of opt-out.

The Nutri-Score and the Eco-Score are good "summaries": the Nutri-Score encompass the fat/salt/sugar/energy etc. levels, while the Eco-Score encompass organic labels etc.

[monsieurtanuki]

@jasmeet0817 Actually you cheated: you never returned "unknown" as a matching result, if I refer to https://github.com/openfoodfacts/smooth-app/blame/53849dbf110c7bb7f3fb2b07d627452ff1902ade/packages/smooth_app/lib/helpers/product_compatibility_helper.dart The only possible results were "incompatible", and a gradient of compatibility level. "unknown" did exist, but was never returned.

For instance, this product has unknown attributes, but "you" say it's compatible.

@jasmeet0817 I was in the process of sending a PR with "the Swiss switch" (from your version to mine), but github with its sense of humour decided not to take it into account. So funny. Anyway, in first approach you can admit a posteriori that never returning "unknown" was not very fair, was it?

[monsieurtanuki]

Please don't ask me why I had no problem sending a PR this morning and could not this afternoon :(

[teolemon]

• 1118

[M123-dev]

@monsieurtanuki interesting and that right after the project was on ice for a few days anyway. I mean we can see that you referenced this issue in the commits, if you wan't I can try if I am able to open a PR with your fork as head repository

[monsieurtanuki]

Thank you @M123-dev, but I managed to PR this morning (another PR, though). I guess something went wrong the other day with my Android Studio, which caused a flaw in the git for that precise PR. So far, I haven't experienced other problems on different PRs.

[monsieurtanuki]

I think it would make sense to go back to a very small list of defaults (2 to 4 max). All the things like vegan, vegetarian, palm oil, fat/salt/sugar etc. can be opt-in instead of opt-out.

@stephanegigandet Back to default being "important" ECOSCORE, NUTRISCORE and NOVA and that's it then?

[teolemon]

We are now back to defaults.

[monsieurtanuki]

@teolemon Preference importance default values are now taken from the https://world.openfoodfacts.org/api/v2/preferences?lc=LANGUAGE_CODE The scores are still computed with 2 distinct algorithms: @jasmeet0817's and mine, to be selected on dev mode. Btw it looks a bit strange that the preferences depend on the language, but not on the country, doesn't it?

[stephanegigandet]

Btw it looks a bit strange that the preferences depend on the language, but not on the country, doesn't it?

The only thing that changes is the translation of the importance levels.

[teolemon]

Typically, for countries where Eco-Score isn't deployed, there's a point.

[monsieurtanuki]

@teolemon Maybe we should divide the world in two: countries with EcoScore, and countries without it. While keeping the translations as they are now according to the language, we could add a distinction EcoScore yes/no according to the country. Which/how many countries support the EcoScore now?

[monsieurtanuki]

@teolemon What about adding a temporary "with Ecoscore yes/no" in dev mode? That way we could play with an app where Ecoscore does not exist - which makes sense for most countries, doesn't it?

[M123-dev]

Like the idea

[monsieurtanuki]

@teolemon Now that the app is able to deal with countries without ecoscore, how could we get the list of ecoscore-less countries?

[stephanegigandet]

I wrote a proposal to adapt the algorithm to classify products: https://forum.openfoodfacts.org/t/proposal-for-a-new-personalized-experience-in-the-open-food-facts-app-and-website/71

In particular it clarifies how to compute the "match" and if some attributes are mandatory, the "compatibility".

• Very good match: 75% and above
• Good match: 50% and above
• Poor match: less than 50%
• Unknown match: if too many of the selected attributes (e.g. 50% of the weights) are unknown.
• Incompatible: only if the user specified a mandatory product attribute
• May not be compatible: only if the user specified a mandatory product attribute

What do you think?

Ideally, please add your comments on the forum post.

Thank you!

[monsieurtanuki]

Hi @stephanegigandet! For some reasons I cannot write to the forum - still waiting for a confirmation email that never came.

Very interesting suggestions! My remarks:

• no problem in smoothie to add the very_important level (that we temporarily removed)
• waiting for the algorithm to normalize the score to 100
• I'm not really obsessed with accessibility but adding a "performance" icon like smiling (or not) emojis would help readability, and make your issue about long titles disappear (text still available with a tooltip). And that could give a little "fun" aspect to the app - 😎 🙂 😞 🤔 😡 (I know, I'm very impressionable, fun-wise)
• "We need to show attributes selected by users instead of having a separate handling to put Nutri-Score and Eco-Score on top": I didn't understand what you mean
• "always score products according to the user’s preferences but no re-order": brillant idea to get rid of the additional click to get what the app is about - products with scores. For advanced users, we can imagine an additional page with tabs, re-ordering or filters
• "do the ranking server side": I've never understood the order of the (non-ranked) products, and either we should say explicitly that we retrieve the most popular products first (which makes sense) or we must implement the ranking server side
• yesterday I was polled about Nutriscore v2.0 (as a member of Étude Nutrinet Santé), and I found very interesting the suggested evolution - just put a black border (with a white text) around the nutriscore logo, for ultra-processed foods (Nova 4 I guess). I was reluctant at the beginning, but I must say that what was finally important to me was ultra-processed or not, and that "black-border bool" was just enough. I don't know how we could build on this idea.

[monsieurtanuki]

With emoji and percentage/score:

[stephanegigandet]

Hi @monsieurtanuki , thanks a lot for the feedback!

I cannot write to the forum - still waiting for a confirmation email that never came.

ah, not in the spam folder either?

Emojis are an interesting idea. :) I guess it all depends on how serious-looking or fun-looking we want to appear.

• "We need to show attributes selected by users instead of having a separate handling to put Nutri-Score and Eco-Score on top": I didn't understand what you mean

Today we show Nutri-Score on one line, then Eco-Score on another line, then after that we have the attribute selected by the users on half lines.

My suggestions is to go back to the personalized behaviour that we had before: if the user says something is mandatory (e.g. "No gluten"), then it should appear first, above the Nutri-Score. And if the users says Nutri-Score or Eco-Score is not important, then we don't show it in the summary card.

The Nutri-Score team talked to us about the Nutri-Score + black border + "ultra-processed" text. We have mixed feelings about it, becauses it mixes 2 things in one. Also if we add the "ultra-processed" text, then we need language specific logos.

But we have the same idea to really highlight ultra-processed (Nova 4), and not really stress out the difference between Nova 1/2/3. We also have a discussion about better icons for ultra-processed foods here: https://forum.openfoodfacts.org/t/what-can-we-replace-the-nova-1-2-3-4-icons-with/60

[monsieurtanuki]

@stephanegigandet Not in the spam folder either.

Ok now I understand: no special treatment for Nutriscore and Ecoscore (except that they are still in the default preferences, that the user can change).

I've just suggested an icon for Ultraprocessed yes/no:

I understand your point about localizing the "ultra-processed" label. I was just saying that the notion of Ultra-processed food is capital (health-wise) and the suggested compact view of both Nutriscore and Ultra-processed was working, for me at least. But it's another context, as we have much more flexibility.

With the Dev Mode we can implement many variations in the app, would you like some of the following to be implemented?

1. get rid of the additional click to get what the app is about - products with scores
2. add the UltraProcessed attribute
3. no special treatment for Nutriscore and Ecoscore

[monsieurtanuki]

I think we can close this issue now as

• we changed the matching algorithm
• the only potential issue is with ecoscore - which is dealt with in #1822.