In both the search designs we could search only for one type of object. For example, in the Credit Card example from the previous articles, we could search only for credit cards on its attributes.
This is a common use-case for most of the applications. Usually the need is always to search only one object.
But what if we want to search on multiple objects using the same search region? For example, say we want to search for Credit Cards as well as Debit Cards.
How do we do this?
Let me show you a couple of ways to achieve this.
Using Object Criteria Droplist
A simple way to allow searching on multiple objects is to provide a selection for the object types above the search query panel.
You can either use a droplist or radio buttons using which the users can select the desired object type.
So, in our example of the Credit and Debit cards, we can allow the users to select either one of them above the quick or advanced search query panels.
The interface would look something like below.
In the above example, I have kept the actual search query panel (which is below the object selector droplist or radio buttons) same for both the cards. You can change the search fields too. We will discuss this shortly.
Using Context Switcher
The above approach ends up taking some UI space on top of the search query panel. If you want to save that UI space, then you can think of using the Context Switcher.
You can place the Context Switcher right adjacent to the Search region header as shown above with a dropdown button alongside it.
The user can then select another card type by switching the values in the Context Switcher as shown below thereby switching the search fields.
One thing that I want to point out is that even though I have used the Context Switcher for controlling the search interface, you can use it for many different purposes like switching contents of an entire page, switching content of a specific region or table etc.
What about Changing the Search Fields?
In both of the above design approaches you can have different search fields for each of the card type.
So, selecting Credit Card will present one set of search fields to the user while selecting Debit Card will display another set of search fields.
However, I will not recommend doing this because it might end up confusing the user rather than adding value.
If you absolutely need to change the search fields then consider doing it only for the quick search interface. Else keep the search interfaces for the Credit and Debit cards separate.
Enhanced Quick Search
If both the above approaches do not look good in your design, then you can put the object selector droplist right inside the Quick Search interface.
Similar to how Amazon has implemented it.
Isn’t Multiple Object Search Same as Federated Search?
Federated Search is a design in which you search across multiple databases. Here we are not doing that.
In Federated Search, we are essentially searching the same thing across multiple sources. Here we are searching for 2 different things.
Furthermore, Federated Search has got nothing to do with the user interface as such. It is about how search queries are run at the backend.
I am not sure if you have ever come across any requirement for searching multiple objects using the same search interface but I haven’t come across many such requirements.
I can think of only one instance when I had to implement the Context Switcher to change the contents of the entire page but other than that I have not really used these design approaches much.
While designing for enterprise applications, I generally like to keep things separate unless I am designing the applications dashboard where I have to present different things together.
I hope you have got an idea of how to implement Multiple Object Search if there is any requirement for it.
In next article we will talk about Faceted Search which can simplify the search process to a great extent.
If you liked this article then please share it. I will really appreciate it if you do so.