Google and the internet has made search for specific content easy and effective. It’s pretty common for our clients to request a search function in their app, with the expectation that all searches are the same as a Google search. There’s a lot more to search, though, and it’s important to weigh all of your options before implementing search in your app.
To search or not to search?
One way that Google has conditioned users is to believe that they can find absolutely anything through search. Consider the content of your app. Do you have curated material? Will the content of your app grow and change as you add users? Do your users already know what content they will find in your app? The most effective searches these days excellent indexes of information, which is effectively all the information that could possibly be available. If the content of your app isn’t what you would consider “exhaustive” on the topic at hand, it’s likely users will use search to look for something that isn’t in your app, and then be disappointed with the results.
For example, consider an app that lists the “Top 100” restaurants to visit across the country. That type of content is designed to be carefully chosen and consumed by the user browsing it. Allowing users to search by restaurant name or even city is setting them up for disappointment if the restaurant or city they search for didn’t make it onto the curated list. On the other hand, consider a resource that lists all local plants and whether or not they are poisonous to dogs. A user with the app would only logically search for a plant that exists in the area of use, and therefore the plant should undoubtedly be on the list. Lack of a search would render the app useless in an emergency.
If the primary purpose of your app is to deliver specific information that the user knows they will find in your app as quickly as possible, search is a great feature. Apps designed for browsing and enjoyment may not find as much value in a search function. Limiting search can be an effective way to provide a hybrid between the two extremes. Offering useful filters can often take users to the content they seek faster than a search would, too.
Interpreting the user’s entry
The buzzphrase around deciphering user-entered text is “natural language search.” This involves the app analyzing what the user has typed to determine the root of the search, finding the appropriate content in one of many indexes that have already been created, and then ranking the appropriate content to make a best guess at what the user is looking for and displaying it first.
This gets complicated when you are searching across multiple kinds of information. Customers of a digital retailer might search for a product, model number, category, size, or description. The search analyzes what the user entered to interpret what they were most likely looking for, even if they misspelled it, put the words in the wrong order, or typed one thing while meaning another. Brands and people make this even more complicated, because interpreting the root meaning of a proper name can yield some really weird results.
How to rank the various kinds of information returned as search results is then the next challenge. The app has to determine which result is more likely what the user was actually seeking. A search that consistently puts the desired information at the bottom of a list is almost less satisfying than not having a search at all.
Making it happen
Fortunately, there are several tools out there these days that enable people with budgets smaller than Google’s to provide an almost-as-good experience, but they do have limitations. That begins with determining what parts of your app are searchable, and what parts are not. In the retailer example, searching within product descriptions probably isn’t overly useful because “pair with a classic button down shirt” doesn’t offer any useful indication of the product described, and if the user was searching for a button down shirt, finding an item that isn’t a shirt at all is pretty frustrating.
With the vast majority of current mobile apps, searches actually go back to a web server and don’t take place entirely on the user’s device. This means an powerful search generally requires a data connection. This usually isn’t an issue for most consumer apps, as most users casually browse content while in an area with a data connection, but this can present an issue for apps intended for use in very specific physical locations that may not have an available internet connection. Warehouses, hospitals, state and national parks, and other rural areas or substantial buildings can be virtual dead spaces. If your app is intended for offline use, that can influence how your search works.
Moral of the story
If you give the user the ability to search for “everything,” then the user often ends up feeling like they are returned with results that are effectively “nothing.”