Selected types do not persist on map movement

[lkwhite]

As a user on the beta site, if I deselect all tree types, select only serviceberries, and then move the map, my expectation is the map will remain serviceberry trees only. This is true on zoom in, but on zoom out the map instead displays all tree types within the expanded viewing area outside of my original map area.

As far as I can tell there's no easy way to refresh the map area for the originally selected search, which is particularly annoying for the use case of "I'd like to explore around an area and to see if there are any of these 10 particular types of trees I'm interested in."

Edit: issue appears to be browser dependent but persists after cache clearing and disabling all content blocking w/ Safari v18.2.

[wbazant]

Hm, I see what you mean! I appreciate the issue being raised. The result you're looking for can be achieved by unticking "On the map", deselecting all, checking serviceberries, and ticking "On the map" again.

I think the problem is 'Select all' 'Deselect all' having the "all" context-dependent on the checkboxes being shown: we've made it work like that in #564 , it made sense for another feature we were thinking about, and the other goal was to make, searching + selecting more useful, but not many users had a chance to tell us what they think yet.

Do you have any ideas for changing the feature should do or look like? We could do something entirely different for type selection, slightly change the behaviour of the checkbox / buttons or maybe a bit of verbiage change / UI positioning of elements could make the current behaviour easier to learn.

[lkwhite]

Hm. Even after reading your explanation and playing around a little I'm not 100% sure what the functionality of the "on the map" tick box is intended to be, so I think a verbiage change is definitely in order but possibly also a functional change as well.

[ezwelty]

@lkwhite Thanks for your feedback. "On the map" limits the location types shown in the tree to only those that occur within the current map bounds. It has no effect on which types are selected and displayed. Similar to if you search by type name and only the types matching the search string are shown.

For example:
https://beta.fallingfruit.org/map/@39.0783015,-76.7704242,19z
Only "Pawpaw" is listed.
You can deselect "Pawpaw" and the single location disappears, but it remains listed since the location with that type exists on the map even though it is not displayed.

Is this more clear? As part of another proposal to treat location type categories as additional search filters, I suggested this design: #608 (comment)
Worse or better?

[wbazant]

I had an idea to put our regular select in place of the type tree - code here. Not a production solution but maybe interesting one day.
Recording here:

Screencast.from.2025-06-15.11-03-47.webm

Pluses:

• supports the basic use case of letting someone search 'apple' to immediately see apples
• sorting by count is immediately useful at answering 'what's here?'
• more powerful search

Minuses:

• showing the aggregated counts isn't solved well here
• the dropdown doesn't really work as a flat list

Interesting:

• if there were also filters by source and last added, the compact design would be really useful
• there could be a tree dropdown like on the live site
• could include synonyms

[janevancleef]

This seems very important, no way would a normal person expect any different behavior. If I select “Apple” and “pear” while I’m zoomed into my neighborhood, then I actually have to zoom out to find some of them, I would not expect the app to reset so I have to re-enter my search.

[ezwelty]

This seems very important, no way would a normal person expect any different behavior. If I select “Apple” and “pear” while I’m zoomed into my neighborhood, then I actually have to zoom out to find some of them, I would not expect the app to reset so I have to re-enter my search.

The app does not reset. The confusion stems from the "On the map" filter, which limits the types shown in the list to those found within the current map bounds. Since "Select all" and "Deselect all" operate on only the types that are shown in the list, if you deselect all with "On the map" filter active, there are inevitably more types not currently shown that remain selected. If you then select a type, then zoom out, you end up with locations matching that selected type plus any locations matching those other types one did not realize were still selected.

Maybe we can clarify the distinction between search and selection controls with an interface and wording like the following:

Types

Search
[ Name: ... ]
[x] Within map bounds
[ Selected ]
[ Deselected ]

[ Select results ] | [ Deselect results ]
...
....

[wbazant]

I thought more (and also wrote earlier versions of this comment, stared into space, conversed with a chatbot, did everything) and I agree with you @ezwelty , we should change the verbiage:

• 'On the map' into something longer
• 'Select all'/ 'Deselect all' to reflect their action affecting what's shown, I got 'Select shown' / 'Clear shown' from a chatbot but symmetric naming i.e. 'Deselect shown' seems better to me

Also, relatedly to this, I think it could be good to swap list and filter in the mobile layout, since filtering expresses the user's preferences for a global state, meanwhile the list view is just a view of what's on the map.

[janevancleef]

Honestly I'm only thinking about this in mobile mode, and my main frame of reference is Google Maps on my phone. I have come to rely on what I hear is called a "hybrid search bar" where there's one field and I can type an address, a general location, or something I want to see. So for my current project, "Brooklyn bridge park" or "bur oak". Or "Quercus macrocarpa" if im feeling saucy I suppose. If I type an address, I expect the map to move so it's centered on that place, at some kind of manageable scale. (5-10 blocks maybe idk. Maybe the same scale I was already zoomed at) Otherwise I expect the map to be centered where I am, also at a manageable scale. And if I type in the thing I'm looking for, I can be served a suggestion that is the official listing for that thing, and then I will see pins dropped on the map with all the instances of that thing. All the other listings are filtered out. And if I zoom out or pan elsewhere, then a button comes up that says "search this area". IMO if you recreated all that, it would be highly highly useable.

[wbazant]

I've seen a new user try to enter plant names into the address field before concluding it's for something else. With google maps there's a context of a 'google search' where a user types in what they would like to find, and Google uses algorithms and data to find it, whereas we have two things a user could search for - address or type - I think combining them in one input field would be unhelpful for the user knowing what they could do.

I tried some other verbiage, can't tell if it's actually better or not. Also, as an extra problem, "Tree inventory" and "On the map" currently look the same, but one of them affects selection, the other visibility of options. So maybe a dropdown? The other option in the dropdown is labeled 'All types'.