"If you have to ask what jazz is, you'll never know."
In music, improvisation is the art of creating a song while performing it, in the moment and in response to interplay and interaction. Along with blue notes, polyrhythms, and syncopation, improv is fundamental to the nature of jazz. The freedom and spontaneity of the solo passes from saxophone to piano to trumpet in the call-and-response pattern of African-American field hollers, while the drums and double bass weave a musical fabric in conversational rhythm. Good jazz engages the listener. It's hard to resist the spellbinding power of a player with chops who's in the pocket. We become fully immersed in a state of flow that dissolves the lines between act and actor. As the artist Henri Matisse once noted, "There are wonderful things in real jazz, the talent for improvisation, the liveliness, the being at one with the audience."
In designing the interaction of search, we'd do well to keep jazz in mind, because behavior is a conversation and flow is a state worth striving for. When we search, our actions are reactions to the stimuli of information and interface. The box and its controls shape how we search, and what we find changes what we seek. The distinction between user and system dissolves in behavior. It's an activity that's open to flow. At its best, search absorbs our attention totally. Our experience of time and self are altered. We become lost in the most positive of senses. But we don't get in the groove by accident. As Mihaly Csikszentmihalyi explains, activities such as music, dancing, sailing, and chess are conducive to flow because "they were designed to make optimal experience easier to achieve."[11] They offer challenge, give control, support learning, reward skill, and provide feedback. We can both design for flow and experience flow in design, since our practice offers ample challenge and reward for those with the chops to put the swing in search.
Of course, music isn't written on a blank slate. In the words of Wynton Marsalis, "Improvisation isn't a matter of just making any ol' thing up. Jazz, like any language, has its own grammer and vocabulary. There's no right or wrong, just some choices that are better than others." Similarly, there are patterns of behavior, elements of interaction, and principles of design that form the building blocks of search. The elements are always in flux. Technology shifts interaction from mouse and keyboard to multitouch to freeform gestures in thin air. But our patterns and principles? They're timeless, both limited and inspired by the nature of information and the inherent affordances of our senses.
Search ends with an exit. Users always quit. The question is, why? Did they find what they need or simply give up? Was it the information or the interface? Too little, too much, too slow? Quit is a pattern that demands analytics. We must know the reason they're leaving.
For instance, are we sending users away with No Results? If so, perhaps we can improve the interface. In Figure 3-3 Yale University fails to state the system status clearly (e.g., "No results were found"), but otherwise provides a good combination of feedback and next steps. Links to popular pages and popular searches might also be helpful.
On the other hand, if we can help users avoid "No Results" in the first place, that's even better. As Figure 3-4 shows, we're less likely to reach a dead end at Amazon, thanks to the autoexpand strategy of partial match, in which unrecognized keywords are omitted from the query string. Even a match against some search terms may be better than none.
When users don't quit, they refine. Narrow is the second most common pattern around. Our initial query casts a wide net. Upon seeing results, we pull back. Sometimes, we can avoid such initial imprecision. A wider box invites more words. So does experience with large (and growing) bodies of content. In fact, the average number of keywords per query in web search has moved from 1–2 to 2–3 in recent years.
But presearch has its limits. Advance query specification is difficult, because we don't know the size or structure of the index. When we're searching without a map, even a traditional SERP tells us a lot. The nature of snippets and the number of results lets us judge how (and how much) to narrow. In particular, diversity algorithms ensure we can sort out synonyms. Upon seeing sample results from each distinct meaning (e.g., psychology versus cover flow), we can disambiguate our query.
Even better, faceted navigation puts metadata on the map. As Figure 3-6 shows, Artist Rising lets us clarify whether we want drinking bars (places) or lemon bars (cuisine) and photos or paintings. Plus, we can refine by searching within these results. And even Sort provides a way to limit what we see. Artist Rising offers us many ways to narrow.
The opposite pattern is rare. Expand is uncommon, partly because users often cast a wide net to begin, and partly because it's a harder problem. Of course, users can try a broader query. When "low fat lemon bar" returns no results, we omit "low fat" and try again. And we can relax constraints. In Artist Rising, we can undo facet value selections or remove keywords to expand the query by closing the box. We can always take a step back.
However, explicit support for expand is rare. It's most commonly seen in the thesaurus browsers of library databases, as shown in Figure 3-8 where structured vocabularies and the risky expectation of searcher expertise afford designers a sense of freedom to reveal the hierarchy (and potential polyhierarchy) that connects to broader terms.
Rather than a formal hierarchy, search applications often let users expand (or at least explore) by showing related terms within matching categories, as shown in Figure 3-9.
Independent of interface, expert searchers employ a singular strategy for expansion known as pearl growing. Find one good document, then mine its content and metadata for query terms and leads. We might look for more articles about this topic, by this author, or from this source. Pearl growing is an old trick that's taught in library school.
Fortunately, pearl growing is also a strategy we can spread by embedding it within the interface. Google's Similar link is the most ubiquitous example. Although the algorithms may be complex, the user needs only to click a link.
Similarly, music recommender systems make it easy to find songs we like by comparing the attributes, ratings, and collaborative filtering data of songs we know and those we don't. Last.fm and Pandora rely heavily on up and down ratings of individual songs.
iTunes Genius, shown in Figure 3-13, pays more attention to the songs in our personal collections. Either way, these systems make pearl growing fun and easy. From one song, we can find many similar songs to buy and enjoy.
The patterns of behavior we've covered so far—quit, narrow, expand, and pearl grow—are timeless. They are inherent to search. Other patterns (or antipatterns) are produced by bad design. For instance, repetitive bouncing between the SERP and individual results is known as pogosticking. A little pogosticking means users are sampling results. That's to be expected, but when it happens a lot, it's not sampling; it's a symptom.
Perhaps our snippets and metadata lack the scent users need to effectively scan results, so they must visit each one in turn. Or, if sequential viewing of results is a desirable pattern, we need solutions that support this behavior. Cooliris, shown in Figure 3-15, uses the iPhone's touchscreen to let users flick through image results in linear fashion.
Lands' End, shown in Figure 3-16, ensures the metadata and features that users need are available in the gallery of search results. It doesn't stuff too many results on the page at the expense of rich summaries. A clear product image, displaying the sole on rollover, inline color selection, the name, and the price are just the right mix for most users.
Another common antipattern is thrashing. In thrashing, a design flaw resides in users' heads in the form of the anchoring bias. We set the anchor with our initial query, and then, despite poor results, we insist on small variations of the flawed search phrase rather than trying new approaches.
For instance, a user searching for a concert may try many queries that begin with the (misspelled) nickname rather than switching to the performer's full name.
| sachmo |
| sachmo concert |
| sachmo jazz concert |
| sachmo jazz festival |
| sachmo music festival |
| sachmo summer celebration |
In Figure 3-18, Yahoo! illustrates two ways to break this pattern. First, autocomplete helps users avoid typos and get the query right to begin with. Second, autosuggest can recommend related queries that don't include the original search term. This feature taps query reformulation data, the terms users enter after their first search fails, to make this semantic leap and help users who start in the wrong place to weigh anchor and move on.
In fact, by identifying related concepts, autosuggest helps users to move forward (refine), backward (expand), and sideways (related). Like many good design patterns, autosuggest multitasks. It's a timely solution to a timeless problem. After all, both autocomplete and autosuggest are recent additions online, made possible by the advance of technology. Even as core patterns of behavior endure, design patterns must adjust to new possibilities, which is why we must keep our eyes (and ears) attuned to the elements of interaction.