Search box/field design with multiple search locations

Question

Not sure if this question is better suited for a different StackExchange site but, here goes:

I have a search page that searches a number of different type of things. All (at the moment) requiring a different input field for each type of search. For example, one might search for a school or district name, a class name, a staff member email address, etc. I have 9 different 'type' of searches each with their own input field on the search page. I've already concatenated one of these (a username and UID search) but I'm wondering if it makes sense both design (user friendly) and performance wise to bring these all into one input field (and therefore one singular search)

These different types are of course a number of different tables, so it would have to query a number of different times for each type, just for one search.

Any ideas? or should I just keep it how it is? I could add a drop-down menu to choose a different 'type' of search but that seems just as messy. I'm already doing this for my navbar when not on the main search page (which also happens to be the home page)

My project is written in Python with the Pyramid framework.

Answer 1

What happens to your search interface if the application changes? This is a very important aspect. Do you add another search type?

A search returns matches on the query string. A result set can contain different entities from different types. Then your search/resultset interface could apply filtering based on entity type or entity facets (examples: Ebay, Amazon)

Learn from Solr/elasticsearch and add-on projects. Faceted search is what users are used to these days. The concept of separating data storage (RDBMS) and full-text search engine is much more powerful and extendable compared to writing complex queries spanning multiple tables. Any larger internet company (Ebay, Facebook, Amazon, Instagram) can tell stories about using the patterns. Separating storage from search offers scalability, flexibility.

Instead of writing query/search code, better learn how to feed these search engines from any data store. This is much more powerful & fun, I promise.

Answer 2

I could see this being posted to the UX SE (ux.stackexchange.com I think?) site, or they might already have a question there touching on something like this. But personally I would probably lean toward either a dropdown selector with different types, or keeping the separate searches as-is. And I think I'd lean more toward the dropdown box - that doesn't seem unreasonable to me for a search interface.

I guess one question would be - could there be any expectation to want results from more than one of the tables in the same search? If that were the case I could see implementing your unified search idea even though it would mean querying multiple tables. Or some sort of additive interface where you select the tables you'd want to query.