In the offline world we can utilize physical cues and established conventions for context and constraint. For instance, a traditional product catalog can be searched through established conventions like an index, a table of contents, page numbers, and browsed through section headers and physical cues (the beginning, the back, etc.).
This combination enables us to move between searching and browsing fluidly and to restart easily. Online, however, we are missing the cues and conventions that guide us in the real world. Instead the constraints we employ are always presented to us as flat interface elements.
When the Web was young this wasn’t much of an issue. Search and browse were separated out of technical necessity and users either traversed a category hierarchy or entered a search term. Their choices were clear. Today (thanks to technological advances) searching and browsing are joined at the hip. A search can become a browse (through filtering) as fast as a browse can become a search (through search constraints). For example, you might elect to browse a Web site by selecting a link to the “Music” category. Your item list (of music products) can then be searched via a constraint like “Search for_____ within Music”). Now your browse is a search.
While these types of “finding” systems empower users they can also make the act of locating a product complex. Martijn van Welie’s Web Design patterns detail 21 “common design solutions” for navigating and 10 for searching. Many finding flows utilize several of these solutions simultaneously and, as a result, may create problems for users.
Ina complex finding system, it can be unclear which constraint or filter is in place. Is it the keyword, I just searched on? Or the category I am in? Or perhaps the navigation tab I originally browsed to? Or a combination? Which constraints are giving me the results I’m seeing?
In the Shopping.com example above- what is constraining me? The active tab (home & garden), my search term (stove), the search constraint (kitchen ranges), the breadcrumb (large appliances)? How are they all related?
Sometimes the process of un-finding or backing out of a browse or search path is how relevant items are actually found. But many finding systems don’t allow users to easily relax constraints. Instead users have to start over or worse yet end up needlessly limited to a constraint unknown to them (resulting in few or no matches to their query).
The CDW example above provides a consistent means to remove search filters (keywords) as well as browsing filters (attributes such as categories). This not only indicates what factors are responsible for the current item list, but also allows users to undo portions of their finding process easily.
In our information-saturated cyber lives, a day may come when the process of un-finding (navigating out from specific results) becomes as crucial as finding (navigating to specific results).