feat: Feature search UI

[Alessandro100]

closes: #806

Summary:

• Selecting GTFS / GTFS RT is now put in the url and has selection Chips
• GTFS Features are now selectable in the filter sections and are in the URL
• Implementation of filter chips to see what has been selected
• Styling adjustments

Note

The feature search will be commented out before merge + will reduce the left column width size

Note

The feature filters do not connect to the backend and are just UI ready

Expected behavior:

For gtfs / gtfs_rt selection, functionality should remain the same. You will now be able to refresh the page and have all the data type stay permanent

You should be able to see the selected filters through the chips

Follow up tickets

• Unit tests
• [blocked] Implement the feature filters in the endpoint
• Continue on NestedCheckbox component (recursion of checkboxes)
• Add debounce when selecting features so users can select many at a time without waiting for load everytime
• Disable / Hide feature selection when only GTFS_RT is selected
• Refactor the Feeds index.tsx (it's getting large)
  • Filter Chips in new file
  • Continue taking styling out of index and into dedicated style file

Testing tips:

Play with the Feeds search page

• Set queries, pagination, filters -> refresh the page, navigate back, etc. Should all work as expected.
  Note: It's expected for pagination to reset when selecting a datatype or feature

Please make sure these boxes are checked before submitting your pull request - thanks!

• Run the unit tests with ./scripts/api-tests.sh to make sure you didn't break anything
• Add or update any needed documentation to the repo
• Format the title like "feat: [new feature short description]". Title must follow the Conventional Commit Specification(https://www.conventionalcommits.org/en/v1.0.0/).
• Linked all relevant issues
• Include screenshot(s) showing how this pull request works and fixes the issue(s)

With Feature filter

Feature Filter Mobile

With feature search commented out

Url parameters

[github-actions]

Preview Firebase Hosting URL: https://mobility-feeds-dev--pr-841-7x16zl5k.web.app

[emmambd]

@Alessandro100 This looks fabulous! I think you mentioned this in standup, but the -planned- backend functionality would be for everything within 1 feature group to be an OR and selections across feature groups would be an AND?

For later: we're going to have a lot of chips at a certain point as search becomes more comprehensive...wondering about design patterns for how to delineate different subsearches (location vs. feature vs maybe mode in the future)

Please make the other issues and we'll prioritize them to make this launch ready sometime in January 🚀

[Alessandro100]

@emmambd we discussed it further amongst the dev and it was decided that it would make more sense for it to all be OR statements. I did some UX research and found that its VERY contextual to the problem

If the main use case will be to broadly discover feed, then OR everywhere would make sense
If the main use case would be very specific feed search, AND statements would be better

I think for the default case, having everything being an OR is good and simple. In the future we could have an "Advanced" Search to accommodate the power users / researchers who are looking for something very specific

For the Chips (and having many of them) I already thought of ideas on grouping them and then having a drop down ex:

[Features (5)]
*click to open dropdown*
- Color
- Wheelchair
- ...

this could be a future enhancement

[emmambd]

@Alessandro100 This solution makes a ton of sense to me! And agreed on the future chip improvement. Awesome work on this and taking something complex and giving it clarity in a short period of time

[davidgamez]

I think if we click a parent category like Flexible Service, we only add one query parameter and one chip Flexible Service instead of all child features. It will be less space in the UI and easier to manage in the backend.

[Alessandro100]

@davidgamez we could have Flexible Services as a parent chip which shows the child elements as a dropdown. A weird use case is if the user individually selects all the child features (if all child feature are selected, the parent is auto selected), then all those child chips go away and Flexible Services is shown. The user could panic seeing things disappear as they select stuff. We could further discuss managing UI clutter / making things easy for the backend

[davidgamez]

@davidgamez we could have Flexible Services as a parent chip which shows the child elements as a dropdown. A weird use case is if the user individually selects all the child features (if all child feature are selected, the parent is auto selected), then all those child chips go away and Flexible Services is shown. The user could panic seeing things disappear as they select stuff. We could further discuss managing UI clutter / making things easy for the backend

If we convert the operation to an "AND," then nothing disappears. Example "Flexible Services" and "Booking rules"

[Alessandro100]

@davidgamez Discussing these enhancements would be easier done in person or in a call, but I agree there is improvement to be done in regards to grouping and dealing with UI clutter of many search filters

[davidgamez]

@Alessandro100 and I connected and went over the design. For features, it is OK to leave it as it is; in the case of more complex filtering like location, we will need to apply a different strategy as this behavior doesn't scale nicely for filters with many sub-categories. cc: @emmambd