Typically, users know what they’re searching for even before they choose a search engine over the site’s navigation. In this investigation, I’d like to explore how we can provide a user interface to help them search more effectively before they get started.
This investigation is about the ordering and structure of the search fields themselves, not the results, which have been the topic of much discussion already. For reference, I will refer to these interfaces in one of four ways: Standard, Surfacing, Qualifying, and Passive interfaces.
The standard search interface is the simplest. It typically includes a label, text entry field, submit button, and link to a more specialized search. Labels are optional if users can clearly understand the function of the field. Yahoo, for example, is a search engine, so the need to label this box as such isn’t as important. Instead “Search” is used as the button name to reinforce its purpose. Microsoft, on the other hand, labels its field “Search” and uses “Go” as the button name, saving horizontal space while maintaining a clear relationship among the elements.
By contrast, surfacing interfaces display part or all of the site’s taxonomy at the first level, thus bringing the site organization to the surface. By adding these kinds of filters, designers enable users to quickly narrow down their search.
Surfacing interfaces often include a label, pull-down menu (or radio buttons), search entry field, a more specialized search, and submit button. Most often seen in e-commerce sites, surfacing interfaces are useful when a search request can be found across multiple categories. The pull-down menu should most often be placed before the entry field, so it is clear that these functions work together. This placement is critical if users cannot search by all products.
The third group I call qualifying interfaces. While this group is visually similar to the surfacing category, it should be given some attention. Similar to surfacing, qualifying interfaces often include a label, search entry field, pull-down menu (or radio buttons), a more specialized search, and submit button. The pull-down menu, however, is generally displayed after the entry field to allow users to qualify the search query. In this case, users are not choosing from categories, rather these qualifiers tend to be time- or location-based. This organization is useful if you have large amounts of content that users will recognize based on location, rather than name.
Another example of the qualifying type is the AltaVista-type interface. Although AltaVista is a full-text search engine, it provides language search “filters” in addition to its search field. Because it provides a free translation service, they are able to provide the qualifying criterion of language to the search interface. I’d argue that this is another example of users recognizing content based on location, rather than name.
Google extends the metaphor by using design elements to communicate its filters. Toggling between tabs allows users to choose a “filter,” while seeing more information related to that filter. Its not immediately clear, however, how to search using all filters, although it is possible. Despite your desire to place this one in the “qualifying” category, I think this one deserves its own interface category.
Using a passive interface is also a design decision: one that tries not to attract attention. Perhaps you want to encourage use of the navigation to gently guide users toward content or marketing for a site. Perhaps you can safely predict that a site’s search results will not be very reliable or clear. In these types of cases, a passive interface makes sense. You can’t dissuade users from searching, but you can try to making other navigation elements more attractive.
Passive interfaces are also seen when search is useful and important, but there is no space to spare. Eddie Bauer has placed the Search link in the same nav bar with its primary categories, giving this link equal visibility. Mousing over this link displays a layer that includes all the necessary information. While using a dhtml layer to provide the entry field isn’t the standard, it is clear and works well with the navigation system in place.
Despite the patterns mapped out here, these only represent a little piece of the many combinations you’ll happen upon. My intention here is to show that these (and other) patterns do exist, and it’s up to us to make sense of how we use them.
Many times, it’s easy to follow established patterns, but more difficult to ensure they match a particular set of user needs. By encouraging clients to think about the specific purpose of search, we can create interfaces that communicate their purpose even before the interaction.
Perhaps these interfaces will change each time we design a page. In fact, I hope they will. As we explore situations that call for new solutions, I hope we can leverage some of the standards already out there.