"chip" functionality in the new search field

As part of the UX Overhaul, we have planned to add support to the search field to automatically turn category words into "chips". This is then also how "browse by category" might be implemented. Then any time that the user types in a category name, it would automatically be converted to the category chip. The upside of this approach is that it is very simple and flexible, with no extra syntax needed. Few people use extended search syntax in UI search boxes. We discussed this quite a bit in the UX Overhaul meetings.

I could see two approaches for this:

• treat category names as the rest of the searchable text
• only convert category names into chips if the matching text is at the beginning of the string, then the rest of the search only applies to apps that are in the specified category

Mentioned in issue #709 (closed)

Mentioned in merge request !409 (merged)

Mentioned in issue #754

I've attached an image of the current implementation when the user opens a category, showing the category chip. @pserwylo You had asked a few weeks back about showing the search input field in the header when a category is opened, as a shortcut. After testing it out in the build, I think it will be much clearer to users if keep the search as a FAB button in this view. The reason is to keep it consistent with the other views. Also, showing the search field right away still requires the user to tap in the field to bring the keyboard up. So, in the end, there are the same amount of taps required to search. Does this make sense?

Also, I've started to work on graphics and colors for the categories. So, we could potentially show a category specific icon and color within the category chip. :) More to come on that front.

You had asked a few weeks back about showing the search input field in the header when a category is opened, as a shortcut. After testing it out in the build, I think it will be much clearer to users if keep the search as a FAB button in this view. The reason is to keep it consistent with the other views. Also, showing the search field right away still requires the user to tap in the field to bring the keyboard up. So, in the end, there are the same amount of taps required to search. Does this make sense?

My personal preference is still to have the category screen show the search bar by default, as in the build you tested. However I am not completely attached to that idea, so if the FAB is preferable by others, than happy to implement that.

I can make the default view of a category such that there is no search bar at the top and only a FAB down the bottom. In that case, pressing the FAB would show the search box at the top and focus on it, bringing the keyboard up ready to search. Under this circumstance, are we thinking that we still keep the chip behaviour? I'd like to, because it means that we can allow users to search specific categories easily, but also quickly switch to searching the entire list of apps by hitting backspace (and hence removing the chip). Thoughts?

Yes, we would still keep the chip idea. Once a user taps on the FAB to search, the search bar with the chip and keyboard would both appear.

Hey @crwinfrey (and anybody else who may want to provide feedback):

While working through this, I have the following problem:

• User selects a category from the main screen
• This opens the list of apps belonging to that category
• The list has:
  • A blue Toolbar (ActionBar) at the top of the page
  • The toolbar has the name of the category as its title
  • No search box
  • A FAB in the bottom right
• Should look about like this

So far so good.

Now when the user presses the FAB button, we:

• Remove the toolbar (perhaps by smoothly scrolling it up and off the screen)
• Add the search box (by fading it into the place where the toolbar used to be)
• The search box is prefilled with the name of the category in a chip
• It is also automatically focussed, causing the keyboard to appear
• Should look about like this)

So far so good.

However, what happens if they choose to dismiss the keyboard? I see two cases when this may happen.

User clicks "Search" on their keyboard

• This should dismiss the keyboard
• The search box should remain
• The toolbar should stay off the screen

User wants to dismiss the search, e.g. by clicking the "x" to the right of the search box, or by pressing back when they have not yet entered any search terms.

• This should dismiss the keyboard
• Maybe the search box has to disappear?
• If it does go, then the toolbar has to return I guess.
• What if they have removed the category chip so that they can search all apps (i.e. without having to go back to the main screen and hit the FAB there)? What should the toolbar say where it used to say the name of the category?

Maybe I'm asking the wrong questions too.

The specs talk about "persistent search" and "expandable search" and caution for "persistent search" when that is the primary goal of your app. I guess that is the primary goal for this list of apps.