Designing Search (Part 1): Search Box Design
Designing Search (Part 1): Search Box Design
Join the DZone community and get the full member experience.Join For Free
Learn how to stop testing everything every sprint and only test the code you’ve changed. Brought to you by Parasoft.
This is the first installment in a series of tutorials on creating the right search utility for your use case. In this part, you will learn how to make the right decisions when picking a design for your search box.
In an earlier post we reviewed models of information seeking, from an early focus on documents and queries through to a more nuanced understanding of search as an information journey driven by dynamic information needs. While each model emphasizes different aspects of the search process, what they share is the principle that search begins with an information need which is articulated in some form of query. What follows below is the first in a mini-series of articles exploring the process of query formulation, starting with the most ubiquitous of design elements: the search box.
1. The search box
One of the fundamental concepts in HCI is notion of affordance: the idea that objects should behave in the manner that their appearance suggests. A push plate on a door affords pushing; a handle afford pulling. How many times have you walked up to a door and found it behaved contrary to your expectations? Invariably this is caused by a mismatch between form and function.
Likewise, the design of the search box should follow its function. If its purpose is to allow the user to enter queries in the form of keywords, then it should look like it will accept textual input, and have an associated button which clearly indicates its function. It should also be wide enough to comfortably accommodate the majority of queries:
The examples below, by contrast, are perhaps somewhat less effective:
The concept of affordance is so fundamental that it should apply universally, across all types of search context and application. However, the major web search engines choose to differentiate themselves through distinct design treatments. Google, for example, uses two buttons on its home page, including the somewhat quirky “I’m Feeling Lucky” option (which takes the user directly to the highest ranked page for the current query). Both of these buttons are centre-justified beneath the text box and given a minimal border which only loosely suggests their function:
However, these design choices are perhaps now so familiar to users that they have become accepted as simply a further expression of the Google brand. Note that the positioning and layout of the search box on the homepage is ephemeral anyway; as soon as the first character is entered the page layout changes to accommodate the results and the search box re-locates to the top left of the page. The search button loses its label and gains a ‘looking glass’ icon, which over recent years has become accepted as communicating a search function:
Bing behaves likewise, offering a similar centre-justified search box on the home page, which also relocates to top left once the query has been submitted:
Yahoo offers perhaps the most conventional treatment, employing a simple layout and button affordance, both of which remain consistent from home page to search results:
All three sites assist the user by placing the cursor within the search box upon page load and allowing the user to press the ‘enter’ or ‘return’ key to submit the query. In addition, they reserve a consistent location for the search box, although only Bing and Yahoo display the search box at both the top and bottom of the page.
They also display the query in the search box after submission, which serves as confirmation to the user of what they entered. This may of course differ from how the query is actually interpreted, particularly if an auto-correct or ‘did-you-mean’ is applied. Retaining the query in the search box also provides a convenient starting point for query reformulation (which we’ll cover in a future post).
On the web, users can search for almost anything, with few constraints over topic or medium. By contrast, in site search (i.e. search of a specific web site), the choices are usually much more constrained. This presents an opportunity to provide further direction in the form of “placeholder” text and other prompts to help users construct meaningful queries. People search site Pipl, for example, informs its users that they can search by name & location, email, username or phone number. Note that this text disappears as soon as the search box receives focus:
2. Scoped search
In some search applications the content is assigned to one or more topical categories. For example, items available on eBay are categorised according to eBay’s content taxonomy. This presents an opportunity to allow the searcher to restrict their search scope to a specific category, e.g. using a drop down menu or similar:
Inviting the user to select a category in advance helps them narrow down their search more rapidly, and enables the refinement options shown with the search results to be tailored specifically to that product category. For example, a query for ‘golf’ in Cars, Motorcycles and Vehicles would present a very different set of refinement options than the same query in Sporting Goods (see the earlier posts on faceted search). Users with high domain expertise can therefore benefit greatly from scoped search, particularly if they are seeking known items.
Conversely, this approach is less well suited to users with low domain expertise, as they may be unsure which category to select at the outset (unless they take the time to learn and understand the site’s category structure). A poor choice can lead to them over-constraining their search which increases the likelihood of zero results and reduces the potential for serendipitous discovery. Classified advert site Craigslist, for example, offers several category choices – but which one would you choose to find focus group opportunities?
It turns out the correct answer is under ‘et cetera jobs’ or ‘gigs’. For this reason, scoped search is usually set to ‘all categories’ by default.
The problem is further compounded if the scope restriction is applied to subsequent queries which are unrelated to the original information need. As we saw in previous articles, search is a dynamic process in which the results of one query can change the immediate goal (or even the work task itself). In cases such as these, it is prudent to apply a fall back strategy that searches across all categories, particularly if searching within one category produces zero results. For example, a search on WARC for “text analytics” produces zero results for Charts, but the same query could have been productively applied to ‘All Categories”. In all cases (but particularly those for which zero results are returned), it is important to clearly display the scope of the search as part of the results.
3. Search within
It is common to think of the search box as the ‘gateway’ to the search experience; the most evident way to initiate an information seeking episode. But there are many cases when keyword search can be productively applied later in the information journey. By allowing users to search within an existing set of results, the query acts as a kind of refinement, narrowing down the results in a manner similar to that of faceted navigation.
For this reason, search within is often presented as a dedicated search box within the faceted navigation menu. Since there are now two separate search boxes on the page, it is necessary to clearly indicate the function of each through the use of placeholder text and other textual labels. In addition, since the keywords are applied as refinements to the current navigational context they should also appear as mementos in the breadbox:
Alternatively, search within can be integrated with the standard search box, using a radio button or checkbox to toggle between the two different types of input. In such cases, the toggle control needs to be sensitive to the application context (i.e. it should be disabled if search within results is not currently possible). In addition, selecting the ‘search within’ checkbox should also remove the current query from the search box (since it is redundant within the current result set).
Since search within offers the user the ability to enter ad hoc refinements which may not match the current result set, it is quite possible that zero results may be returned. Although this outcome is generally best avoided, there are various techniques for dealing with it productively (which we’ll cover in a future post).
4. Advanced search
In principle, the idea of advanced search is to offer search functionality that goes beyond that implied by the basic search box or the ‘standard’ search experience. By convention, advanced search is usually invoked through a link adjacent to the regular search box:
In the days of parametric search, when the interaction was based around the notion of selecting parameters from an ever-growing form, it may have made sense to withhold some of these choices from the default view and present them instead as an advanced option:
But now, with a greater understanding of search as a dynamic, progressive dialogue, there seems less value in adopting an approach that requires the user to make such a commitment in advance of even the first exchange. If you were about to initiate a conversation with a stranger, would you ask that they to choose a tone of voice first (e.g. ‘normal’ or ‘sophisticated’)? A far more productive strategy would be to demand the minimum at the outset, then modify your interaction as the discourse unfolds, reacting and responding meaningfully to each exchange.
Of course, there will always be applications for which it makes sense to divide the audience into two or more groups, such as medical information sites that serve both clinical professionals and the public. But in such cases, a more informed strategy may be to consider how the whole experience (i.e. content, navigation, transactional functionality, etc.) could be adapted for that audience, rather than assume that search alone deserves special treatment. An effective search experience puts ‘advanced’ search tools in the hands of all users, as and when they are able and willing to use them. In practice, many of the instances of ‘advanced search’ as described above have transpired to be either unnecessary, underutilized, or both. We touched on this issue previously, when we reviewed the ways in which faceted search can provide a more elegant and scalable approach to advanced search.
5. Beyond keywords
In the examples above we’ve looked at a number of ways we can search using various forms of typed input. But entering keywords isn’t the only way to express a query. In fact, there are host of other ways we can articulate an information need.
5.1 Natural Language
One of the most intuitive is to express the query as you would to another human being, i.e. as a natural language question or request. This kind of interaction was popularised by search engines such as Ask (formerly Ask Jeeves), which uses a combination of text analytics and human moderation to produce a question-answering search experience:
In fact, natural language has often been portrayed as the “killer app” for search, prompting the creation over numerous start-ups over the last decade or more. However, up until a few years ago, disappointingly few of these had had a lasting effect on the mainstream search experience. This is partially due to the inherent challenge of developing robust algorithms for natural language processing (NLP). But it also reflects the dynamics of the search experience itself: to effectively support human information seeking across the widest range of task contexts, we need to facilitate an open, scalable and interactive dialogue. Answering questions may be part of this, but it is not the whole solution. For some types of application, techniques such as faceted search can facilitate the search conversation in a more transparent fashion than an exchange of purely linguistic constructs.
But that isn’t to say NLP has no future in search. On the contrary, it just needs to be applied in the right manner. For example, NLP techniques are currently being applied to an ever growing variety of chatbots and interactive agents to provide customer service and other types of automated support across a wide range of industries and domains. And at True Knowledge, NLP is used to provide a question answering service that determines the meaning of questions which it then matches against discrete facts in its database. Likewise, Wolfram Alpha uses NLP to answer factual queries by computing answers and relevant visualizations from a knowledge base of curated, structured data:
5.2 Non-text queries
Information needs don’t have to be expressed exclusively in linguistic form. Sometimes a visual medium can be more natural, particularly if an example already exists. Google, for example, allows users to drag & drop an image to use as a search query:
Similarly, Like.com (now part of Google Product Search) allowed users to use images to describe parts of queries which would have been difficult to describe using keywords alone. And beyond visual queries, services like Shazam allow users to record music clips which it then identifies by matching them against a database of audio files.
Each of these services represents a type of search known as query by example. But queries don’t have to be complete samples. Retrievr, for example, allows users to search by sketching a shape or outline. And Etsy allows user to explore by selecting colours from a palette:
Figure X:Search by colour at Etsy
These alternative forms of input serve to remind us that keywords may be the simplest form of input, but they are not always the most natural. Sometimes our information needs go beyond words. Instead, we should choose input methods that match the broader information landscape.
6. Summary and best practices
The search box
- Form should follow function: apply the principles of affordance to interactive design elements
- Reserve a consistent location for the search box, and make it wide enough to comfortably accommodate the majority of queries
- Place the cursor within the search box upon page load and allow the user to press the ‘enter’ or ‘return’ key to submit the query
- Provide direction in the form of “placeholder” text and other prompts to help users construct meaningful queries (remove this as soon as the search box receives focus)
- Display the query in the search box after submission
- Consider scoped search for applications where users have high domain expertise (but avoid forcing this on users with low domain expertise). Ensure that it defaults to “all categories”
- Apply a fall back strategy that searches across all categories if searching within one category produces zero results
- Clearly display the scope of the search as part of the results
- If presented as part of a faceted menu, clearly indicate the function through the use of placeholder text and other textual labels. Ensure that keyword refinements appear as mementos in the breadbox
- If presented as an option to the global search box, ensure that the toggle control is sensitive to the application context. In addition, selecting the ‘search within’ checkbox should remove the current query from the search box
- Review the rationale for advanced search: in particular whether it is better to customise the whole experience (i.e. content, navigation, transactional functionality, etc.) for a specialist audience, rather than assume that search alone deserves special treatment
- Sometimes our information needs go beyond words: choose input methods that match the medium
Opinions expressed by DZone contributors are their own.