The search pattern uses a single-line input field for users to search for a location. It is the main mechanism for finding a place or an entity that has a location associated with it. Users expect to receive the correct result, regardless of what they type and search for.
The search pattern is often the first step in a user’s journey and may lead to extended workflows. Search is probably also the worst usability problem to solve — it’s complex and difficult. What should you type or enter? You’re on your cell phone or in front of a kiosk, and typing is frustrating. Why aren’t there any results? Why are there so many? The thing you’re searching for doesn’t show up so it must not exist.
That’s why universal search engines have become the go-to address to find information. People have grown accustomed to using a single-line input field to retrieve aggregated results from different data sources, regardless of the spelling, length, form, or language of their search term. But not everyone has the resources to build comprehensive search functionality on that scale.
The key to a great search experience is to present a single set of results that is free of any duplicates but gives the user easy access to the diverse information contained by the different sources of available data.
Search is the logical first step in a user’s journey. It’s faster to search for a place of interest or an address than zooming and panning the map multiple times (see location finder). It’s also easier to search for such things as events, depots, replacement parts, hospitals, or incidents than clicking each individual marker on the map to find out what it is. Combining the search for places and things into one unified search helps users find what they’re looking for in one action.
The search function is complex, but the two most important keys to success are as follows:
- It’s fast: Users want to see immediate results with minimal response times. Your hardware and algorithms need to be optimized to meet this expectation.
- It’s federated: As data becomes more distributed across providers and services, people are used to entering a keyword or phrase without having to know where the results come from — and they shouldn’t need to know. Don’t make them select a data source from a list before they can type their keywords.
The search interface is usually a single input field, sometimes with a leading magnifying glass icon to indicate its purpose. The search may open a list of actions such as locate me and suggestions of previous searches or personalized places, such as your home or work. As the user starts typing a search term, the search engine queries content from different sources and aggregates and disambiguates the results into a single set of search results. Providing an autocomplete feature is recommended, in which the search engine predicts the user’s query and provides suggestions as the user types. This feedback mech-anism allows users to detect mistakes such as typos before they submit a long search term that returns zero results. On the flip side, the constant queries put a strain on the system architecture, so it’s advisable to add a waiting period of approximately 30 milliseconds between keystrokes before the search engine fires the query.
Once the search results come back, it’s important to disambiguate them in a meaningful and logical way that includes removing potential duplicates, weighting results by relevance or importance, indicating the source or nature of the result, and completely removing excess results. Structure the results by grouping them into categories and adding as much information as possible. Consider highlighting the characters that match the search term.
Make the search result actionable and indicate this to the user by changing the mouse cursor to a pointer. Upon the user clicking the result, zoom the map to full extent. If the search result is a point, consider replacing the point with a temporary marker and possibly opening the associated info pop-up. If the result is a line or polygon, highlight or emphasize it in some way.
Not every result has a spatial component (geometry) associated with it. Searching for a person in a directory will pull up the employee, but another query is needed to relate this person to their office, which can be located on the map.
As a government entity, GIS and Data Services, City of Lubbock, Texas, needs to cater to a user base with a wide range of needs. There are Realtors interested in zoning or evacuation zones, mortgage underwriters interested in hazard zones or road ownership, and citizens who want to look up miscellaneous information. Instead of building multiple single-purpose apps, the City of Lubbock decided to build an app based on the assumption that people are familiar with searching, so it is easy for them to start typing whatever they need to find. The autocomplete function then returns results grouped by interest (parcels, addresses, roads). Once a result is clicked inside one of these categories, the app funnels users to the appropriate workflow. For instance, if the user selects an address, the workflow will show details of the property with the option to run an analytic tool to show more information about the property’s surroundings. The app uses full map layout to maximize the map space, whereas all the other map tools are tucked away in the navigation panel. Clicking the menu button opens this panel in which users can toggle layers on and off or change the basemap layer.