Integrate location type categories

[wbazant]

On live site, the "Show invasive species only" functionality is out of sight until zoomed in, and there are magic links leading to a portal with a different map.

The current solution in the beta is two checkboxes partially ported from live site. They are more prominent and I think they confuse the user - they get in the way, and offer explanations in pop-ups.

The magic links could be part of the UI and thus discoverable.

Some potential goals for the UX include:

• the default choice for categories stays out of the way until the user is ready (the non-default options like "Include municipal tree inventories" and "show invasive species only" are slightly further away from the UX of a first-time user)
• user learns to strategically choose groups of markers (e.g. decide to enable tree inventories to get more hits)
• discovery of categories introduces communities and lifestyle ideas (e.g. learning about that /grafting category might lead to someone trying grafting themselves)
• user can inform themselves on what the categories are

There's a list of all categories at #246. The categories are partially overlapping and nonexhaustive, suggesting tag semantics.

[wbazant]

I've had an assistant make a mock-up for this, the suggestion is to put categories in a tag cloud between the search bar and "On The Map". Replace "Select all" and "Unselect all" with the semantics of tags (you can click All to select all, and then again to deselect it) and make "Invasive" a category again. Bring in other categories that the live site uses too.

The "Include tree inventories" can stay at the bottom as a data source related option.

https://chatgpt.com/c/355bbf2d-732b-45ed-b89d-b2aa942f3d24 https://codepen.io/Wojciech-Baant/pen/mdYRjbb

[wbazant]

@ezwelty screenshot above!

Initiative doc: https://docs.google.com/document/d/1ah6jKO9uizBqeBtTVoIXi51gpYEQEyYzzastcMKOp5Y/edit?pli=1#heading=h.cbt21puyoh05

[ezwelty]

I disagree that "invasive species only" is a type category, because whether a type is invasive depends on the location. Thus, like "include tree inventories", it is a location-level filter rather than a type filter. The reason it is not currently available at the cluster-level zooms is that, unlike location.muni, separate clusters are not currently computed for location.invasive true and false in each grid cell. Frankly, the data behind the invasive filter needs an overhaul (e.g. only data for US, out of date), and until then, it may be best to just hide it...

However, I'm very supportive of integrating type categories (and making forager + freegan the default). This requires a change to the API (see https://github.com/falling-fruit/falling-fruit-api/issues/10) and a UI like you suggest. Categories are forager, freegan, grafter, honeybee; what is community in your mockup?

