Producers: filters with multi-select options (as per design)

[kirstenalarsen]

The designs provided showed multi-select in the filters

We are adapting to the styling presented (i.e. happy with the drop-down arrows rather than the + signs, but need multi-select on the filters (as per on the supporting evidence filter)

@mariocarabotta to provide updated design using closer to the styling now presented

[mariocarabotta]

prototype available here > https://www.figma.com/proto/jCheM9rB3tzfdPyIZcmcM9/Engineering-Delivery---Discover-Regenerative?page-id=454%3A23&type=design&node-id=454-26&viewport=-1409%2C582%2C0.55&t=fuA7eSsGs3GINuqK-1&scaling=min-zoom&mode=design

[kirstenalarsen]

@JbPasquier can you give me an estimate on how hard this is please?

[JbPasquier]

@kirstenalarsen asked:

can we also apply this logic to how the Supporting Evidence filter works on the Producer list? This would clean up the problems we are having in a range of other issues

No, the way I implemented it here works because there is really only a small amount of data. It's just one producer's data. If this custom implementation were to filter the entire list of producers, it would take a really long time to filter anything.

The main issue here is the complexity of the data: filtering many certifications within many supporting evidence within many producers (within many products on the other list), combined with an 'and/or' filter.

Maybe we can think of some data adaptation. @mkllnk would it be complex for you to pre-calculate all of this and add three fields directly on a producer/products with all its relevant Supporting Evidence, Assurance Partners and Certifications filters? The same way you did ofn:Produce_category?

[kirstenalarsen]

@JbPasquier Just to be totally sure that we're on the same page before I take up with @mkllnk

The 'Custom Implementation' potentially does two things:

1. it combines information from Assurance Type 'Certification' sit within the filter alongside the Assurance Type 'supporting Evidence'. (I think).
2. It allows multiple select of the criteria under supporting evidence

Re. 1 - we are NOT proposing to do this on the Producers list. So the Supporting Evidence filter does NOT need to check Certifications. We are cleaning up the confusing label so this becomes super clear

SO you are saying it is TOO COMPLEX to just make the Certifications filter multi-select because there would be too much data

AND/OR this is too complex in its own right (as one filter), or the complexity as it interacts with the other filters on the page (e.g. supporting evidence)

[JbPasquier]

SO you are saying it is TOO COMPLEX to just make the Certifications filter multi-select because there would be too much data

Exact.

AND/OR this is too complex in its own right (as one filter), or the complexity as it interacts with the other filters on the page (e.g. supporting evidence)

Both of them.

Both Supporting Evidence, Assurance Partners and Certifications filters share the same complexity: "something" that may be multiple times in "something" that may be multiple times in "something", these kind of search criteria are really expensive due to the fact that we have to "translate" every single step with a proper context.

From a non-technical perspective, let's simplify this as: Client-side complex filtering are heavy and should be pre-processed by the server/API whenever it's possible.

[mkllnk]

Let me know if I'm understanding this:

• You get a list of filter options for each filter from our data.
• You filter the data by one of the options in the browser. For example, if I select a supporting evidence, you go through all producers and all of their supporting evidence to match the label.

What kind of endpoints would be best for you? We could add a list of supporting evidence label to the enterprise record, for example. Or when you call the URL of a specific supporting evidence label, we could list all the enterprises in a container there.

It's a bit more work for me but possible. But I'm also wondering what will be the most flexible for other people building similar portals with slightly different data models... :thinking:

[JbPasquier]

through all producers and all of their supporting evidence to match the label.

Through all producers and all of their supporting evidence and all their certification to match the @id.

The best thing you could add to simplify this filtering would be to add something like that:

{
  "@id": "/regen/producer?id=XYZ",
  ...,
  "ofn:filterSupportingEvidence": {
    "@id": "/webhook/regen/...",
    "@type": "ldp:Container",
    "ldp:contains": [
      {
        "@id": "Matching ids from https://api.regenerative.org.au/webhook/regen/supporting_evidence_classifications"
      }
    ]
  },
  "ofn:filterCertifications": {
    "@id": "/webhook/regen/...",
    "@type": "ldp:Container",
    "ldp:contains": [
      {
        "@id": "Matching ids from https://api.regenerative.org.au/webhook/regen/certifications"
      }
    ]
  },
  "ofn:filterAssurancePartners": {
    "@id": "/webhook/regen/...",
    "@type": "ldp:Container",
    "ldp:contains": [
      {
        "@id": "Matching ids from https://api.regenerative.org.au/webhook/regen/assurance_partners"
      }
    ]
  }
}

This way I can directly match de filter against the producer and avoid comparing it with objects in objects in objects.

This should be enough to have it on producer for products too.

---

But I'm also wondering what will be the most flexible for other people building similar portals with slightly different data models...

It's all about optimizations. In our DjangoLDP world we'd be dealing with this with a complete server filtering solution. Browsers, especially mobile or light terminal ones does not like complex data filtering.