Search options about harmonic-hn

[mchowdhury]

Take a look at implementing search using https://github.com/material-components/material-components-android/blob/master/docs/components/Search.md#usage

They should have support for filtering in SearchView

[AppearamidGuy]

I like Gmail's search ui which uses chips for filtering*:

There are actually two slightly different UIs for search. The first one is when you start searching and it shows quick results. In this mode the search field with chips is part of a fixed toolbar** that doesn't move when you scroll quick results. After confirming search, the search field transforms back into search bar. It is still part of a toolbar with chips, but now it can scroll away and reappears on scroll in opposite direction. This UX might need to be adjusted for Harmonic as it doesn't display search bar by default, but there is some guidance for this***.

Clicking the options opens bottom sheet dialog, but they can also display menu or date picker directly. Between BS and menu I prefer bottom sheets for consistency, because we need numeric inputs for points and number of comments filters.

---

* A few other search UI approaches I saw had a button that opens a separate dialog/screen with all the filtering options. And one more used slidable view (like nav drawer) for the options
** Probably combination of search view and chips in the container area
*** Also UI on tablets is different

[SimonHalvdansson]

I agree Gmails implementation is rather ideal with their chips instead of dropdowns. Also the whole Material 3 concept of having the search interface be a modal (which is not necessarily fullscreen on tablets) is certainly preferable to what is implemented now.

The Google Photos example you linked in the guidelines for the UX is certainly nice and plays nice with the current UI outside of "search mode".

I think the way to implement the search bar atleast is to have the search button start an animation which introduces an SearchBar with a focused SearchView. Then how this whole modal thing comes into play is still unclear to me - reusing the same RecyclerView as the main screen as is done now has it's advantages (less need to reimplement things) but it would certainly be preferable to introduce a new RecyclerView for the search results and "disentangle" the UI's a bit.

[AppearamidGuy]

After experimenting a bit with search components, I've found some problems. Material design library actually doesn't support tablet search UI yet: material-components/material-components-android#3190.

Also there is no built in way to animate to/from a button. It can either slide in from the bottom or animate from SearchBar. The best workaround I've found is to have an invisible SearchBar at the same position as search button and animate from it. It looks pretty good, but not perfect.

Then how this whole modal thing comes into play is still unclear to me - reusing the same RecyclerView as the main screen as is done now has it's advantages (less need to reimplement things) but it would certainly be preferable to introduce a new RecyclerView for the search results and "disentangle" the UI's a bit.

I'd suggest separating headers from content adapter, so the same adapter implementation can be used by both main screen and search modal. This can be done by either moving headers to a Toolbar, or if you want to keep them part of recycler - by moving to a separate adapter and using ConcatAdapter to display it in the same recycler as content.