In a second step (or directly, if you prefer), we could extend the concept of categories to the more general type lists (see https://github.com/falling-fruit/falling-fruit-api/issues/9 and https://docs.google.com/document/d/1ah6jKO9uizBqeBtTVoIXi51gpYEQEyYzzastcMKOp5Y/edit?pli=1#heading=h.cbt21puyoh05).

[wbazant]

Glad to hear you like the cloud tag design! So, updating the mock- up a bit: I suggest about five categories and a "more" expanding it to about ten. The default categories would be aimed at a new user - simplifying their interaction with the types tree, telling them what's on the site, highlighting something that could be missed but is especially valuable to advertise, and so on - and the extra categories would be interesting rabbit hole type things like grafting or honeybee. Then eventually the "more" element could be replaced with an "edit" element where a user can browse through a big list of categories, possibly also add their own, and configure the tags they want shown.

"Community" was meant to include seed libraries and community gardens, changed it to "Initiatives". I don't have a strong idea on what categories to put in, except I think the default ones should be aimed at a casual or new user, because they'll be very visible - and the extra ones should help us move over /grafting and /honeybee from the live site.

The mock-up hides the invasive filter, but maybe the functionality can come back through the back door, as lists of the type "Invasive edibles in California". I see what you mean about it being location dependent, which doesn't quite map to my concept of invasive species - I just think of them as a subcategory among plants I know, although I appreciate that e.g. Japanese knotweed is not invasive in Japan and so on - but see that it is a location-based filter on the site.

[ezwelty]

I would encourage a two-step process to keep us focused:

1. We integrate the existing type categories (forager, freegan, grafter, honeybee) by having the API return a categories array for each type (see https://github.com/falling-fruit/falling-fruit-api/issues/10). The design could be something like your tag design, but without "more". We make forager + freegan the default selection (to match the existing website). Bonus points if we somehow included the category icons originally designed for the mobile app (e.g. main icon changes when one of the categories is clicked). One for grafter is missing but could maybe be commissioned.

For more info on these, see:

• https://fallingfruit.org/freegan
• https://fallingfruit.org/grafter
• https://fallingfruit.org/honeybee (never got its own custom welcome popup)

2. A few more high-priority categories are added (and the "more" appears to accommodate them). Note that this can be a real rabbit hole with 3000+ types.

3. Later, we introduce the type lists feature (see https://github.com/falling-fruit/falling-fruit-api/issues/9 and https://docs.google.com/document/d/1ah6jKO9uizBqeBtTVoIXi51gpYEQEyYzzastcMKOp5Y/edit?pli=1#heading=h.cbt21puyoh05). The built-in categories could stay in place (there might be a performance benefit to this, since I can build a database index for each, especially useful for the default map view), or be migrated to type lists. The "more" becomes "edit".

[ezwelty]

@wbazant FYI The API now returns categories for each type, which makes scenario 1. of my previous comment possible.

[wbazant]

I'm thinking another UI solution would be to show categories in a tree select. The interface would let the user swap between two tree selects through horizontal tabs (like tabs in a browser, over the tree select), or through a "show individual types" checkbox that toggles between the two views. We'd need to get the counts from the back-end (since if we added up type counts by location, we would multiple count some locations) but this UI would take up less space than tags I proposed above, not introduce a new visual element, and works better for making the categories more numerous and elaborately grouped. Showing categories instead of individual types could even be the default choice because a new user might find them less overwhelming.

The natural default state here seems to have all the categories selected at the start. @ezwelty what was the reason for forager + freegan being the default choice on the live site? If the above solution seems better than the tag cloud, is it still worth having some categories off by default? Ticking a category should select types that category is for, and related categories should interact through the types they group - for example, unticking "Forager" should make "Honeybee" go from selected to indeterminate.

"on the map" and select/deselect all when the categories are visible should work on them as for types. The search should be hidden for categories because we only have a few. Alternatively, the hint should change to "Categories" when categories are visible. The "Types" header of the filter should still say "Types". We could still link parts of the old site to specific categories selected. The map should still show labels referring to specific types.

[ezwelty]

@wbazant Interesting, let me think through this. I like the idea of a tab to switch between category and type-level filtering. It allows a more user-friendly (and potentially more performant) default.

We'd need to get the counts from the back-end (since if we added up type counts by location, we would multiple count some locations)

Note that the clusters do not count locations, but types. This is largely for performance, as it allows us to precompute type counts on a quad tree and sum them together for an arbitrary type filter without concern for which types share a location. Counting the number of locations on the map that contain a type in each category is possible, but for only a small number of categories, and for it to be fast regardless of the number of locations shown, would need to be precomputed as well. Frankly I would just stick to counting types (which isn't entirely wrong), especially since this is what the clusters already do anyway. Actually, I would start by omitting counts entirely for the categories and see how it feels.

works better for making the categories more numerous and elaborately grouped

I don't quite see how categories would end up elaborately grouped in a nested tree structure. If I think forward to the custom type lists mentioned earlier, then I imagine:

• At the top: an all or uncategorized (because many types are not categorized) plus a few built-in categories (forager, freegan, ...).
• Followed by the user's custom categories (if logged in)
• Followed perhaps by other user's publicly shared custom categories (if we ever get this far)

Especially for the custom ones, I expect we'll want as much width as possible to display them. Are you imagining that Falling Fruit would curate a taxonomy of categories? That sounds like a lot of work that I was hoping to pass off to users through custom type lists.

what was the reason for forager + freegan being the default choice on the live site?

Because the database stores everything, and displays different types to different user communities. Since most users are interested in either edible plants or food-bearing dumpsters (or often both), forager and freegan is the default. Only a few special users are interested in food plants for honeybees (honeybee) or non-fruiting rootstock for edible grafting (grafter). Consider these side projects.

The forager category is currently very broad because we have some users adding marginally-edible things that I still need to render on the map of the website/mobile app less they wonder why these locations disappeared. With more flexible type filtering, I will probably make the default forager more selective, since these users can always select all or specifically the types they want.

for example, unticking "Forager" should make "Honeybee" go from selected to indeterminate.

If I have forager and honeybee selected, and untick honeybee, I would expect all forager types to remain on the map. Categories should be OR, i.e. select any type that is in any of the selected categories. I don't see a need for indeterminate. But unticking a type that is forager should make forager not selected when back in category view.

[wbazant]

Awesome, I'll attempt that! I'd like to first finish a tree select that works for just the current features, but adding the categories after that shouldn't be far off.

I don't see a need for indeterminate

The need arises because what is being selected by the tree select UI, and what corresponds to the parent checkboxes, is a set of types. I think the categories should be a way to select types too - so if the user e.g. selects only forager in categories, and switches to types, they should see forager types checked - then after unchecking one of these types, and switching to categories, I propose they should see an indeterminate checkbox.

[ezwelty]

... after unchecking one of these types, and switching to categories, I propose they should see an indeterminate checkbox.

I agree with that, but I was saying that deselecting a category should not remove types that are selected by other already-selected categories. You wrote:

Ticking a category should select types that category is for, and related categories should interact through the types they group - for example, unticking "Forager" should make "Honeybee" go from selected to indeterminate.

And I argued that unticking "Forager" should not make "Honeybee" indeterminate, because all types for "Honeybee" should remain selected as long as "Honeybee" remains selected. It doesn't make sense to me that unticking "Forager" would remove types included in other ticked categories, but willing to be convinced otherwise.

Anyway, by my logic, indeterminate/partially-selected does not work for categories. For example, starting from an empty type filter: ticking "Forager" would make "Honeybee" indeterminate (and probably many other categories) because it shares common types with "Forager". Ticking and unticking "Honeybee" would then not untick it, but make it indeterminate, because some types in "Forager" are also "Honeybee". Hence why I suggest that categories are either ticked (all types in this category are selected in the type folder) or unticked (not all types are selected).

[wbazant]

Sure, I see what you mean, I guess selecting categories as themselves is logically coherent too.

In I think 2017 my colleague and I wrote something with checkboxes in multiple categories that overlap and are used to implicitly select something else - I just checked and it's still online more or less as I remember it, you can check out https://www.ebi.ac.uk/gxa/experiments/E-CURD-1/Results and "Experimental Variables", which opens a modal, and it gets really complicated for some experiments: .

In our example ticking "Forager" would indeed make "Honeybee" indeterminate, but then the user can e.g. untick "Honeybee" and get the "forager but not honeybee" selection they might also want.

[wbazant]

So my next thought after considering the checkboxes is that maybe treating categories as groups of types that facilitate selection - letting the user look at "forager but not honeybee" etc. - is not very useful. Maybe categories are better for organizing types. If so, they could be used to split the type menu:

If a type appears in many categories, we just render the checkbox in each category, and fortunately it's not a problem for the default Forager/Freegan choice.

The categories (default / visible status for each) could be configurable in Settings, with user and community categories eventually supported.

Hiding a category would remove all the types from the pool, unlike a chevron, so we should use a different symbol for the toggle.

Not yet sure what to do about "category visible, but no types in map selection" - maybe not showing the category, and not showing a category header if there's only one category with types for selection?

[wbazant]

Maybe we should just display five checkboxes:

Last option could explain what this row of checkboxes is, but Uncategorised is a bit of a long word:

With this proposal, category checkboxes would behave like the On The Map checkbox, hiding and revealing parts of the tree. The default choice would be to select only forager and freegan types by default, and also to only show them by default.

Hiding elements instead of changing state should make it simpler and we'd have a bit of logic for what types to request for the map: we'd request types that are checked and visible. So if we tick Uncategorised and then tick Oak in the type tree, we'll get oaks on the map, after unticking Other they will disappear, but then after ticking Uncategorised will return oaks to the map.

Implementation plan could be as follows:

1. Add the UI elements to src/components/filter/Filter.js : just the simple UI choice of five checkboxes in a row will be great for a start
2. Add state.categories to src/redux/filterSlice.js as well as an appropriate reducer, and wire up the checkboxes so they change the redux state.
3. Add the concept of categories to src/components/filter/TreeSelect.js and src/utils/buildSelectTree.js . Do it like with searchValue - types whose categories don't intersect with chosen categories should be omitted, except if a parent is not in the chosen categories but has children that need including, it should be included but disabled. Check that clicking category checkboxes hides / reveals types.
4. Make the choice of categories impact the choice of what's fetched by the backend. For example, src/redux/mapSlice.js has fetchMapLocations passes state.filter.types to getLocations but this will have to get a bit more complicated

[ezwelty]

@wbazant If the category checkboxes also limit what is shown in the tree, how does one return to a tree that shows everything but has only forager or freegan types selected (aka the default)?

1. One approach is that the "Select all" / "Deselect all" operate on only visible types (and perhaps renamed). But note that parents and children do not always have the same category (e.g. a genus has very few edible members so it is not in the forager category, but a particular species of that genus is the rare exception and is). Since parents need to remain displayed for the children to be properly displayed, parents displayed only for the sake of a child would need to be greyed out (as is done when searching by name) and also not (de)selected when "select all" or "deselect all" is pressed. This would make the categories more like search filters, which would scale well if/when we add other type filters (e.g. edible plant parts, edibility rating).

2. The alternative to this scheme (filter by category, select/deselect with controls) is the reverse: select/deselect by category, show/hide with controls. For example, we would add a checkbox whether to only show selected types ("[x] Selected"), akin to our "On the map" (whether to only show types present in the current map bounds). Still I think it would be useful for "Select all"/"Deselect all" buttons to operate on visible and non-greyed out types, so that the search results are more useful.

Curious to hear which you think is better?

p.s. Oak Quercus is a forager type. Acorns, yo.

[wbazant]

Yes, I was thinking to make categories like search filters! But I agree with you that Select all / Deselect all are most useful and clear when they really select / deselect everything, for example a strategy you can use with search is to deselect all, type a search term, and tick the right results.

how does one return to a tree that shows everything but has only forager or freegan types selected (aka the default)?

In how I was thinking about it yesterday, one doesn't, but maybe that will not be too confusing or even noticable, since one can easily go to a selection where everything is selected, but only forager and freegan are visible. It's functionally the same, since gets you the same types on the map. But that's definitely a weak point of the design.

p.s. Oak Quercus is a forager type. Acorns, yo.

I clearly don't have a good enough idea about why some types have been included on Falling Fruit. The beta site should get some kind of feature that will help me with it!

select / deselect by category has the problem of categories that intersect. We should then also draw them more like buttons rather than checkboxes (since the other checkboxes filter the type tree) and I guess that's the version from https://github.com/falling-fruit/falling-fruit-web/issues/383#issuecomment-2139703922 except with correct checkboxes (and light blue meaning partially selected).

[wbazant]

Proposed resolution from the call:

• categories show up as checkboxes, similar to the "on the map" feature
• categories control what's displayed (a bit like search value )
• select / deselect all applies to selection only (not everything like currently)
• parents that need to be there for the tree but don't match categories are displayed inactive ( like search values )
• needs "Other" category for sure
• other buttons, like expand / collapse all, are interesting