Understanding SearchJanuary 18, 2020
Most applications have some type of search. You type something into a box, check a few boxes, and voila you have what you were looking for. At least you hope you do.
But what is search, really? What are the different facets that make it work and how can you begin thinking about search for your app?
It all begins with having a solid understanding of the building blocks that make up search. By understanding these things, you can begin to gain clarity into what’s possible and better communicate with the team as to what you want to occur.
When you get a set of search results, they are more often than not all referring to the same type of data. This data is most likely different on each application. For example, a Google search returns webpages. And if you want images, news, or otherwise, you must go into a separate tab of the search.
There is a good reason why Google and most companies separate search by types of data; it’s difficult to combine the results of varying data types, and therefore completely different attributes, into one result set. So unless you have a very specific reason to query against multiple subsets of data, it’s highly recommended to stick to a single type. And if you’re working on the first iteration of your project, definitely stick to a single type.
So you have the results you were looking for and they’ve been rendered to your webpage. But when you scroll down, it’s rare to see all of the results at once. You more often than not have to click to the next page or more results load in when you scroll to the bottom of the first set. Why is that?
Each request that is made to the application means the app itself needs to send data back. In the case of search, it’s the results. Each result that’s return means more data that’s being sent over the wire, which leads to not only slower responses but also heavier data usage. And if you’re browsing the web on a cellular plan, both of those traits are highly undesirable.
If you can magically make slow and heavy responses disappear that doesn’t solve our problem. It’s a lot of work on the browser itself to “paint” each and every item. Can you imagine how long it would take Google to show you all 3.4 million webpages it found for you on a single page? It would most likely crash your browser. Maybe even your computer!
So unless you’re 100% certain the results being rendered will always have limited results, it’s best to implement pagination from the get-go. But don’t worry, you can always change your mind and implement it–or take it out–at a later date. It’s just something you have to keep an eye on in your performance metrics to see if it needs addressing.
We now have the results of our search, but it’s giving me data I didn’t want. This is where filtering comes in. Filtering allows you to limit a set of results to match a certain criteria. This works similarly to any type of filter. It gets rid of the things you don’t want, allowing the things you do want through.
Filters can come in a wide variety of options. They can be ranges, such as date ranges. For example, you may want all articles that were posted within the last month. They can be based off of relationships to those results, such as a category or tag belonging to an article. Sometimes these types of filters can be done on an individual basis and sometimes in multiples. It just depends on the level required by the people using the app.
There’s a real rabbit hole you can go down here, so proceed with caution. It’s highly recommended to start small and add filters when they become necessary. This is usually when either your users are continually asking for them, but typically not sooner than that.
Now that we understand filtering, keywords will become much easier to understand. These are the text inputs where you can type in some letters you expect the search results to match. You can think of a keyword as a filter, because it is a filter. The only real difference is you the user are deciding what you want to filter your results to, rather than the application dictating some of those filters for you.
More often than not, a keyword is used to find partial or complete matches to a string of text. In the case of articles, you may know that you’re looking for “app development”, so you type that into the input. You then see a filtered set of the results where “app development” exists either somewhere in the title of the article. While usually a one-to-one relationship between a piece of text (keyword) to an attribute (article title) on the dataset, the keyword can be used to check matches against a number of attributes belonging to the dataset or one related to it.
Other times keywords can have special characters or hidden functionality. If you didn’t already know, this is true for Google. If you’re searching for something popular and something else you don’t want continues showing up, you can “subtract” that keyword from the search. So if I were wanting to find a cookie recipe that didn’t have flour in it, I would type something like: “cookie recipe -flour”. Google then translates that “-flour” in the keyword as something I don’t want in the results. This is only a small taste of the power Google provides in its search functionality.
Just like in filtering, keywords are another rabbit hole. It can quickly get out of hand. So keep it simple and build it up slowly over time. And remember, you’re not Google.
The last thing I wanted to touch base on related to search is sorting. We’ve got our results and they’ve maybe been filtered down to what we want. Now I want to see them in a different order.
This is sorting. It’s simply a matter of seeing the exact same result set in a different order. This can be alphabetical, date created, popularity, or a whole number of other attributes.
There’s one main piece to keep in mind when working with sorting. The data you’re trying to sort must be something that can easily be placed in ascending or descending order. Think numerically or alphabetically. You can’t, therefore, sort something that isn’t numerical or alphabetical, unless you somehow massage the data in a way that tells it how to become numerical or alphabetical.
All in all, search is an important piece of functionality for any app. There are many different facets that go into making search and this article barely scratches the surface of what’s possible. But as you start diving into more aspects of search, we hope we’ve laid the groundwork for your understanding. You now have the base knowledge to have meaningful conversations with not only your development team, but any other stakeholders. Now it’s just a matter of searching what you’re searching for. So get searching!