Categories POC#608
Conversation
… use currently selected categories
…ries are only visible if at least one of their categories is checked. For disabled parents follow same logic as searchValue
…e if at least one of their categories is checked. For disabled parents follow same logic as searchValue
…opy parentMatchesSearch logic
… which applies only to types without any categories. It should have a checkbox, state in redux, and influence on select tree
…to types without any categories. It should have a checkbox, state in redux, and influence on select tree
…play. The logic for leaf nodes and parents treated as leaf nodes to indicate nonspecific annotation should be as currently - if type includes one or more categories, it's in - but for parents that are there for tree structure, use children's match: all children matching category means include enabled, only some children matching category means include disabled
…hen a parent matches a category but child doesn't
…abledCategories, and log out the result - we'll use it in a second
…rTreeNode. Then don't return null, but instead set isVisible to false.
…t return null, but instead set isVisible to false.
…pes so that only types for currently selected categories are passed into selectParams
… depend on categories, make sure we refetch after category checkboxes are interacted with
…s, make sure we refetch after category checkboxes are interacted with
… reset. Solve it by defining categoriesChanged and using that in Filter.js
…, do them as a multiselect
…re visible - give them a background color
…em a background color
|
@wbazant Well, don't be so hard on yourself 😉; this is pretty exciting. Took it for a spin and here were my initial ideas:
I fiddled around, including reducing 
What do you think? |
|
All right, I was being hard on the feature actually ;). Thanks for the suggestions, making tags square helps with the UI and the 'All' tag is a logical extension. Still, I would like to see what this implementation does well, and then explore a step back. The requirements we have for this feature come from experience with the current site so I have no reason to dismiss them, but combined they put a lot of constraints on the solution. Meanwhile, if we looked at the current beta site from scratch and wanted to improve search controls we wouldn't come up with these categories, the data behind them, the default state offered to a new user, etc.
You can see this version at 5deeed2 - it was as good as the head commit for the exploring the types menu, but it seemed weird that I have to do 'Select all' to enact the choice. It also came with the default state of only some checkboxes being checked, which looked weird on unchecking the default categories and navigating to Grafter or Honeybee. So then I did the head commit version where all type checkboxes are selected by default, but the selection for the map combines categories + types. What's good and working well? One piece of feedback I got indirectly is, now it's easy to exclude dumpsters, but what else? Meanwhile I think these design decisions are maybe not working out that well: default is forager + freeganWhen unticking these and ticking "other", and also unticking "include tree inventories", that's the stuff we exclude from the map. I can see some imperfect annotations but not sure if the map is so much better with them excluded that it's worthwhile to justify the complications of not everything being the default. allow browsing multiple categories at onceWhen I was learning about what types each category has I did a bit of "check this, uncheck that" to see what's in e.g. just Grafter, but I never wanted to see more than one category at a time. the site has data in these four kinds of categoriesWhy are exclusive Freegans (only interested in dumpsters) different from e.g. my pals in Glasgow that press urban apples from juice, and will only be interested in apple trees? Still not sure who a Honeybee user is and how they use the site, do they have urban hives they need to locate? Will a budding urban grafter benefit from the Grafter category? With the current annotation state, it seems to mostly be a way of finding types annotated to a genus level (e.g. apple trees that are annotated as Malus). I'm thinking maybe the non-default categories would be really good as side avenues to explore if they're presented as a subset of filters together with a title / description, a bit like 'Invasive species in CO', and the default selection could just be all types again or maybe there could be one checkbox that excludes more or what we want to exclude. |
|
@wbazant Somehow I don't want to forget that this PR exists, so I'm reopening it and leaving it as a draft so that it doesn't sink too deep. I think there's some good stuff in here to be salvaged. |
|
@wbazant I think a valuable part of this feature would be to clarify the reason behind the default type-filter setting (ah, I'm seeing forager and freegan types), allow users to return to the default, and to by default hide types that are not selected by default (some of which are not edible by any reasonable definition). So I think visibility controls ("Show / hide unselected", "Expand / collapse all") or similar would be a good addition to the above mentioned selection controls ("Select all" and "Clear"). |
|
I stole the 'clear' from this for replacing the 'On the map' with a types dropdown in #929 so that's one thing salvaged! I think we can build on it, imagining the dropdown getting more options: 
Choosing anything but 'within map bounds' or 'all types' would then also restrict the dots shown on the map. Offering a current list of categories would be confusing since the names aren't enough to describe the types in them, and I still don't like it much, but we could come up with awesome categories with the dropdown as a starting point and using interaction design from there. Just to propose something else to stir up imagination:
|
2 participants
For #383
Things I like about this implementation:
I don't like the tags UI, or any other UI I tried, including a multi-select and a list of checkboxes.
Let's not merge this branch - e.g. the On The Map checkbox is not working now - but maybe it will be useful for figuring out what a better solution will look like.