I have an PWA in development that is focused around the material design ideologies and style, although this question is likely still applicable to other design schemes as well.

Essentially I have a persistent App Bar at the top of the window, with the usual burger and additional actions.

The app has a number of data-sets available for the user categorised into say, Products,Invoices,Users,Customers. Currently each data set has a unique and separate search within a "browse" view (separate from the app bar), enabling the user to search and filter results to find what they are looking for.

In testing i have found, that users sometimes get confused why their current search criteria don't return expected results, when simply its because they were within the Products section when searching for Invoices.

Search is an important part of the app although, hence during BETA i have browse views, which eventually would end up being focused metrics showing recently viewed data and data to take actions on.

So although I should likely lean towards the persistent search box mentioned here, I feel its much more important to display the page name in the app bar, because of the various data sets and their actions.

So my options i have come up with,

  1. One app wide unified search (Within the app bar)
  2. Have app bar search input use the current view search context (e.g Products)
  3. Keep separate "browse" views with individual search inputs

The only hesitation comes from the current users ease of use, when searching in products the search as you type returns relevant products, if i were to remove the browse feature in favour of a unified -but categorised search- is the extra step of opening a search input within the app bar.

I'm open to any additional ideas and of course some good old fashioned constructive criticism.

1 Answer 1


Unified search boxes work best when searching the pages of an app/site such as on social networks where you can search for posts, groups, users, etc which all have their own page. These search boxes should provide a dropdown selection of potential targets for the user and resolve to a search results page.

For filtering a dataset, it is a better idea to create a UI that is positioned near to the data that is being filtered. I would generally position a search box directly above the datatable or list that the data is presented in to provide a visual link between the two elements. You could implement this using position: sticky on smaller screens so it remains at the top of the screen as the user scrolls to view the data.

If you do wish to go with search in the app bar, I would suggest using the expandable search pattern you linked above as it allows for the page title to be shown until the user initiates a search.

Expandable search documentation from material guidelines

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.