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.