Filters appear when appropriate

[Megachile]

See below: https://github.com/jeffdc/gallformers/issues/39#issuecomment-774557866 for decisions on how we will handle this.

This is the original issue text

We should only let the user filter by a trait if we can be fairly confident that the filter will return every gallformer that could potentially match that trait. Personally, I think we should aspire to guarantee this is true for Host, Location and Detachable (and indicate where it might not, as noted in the data quality issue). Further traits, like texture, alignment, wall thickness, cell number, shape, and color, are very useful for a few hosts with diverse gall fauna, but fit awkwardly on other species, admit a lot of variability and subjectivity, and would be annoying to apply to all the species in the DB. I think we should only have Host, Location and Detachable appear on the basic ID page. Additional trait boxes should appear only if they select a genus like hickory or hackberry for which those traits have been specifically applied to every gallformer species.

[jeffdc]

@Megachile I am not sure that I understand what you are saying here.

[Megachile]

Rewrote, hopefully that makes more sense

[Megachile]

If we move forward with my proposal to limit the filters this way, we should also alter the Gall admin page to indicate that Host Location and Detachable are mandatory and the rest are optional. Hopefully the solution to that issue would make it less likely that Detachable gets overlooked and entered as "no" when the user just forgets to fill it in one way or the other.

[madeleineclaire]

I am all for limiting the filters in this way. Even though many of the fields are not required, as a user I feel as though I need to select as many of them as possible, which can cause erroneous elimination (or inclusion) based on my own subjectivity on what the options mean.

I used this observation to see what results I may be able to uncover and had a hard time knowing what to select in every single filter category: https://www.inaturalist.org/observations/67286584

[madeleineclaire]

I tried another ID with this one: https://www.inaturalist.org/observations/67933275

I am pretty sure this one is Rabdophaga salicisbrassicoides, but it doesn't appear that this gall is included in the database. I started by selecting Salix in the Genus dropdown and hit search, intentionally leaving all filters blank. This returned 0 results. I tried selecting 'Stem' under 'Location' and hit search again...also no results. I then went up to the 'Seach' box on the top menu bar next to the green 'Search' button and put in 'rabdophaga'. One result was returned, rabdophaga rosacea, which as I understand is a visually similar gall, but is known on European species of Willow and not known to the US.

I clicked into the rabdophaga rosacea record and noted that the location is listed as bud. This is worth noting because with my limited knowledge of plant anatomy, I believed the gall was located on the stem, not on the bud. I can see it now, but it wasn't my first instinct. This is where I was hoping simply searching 'Salix' might have returned a listing of potential Salix galls and I could have continued narrowing it down based on visuals.

I'll conclude this stream of consciousness with two things:

1. I see the value in leaving which identifiers to select open to the user to choose whatever may have stood out to them most meaningfully. With that in mind, I agree that the location of the gall is critical to an accurate ID. If it is made required, it might be worth considering consolidating the options or building in a decision tree of some sort. Example: I select 'Leaf' and it brings up all possible leaf galls, but also open up a new selection window in which I can select 'at leaf angles' or 'on leaf vein' to further refine my results.
2. Would it be possible to display search results in a gallery view rather than a list view? Most users will likely make the initial connection to their gall visually. The layout Joyce Gross uses was exceptionally helpful to me in the early stages of my gall addiction. (example here: https://joycegross.com/galls_ca_oak.php)

[Megachile]

Just a reminder that the database is only complete (to my knowledge) for Acer. Most host genera have no galls added at all yet.

Distinguishing bud and stem can definitely be confusing. Something I'll write about in the relevant notes section.

I don't think we should make any filter required. Leaving one blank if you're uncertain and filling in the others is a strategy I use all the time.

Making a sequential decision tree for plant location makes sense to me but I'm not sure it's worth the effort. There are few enough now that it's not an issue. But that's just my opinion. Something to consider for sure.

I agree that a gallery/tile view is better. I made an issue #65 for that.

[jeffdc]

As part of another change I am going to make a temporary and easy change that looks like this:

[jeffdc]

I think that we need to rethink this issue. Here is my rationale:

The detachable field defaults to empty (as do all of the criteria) which means that they have ZERO impact on the search if left empty - in other words empty does not equal No - this is already being discussed in another issue #40.

I made the UI change as seen above. If desired I can move Detachable up above the line and text, and modify the text to include detachable. However, I think we should not even do that. Instead we should encourage the user to start with Host/Genus + Location as the UI does now. Then once they get a list of galls with those criteria they can start selecting the other options. If they select stuff and it eliminates all of the galls they can un-select. We can order the filter boxes by importance and indicate to the user that lower filters are more esoteric and may not work for all galls. We can also show on the screen if there are no matching galls a better message. Something like of:

Your current filters eliminate all galls. You have selected filters for "Walls" and "Alignment". Many galls do not have data for these filters. Try and remove them.

As for the data, I believe that we should strive to add more info rather than less. I understand that Carya and Celtis galls have more documentation RE shape, walls, color, etc. but we also have a TON of data about other galls that would allow us to collect and document these same traits for other galls.

IMO, trying to track filter properties based on Genus/Species is going to create a lot of headaches on the tech side, the data side, and the user side.

[Megachile]

Hmm, well my goal was to avoid headaches (thinking only from the data side and user side) so I definitely want to make sure we don't create more of them.

I've been mulling this problem over since I started keeping my spreadsheet and ultimately don't know if there's one perfect answer. My impulse is to pull back to only a few traits and make them as inclusive as possible. My fear is that while it might be obvious that you've gone too far if you end up eliminating everything, it is not obvious if you've only eliminated everything but a few species. This happened to me last night on one of my own guides, with location. Adding more traits creates even more points of subjectivity and incompleteness.

But I understand the impulse to use all the info we have to help users get as close as possible to their ID. I think your suggestion is a good middle ground. We can use text to make it clear to users on both ends which filters are comprehensive and which are probably not, so those latter filters can be useful without giving the wrong impression. I would just want to make sure we give as much info on that as possible.

[Megachile]

Okay, I came up with a proposal for low-tech way to handle this. All text provisional, first draft.

The user chooses a set of filters and gets either no results, prompting the system to display this message:

It’s possible there are no described species that fit this set of traits and your gall is undescribed. However, before giving up, try altering your filter choices (link to tips).

or some results, which are displayed along with this message:

If none of these results match your gall, you may have found an undescribed species. However, before concluding that your gall is not in the database, try altering your filter choices (link to tips).

The link would take the user to a page containing text like this:

The host, location, and detachable filters are comprehensive to the best of our knowledge for every host genus listed here (link to list). If you’re not finding a match, try using only these three filters before you give up. Common issues using these filters include: wrong host ID (try moving up to the genus level or checking your second or third guesses) Whether a gall is “Between veins” or “on leaf veins” can occasionally be ambiguous or misleading; try choosing the opposite or avoiding these terms entirely Bud galls are often mistaken for stem galls A gall looks detachable but is not (or vice versa); check the results for the opposite option

Other traits, including color, walls, cells, alignment, shape, and texture, are added only comprehensively for particular host genera (link to list). In other genera they may be applied incompletely or not at all. Check the filter glossary (link to #62) to make sure you’re applying the terms consistently with our usage.

There is also the possibility that your gall is not a gall; see our FAQ page on structures commonly mistaken for galls (link to #60).

The linked list would be a table that serves the function of #38, with rows being host genera and columns being traits, with a check mark to indicate the ones that were added comprehensively.

How does that sound?

[jeffdc]

This sounds great and is inline with what I was thinking.