Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Listing problematic attributes for obscure matches #785

Open
monsieurtanuki opened this issue Aug 12, 2023 · 7 comments
Open

Listing problematic attributes for obscure matches #785

monsieurtanuki opened this issue Aug 12, 2023 · 7 comments
Labels

Comments

@monsieurtanuki
Copy link
Contributor

Why - Problem description

cf. @teolemon's openfoodfacts/smooth-app#1118
When we try to match a product with the user preferences, sometimes we get an "unknown match".
We just know it's unknown, and we don't list what is missing for a correct yes/no match.

What - Proposed solution

Instead of just saying the match is unknown, we should list which attributes are missing.

@monsieurtanuki monsieurtanuki self-assigned this Aug 12, 2023
@teolemon
Copy link
Member

teolemon commented Aug 12, 2023

Well, if we could have something pedagogical about the computation as well. I'm unsure whether we'll be at ease showing it to users at first, but it would be interesting to have in Dev mode.

@monsieurtanuki
Copy link
Contributor Author

@teolemon Understood: I will extend that principle to "may not match" and "does not match".
For the record there are 8 different cases for 6 different match statuses (very good, good, poor, unknown, may not, does not), and in 3 cases we put "unknown" (no attributes at all, at least one mandatory attribute that is unknown, too many unknown attributes).

@monsieurtanuki monsieurtanuki changed the title Listing unknown attributes for unknown matches Listing problematic attributes for obscure matches Aug 12, 2023
@monsieurtanuki
Copy link
Contributor Author

@teolemon @stephanegigandet Btw I think there's a flaw in the score computation, as we loop on the product attributes but not on the preference importances.

That means that a mandatory preference is ignored if the product doesn't have the related attribute at all.

It's OK as long as a product has

  • either no attributes at all (probably a corrupted product), as we flag it as "unknown"
  • or all the attributes populated.

@stephanegigandet
Copy link
Contributor

@monsieurtanuki The server always compute all attributes so we should be fine.

@stephanegigandet
Copy link
Contributor

I'm not sure if creating a separate list with explanations is the right approach: that kinds of duplicates the information we have on the attribute cards that are displayed on top of the product page.

e.g. on the website we have something like that on top of the product page:

image

Related to that, is it planned to add the % score on the mobile app, like we have on the website?

Could we also adopt the same translations on the website + app for the strings like "Does not match" etc. e.g. in French on the app we have "Pas de compatibilité" while on the website we have "Ne correspond pas"

@monsieurtanuki
Copy link
Contributor Author

@stephanegigandet You're right, there's some kind of duplication here, and it may not be necessary.
Maybe I over-interpreted the initial needs.
I needed this step though, to understand the product score/match computations.

Basically there are 3 reasons why the product match is unknown:

  1. no attributes at all - let's say it's not the most interesting case
  2. unknown mandatory attributes
  3. "too many" unknown attributes ("too many" means "sum of factors for unknown attributes >= sum of factors / 2")

It's easy to detect which attributes have an unknown match, and which are mandatory.
But it could be a frustrating experience for the user if you say: "there are unknown mandatory attributes, please 'fix' them to get a correct match". And then to say "oh it's not enough anyway as there are too many non-mandatory attributes" (cases 2 and 3 at the same time).

What can be done is just providing extra data in the "unknown" cases, with 1 bool stating if there are too many unknown attributes.
With that, the developer (e.g. in Smoothie) will be able to detect in which "unknown" cases we are (1, 2, 3, or 2+3), and has enough data to loop the attributes checking which are unknown and which are mandatory.

@monsieurtanuki
Copy link
Contributor Author

Let's try to code directly in Smoothie first, and then move some code here if relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

3 participants