Closed sinabahram closed 4 years ago
What should the UX be? These filters are buttons which, when clicked, submit the search form with the term/subject/etc omitted?
It may make sense to hop on a call to discuss this. The buttons remove the filters, and then you need to hit search again to see the results of that filter being removed.
What do you all think for the search terms would we just pre-populate the search field with those words and the user can either delete that text themselves, and add a new word by adding a space then the additional search term they want to add? As for Subjects, types, and accommodations would they just be preselected and the user would uncheck those or check more they wish to add to the search results?
Or do we have what Sina just suggested and have a list of current filters that you can click on to remove like: "X - Heart", "X - Subject: Science", "X - Type: Image" then you can click to remove any number of these and then preform your updated search.
We can’t support multiselect in subjects and such, as that ship has sailed RE designed and data model and such.
So, I think we are left with removeable filters per the original designs.
Let me know if this answers your question.
Use checkboxes as filters, corresponding with hidden form fields.
Use aria-live=polite and atomicity
, use the announcement element
@sinabahram aren't search filters conflicting with the "search within existing results" functionality? Since that's basically what filters are. It seems to me that having filters, as well as "search within existing results" is confusing to what it exactly means regarding one's search query.
Hence it would mean: "If you remove all filters, you're no longer searching within existing results."
I guess my real question is, say you have an existing search term "carbon", and you enter a new search term, "steel", does that mean that you're implicitly searching within the existing results for carbon? And if so, is that clear towards the user?
Let’s talk about this sooner rather than later because this needs to be finalized immediately. We can possibly get rid of the checkbox but stateful filters are still necessary because of fields that support multiple values. The alternative would be to facilitate multiple select on certain filters during search.
I think this all sounds good. The only question I have which I think @sinabahram was worried about is if you are Searching within a specific Subject which is under say "Science" such as "Life Sciences" will you still have options to choose other subject areas not within "Science" say the top-level subject of "Engineering" or any sub-topics under Engineering such as "Electrical". Or for that matter other subjects under "Science" say "Earth Sciences". I don't think that makes sense since a resource can only be in one main subject area. Now if you chose "Science" you should be able to refine your search to say "Life Science", but I think thats about it right? Until you remove those subject filters, and then you can choose a different subject.
@clapierre you are correct about this edge case, but let's get evreything working first, as that's simply a refinement to what we already agreed to on a call with @jkva earlier this morning. @jkva the case of picking multiple things from the subject simply means to treat it just like type or anything else, but only the current selected subject's children should then populate that combobox. This easily fits into the framework you laid out above after our call, so let me know if any problems, though I suspect none.
Implemented via ddf29a1a8bf7062425d5015e1b3a718079c55304
This is heavily related to #92. @jkva Once that's implemented, we must then have filters to dismiss previous searches. Note, these filters are nothing more than the label of the select or search field e.g. "Search Term" or "Subject" and then the value (multiple of them if there's been multiple search withins), and they should behave like the mock shows where you can get rid of them by activating them.