CHAPTER 10

THE MYSTERY OF FILTERING BY SORTING

Filtering by Sorting: It Was Colonel Mustard in the Study PAGE 156

The Mystery of Filtering by Sorting PAGE 156

Five Myths of Sorting PAGE 157

Case Study: Redesigning Hotmail Sorting PAGE 166

What is the difference between filtering and sorting for a search query? Any SQL developer would tell you that sort translates to a SQL ORDER BY statement, whereas a SQL WHERE clause performs a filter. However, the practical distinction between sorting and filtering in the minds of typical ecommerce customers becomes more vague as the number of search results increases beyond a few pages. I've called this phenomenon “filtering by sorting”, and it calls into question much of the conventional wisdom around the design of sort and filtering controls.

FILTERING BY SORTING: IT WAS COLONEL MUSTARD IN THE STUDY

During one particularly memorable usability study involving filtering and sorting, my first participant—who I immediately dubbed Colonel Mustard because of his resemblance to the character in Milton Brothers' Classic Game of Clue—kept referring to the sort control as a “filter”. During the think-aloud portion of the usability test, he repeatedly said, “I am filtering by price,” while manipulating an HTML drop-down list that we'd clearly labeled Sort By: Price: Low to High. Despite his confusion, this participant was getting exactly what he was expecting—that is, lower-priced items—using the Sort By control, so sorting was working fine in helping him reach the task's goal. At the time, I attributed this confusion about filtering and sorting to the participant's lack of technical vocabulary and dismissed the finding as inconsequential.

Much to my surprise, many of the participants who followed Colonel Mustard in subsequent test sessions—many of whom hailed from different professions, educational backgrounds, and levels of site familiarity—also said, “I am filtering by price,” while manipulating that same Sort By control. After observing this phenomenon numerous times, it became clear that this was not merely a matter of simple confusion of terms between filtering and sorting. Instead, it revealed a strong mental model of “filtering by sorting” that blurred the difference between these two modes of search results refinement.

THE MYSTERY OF FILTERING BY SORTING

As children, we learned to understand sorting by ordering small numbers of items. As adults, we now often sort search results that include hundreds of thousands or even millions of items. At first glance, we might not see any difference between the two tasks. Regardless of the sample size, we think our childhood training should apply perfectly to sorting 100,000 items by price, even without our understanding what's going on technically. Why then this strange confusion between filtering and sorting?

To understand this phenomenon, you need to take into account how people look at those 100,000 items after they are sorted. Research clearly demonstrates that, despite there being a virtual cornucopia of data, people usually see only a small number of items in each search result set. As Jakob Nielsen wrote in Prioritizing Web Usability:

“Obviously all users saw the first screenful (the one above the fold). But viewing frequency dropped off rapidly after that. More than half the users didn't scroll at all, so only 42% of users saw any information on the second screenful. Only the most persistent one percent of users viewed more than seven screens worth of information.”

Although it's generally hard to measure how much people scroll, my own experience studying pagination on ecommerce sites supports this finding. For a result set of 100 items per page, most people do not view even the second page of results, and almost nobody goes past the third page of results. Thus, from a customer's point of view, for a result set of 100,000 items, sorting by price actually filters the result set by selecting at most 300 items with the lowest prices and effectively removing the remaining 99,700 higher-priced items from consideration. This is what Colonel Mustard and other participants referred to as “filtering by lowest price,” when changing the sort order. Thus, I decided to call this phenomenon “filtering by sorting.”

FIVE MYTHS OF SORTING

Usability expert Dan Norman famously said, “There are no secrets of usability, no more than there are secrets of astronomy.” Anyone using the correct usability testing methodology would observe the same behavior in their own studies. The catch is using the right methodology. Most companies build prototypes for testing their software in a lab. Prototypes are expensive to build and populate with data, so most usability tasks include as few preset items as possible—usually on the order of a couple of hundred—to test the discoverability and usability of various filtering and sorting controls. For my study, I lucked out and got a large test database, which allowed me to observe this filtering by sorting mental model.

When you accept the mental model of filtering by sorting, you can see all kinds of interesting implications for search user interfaces. It becomes necessary, for example, to debunk some myths about sorting that Web development professionals have long accepted as truths. Hopefully, looking at these myths will inspire you to think about killing a few of your own sacred search user interface cows, in the interest of improving the search experience on your site.

Myth #1: Sort Should Be Visually Separate from Search Filters

Typically, sorting controls are outcasts among search controls. Not wanting users to confuse sorts with filters, most designers place sorting options in a drop-down list that is as far removed as possible from the search box and filters on the left. This outcast placement results in users not using sorting controls as much because it sends a clear signal that these controls are not as important as the others. I recall a project in which the marketing lead suggested we remove the sort control altogether and replace it with an ad. Apparently this sentiment isn't particularly rare. As Figure 10.1 shows, on Amazon.com, sorting is not even available until a customer chooses a category.

FIGURE 10.1 Amazon.com makes customers choose a category before sorting

The ostensible need to visually separate sorting and filtering controls is a myth. As discussed earlier, for search result sets that exceed a few pages, which covers most queries on the majority of ecommerce sites, filtering by sorting phenomenon kicks in, making the distinction between sorting and filtering less distinct. Thus, for most consumer-facing applications, articulating what such controls do in general terms is enough. Understanding in detail how sort is different from filtering is not critical to a customers' ability to find what they are looking for. There is simply no value in placing sorting controls far away from filtering controls.

In his book Don't Make Me Think, Steve Krug proposed that you should place search controls in such a way that users can read their settings as an English sentence. This provides a perfect way to position sorting controls. In Figure 10.2, you can see my proposed redesign of a typical ecommerce user interface, using an English sentence structure for better placement of the sort control.

FIGURE 10.2 Incorporating filtering and sorting controls in a sentence

Although, at first glance, the proposed search user interface appears to be slightly more complex than the Amazon user interface shown in Figure 10.1, this redesign ensures that the Sort By control is in a more noticeable position and would be considerably easier for most people to understand and use. This is important because according to my field and lab study observations, sorting is much more successful than filtering in some cases.

Myth #2: Sorting Is Less Successful Than Filtering in Helping Customers Find Content

Anyone who's ever observed a usability study that involved filtering search results by setting a price range can readily attest that shoppers tend to over-constrain their queries. A good example would be a task such as “find a digital camera that fits in your pocket and costs around $100”. Most people respond to this simple task by setting the price range to—you guessed it—Price: from $100 to $100. A typical search user interface would invariably respond to this query by returning no results. This outcome is the result of a basic mismatch between a human's understanding of what “around $100” means and the machine logic that delivers precisely what the user asked for—no more, no less.

As it turned out, in the study in which we asked participants to shop for a digital camera, there were about 50 camera models for sale under $99.99 and about the same number for sale over $100.99. The mean price for cameras on the site happened to be $100, so this price should have been a perfect starting point for exploring the site's inventory. Instead, the nature of the search user interface caused users to manipulate the filters in a way that was detrimental to their success in finding a camera.

As Neal Stephenson said in his book, In the Beginning… Was the Command Line:

“Giving clear instructions, to anyone or anything, is difficult. We cannot do it without thinking, and depending on the complexity of the situation, we may have to think hard about abstract things and consider any number of ramifications, in order to do a good job of it. For most of us, this is hard work. We want things to be easier.”

To use range filtering controls effectively, you must give instructions to the system that are sufficiently precise—but not too precise.

The same goes for price sliders that do not show the price range for the available inventory and make it too easy to over-constrain the query to a single price point or to too small a range. (Chapter 8 covers sliders.) And, although most people would not care whether they spent $99 or $109 on a camera, those same people would care deeply about spending $99,000 versus $109,000 for a house. In the latter case, rather than a price range, the upper limit of the user's price range would be a more appropriate filter for a query. However, for most ecommerce applications, price is at best a fairly vague parameter such as “around $100.”

Additionally, most people do not have a clear idea of a price they would expect to pay for most items and are easily swayed by other factors such as features, brand recognition, ratings, and social pressures. Thus, in many cases, a well-placed Sort By Price control is often much more successful in producing a useful set of search results than a filtering control.

In contrast to filtering, sorting controls never produce zero search results. So, sorting eliminates many of the common search misunderstandings that people encounter with filtering and help people to be more successful, while applying considerably less thought. Sort displays the result set in the right configuration for efficient exploration. If, when sorting by price, a customer chooses the Lowest Price sort, budget models appear first, enabling customers to reach their target price point via scrolling. If a user chooses Highest Price sort, the search results present a useful entry point to the higher-end models. For finding midrange cameras, the most appropriate interaction model would be a combination of sort and filter. We'll get to that in a moment. For now, let's just say that, in many cases, sort is a great way to entice your customers to explore the site inventory so that they'll find something interesting. Search success leads to more satisfied customers who come back more often.

Based on my research for consumer applications, I can state with confidence that sorting by price—high-to-low and low-to-high—is quite intuitive and quickly understood by diverse audiences. So, unless we are talking about the larger sums of money customers might spend on cars, real estate—and political donations—a simple bidirectional Sort By Price control is sufficient, even without using a price filter.

Myth #3: Sort Should Be Hidden in a Drop-Down List

As mentioned earlier, various sorting options offer superb starting points for browsing the inventory on an ecommerce site, so there is no reason to hide them in a drop-down list. The Apple iPhone App Store shown in Figure 10.3 provides a great example of an alternative sorting user interface. The two buttons at the top of the screen and all the tabs at the bottom are actually—you guessed it—examples of sort-by controls that have been liberated from a drop-down list.

What makes this user interface successful? For this screen, a typical use case might be something like this: “Find a new to-do list application for your iPhone that is easy to use.” The best way to accomplish this task is actually through browsing because searching by keywords like to do easy to use is not likely to be productive. As we all know, these days, most manufacturers tout their applications as “easy to use” when they are nothing of the sort, and with thousands of iPhone apps in the app store, the application's name is unlikely to match its function closely. Therefore, a better finding strategy might be to browse Productivity Apps, sorting by Most Popular or Highest Rated. The strength of using a tabs-based sorting mechanism as the App Store's primary navigation is the ability to offer inventory in a format that is optimized for a specific entry point, thus forming a series of parallel views of their inventory. These tabs-based sorting controls are extremely usable and intuitive, and readily contribute to a customer's success.

FIGURE 10.3 The iPhone App Store's sort-by controls facilitate browsing

Myth #4: Sorting and Filtering Cannot Be Combined in One Control

As the amount of information retrieved increases, sorting search results becomes less and less about reordering the results and more about providing a convenient way to massage the results into a manageable form that more closely matches the person's goals. This is especially important for user interfaces with limited screen real estate—like those on the mobile platforms. However, even on the Web, the demarcation between filtering and sorting is not necessarily a rigid one. For example, as Figure 10.4 shows, the Facebook applications inventory screen conveniently combines sorting and filtering in the same drop-down list.

FIGURE 10.4 Facebook combines sorting and filtering options in one drop-down list

For example, the Recently Used setting sorts the entire applications inventory by date of use, whereas Bookmarked or Authorized are basically filtering controls based on flags.

Of course, there are some disadvantages to simply throwing a bunch of sorting and filtering options into the same drop-down list. For example, in the case of the Bookmarked or Authorized filters, the order in which items in the inventory appear is not clear. In the case of Facebook applications, filtering by bookmarked apps may be the primary intent, and sort order might not matter much. However, in some cases, you can apply the principle of filtering by sorting to combination sorting and filtering controls to create a more graceful user interface (see “Case Study: Redesigning Hotmail Sorting” at the end of this chapter).

The best sites use a creative combination of sorting and filtering to help customers reach their goals faster and easier. For example, Netflix combines Top 50 and New Arrivals sorts with a Genres filter on the navigation bar under Watch Instantly, as Figure 10.5 shows.

FIGURE 10.5 Netflix navigation offers a combination of sorting and filtering controls for exploring their inventory

Clicking New Arrivals sorts the Netflix inventory by date of entry. In contrast, the Genres drop-down menu filters the inventory by category, sorted by relevance. These two controls coexist on the same navigation bar without causing any confusion and reflect the most efficient and popular ways to drill down into the Netflix inventory.

Top 50 is an interesting variation that combines a popularity sort with a count filter that cuts off the list of results at 50 items. There is no technical reason for cutting off the popularity sort at 50 items. However, people who use such features might feel that a Top 50 or Top 100 list represents a manageable number of items they can explore effectively, whereas a list of 100,000 movie titles sorted by popularity could be quite intimidating.

In your own search user interfaces, look for opportunities to address your customers' goals by providing appropriate combinations of controls. If it is appropriate for a task, do not hesitate to place sorting and filtering controls side-by-side—or even to combine them in creative ways that help people meet their goals.

Myth #5: Sorting Implemented Using Column Headers Is Superior to Other Sorting Methods

Clickable column headers are an excellent way to implement sort user interface—they save screen real estate and look slick. Is header-based sorting superior to other methods, like tabs and drop-down? The answer is, as always: It depends. At least when it comes to ecommerce, the header sort has the following serious drawbacks:

• Some people do not realize that the column headers are clickable.
• It's hard to tell a sort direction on a column at a glance. (Up/down arrows do not always translate into tangible sort direction, like price low to high, for example.) Most people click a column header several times to figure out the sort direction.
• Default sort direction (for example, always descending, the down arrow) does not always translate correctly to the primary use case, so some headers always need to be clicked twice. To accommodate the most common use cases, some columns like Date, need to start with sort arrow up (for example, Most Recent First), whereas the others such as Price start with the sort arrow down (for example, Cheapest First). This mismatch between the initial sort directions for different primary use cases introduces additional elements of confusion and cognitive friction to the interface.
• It is difficult to clearly indicate common “combined sorting” conditions, for example, Sorting emails by Sender and Date, Newest First.
• It's impossible to allow sorting by an attribute that is not shown in the columns, for example, the primary Amazon use cases of sorting via Bestselling and Most Popular can't be implemented via header sort unless you display a Sales Rank and Popularity columns, neither one of which carry any useful information.
• Column headers do not readily translate into mobile UIs due to a lack of horizontal screen real estate.

In most common ecommerce applications, tabs and drop-downs generally work better as Sort By user interface controls than column headers. Drop-downs (and to the lesser extend tabs) enable the designers to specify precisely what items will appear first using natural language that maps best to a user's mental model. Drop-downs are by far the most common because they are more flexible and completely independent from the format and nature of the data in the search results and are more frugal than tabs with screen real estate. For example, the Price: Cheapest First drop-down option and a Most Popular tab both offer clear, unambiguous, and goal-oriented sort controls. It is difficult to achieve this level of clarity with a sort implemented via a column-header.

CASE STUDY: REDESIGNING HOTMAIL SORTING

Often a well-chosen combination of sorting and filtering controls, creatively recombined to allow the customer to apply both controls together, creates a more useful and intuitive experience. For example, the Sort by drop-down list in Hotmail, shown in Figure 10.6, combines various Sort by options—including Date, From, Subject, and Size—with just a single filtering option: Show only messages with attachments.

FIGURE 10.6 Hotmail combines many sorting options with a single filtering option

Although there is nothing wrong with combining sorting and filtering, in this case, the filtering task is the odd one out. It is separated visually from the sorting options, and it appears that the text of the filtering option wraps. You are left wondering how email messages with attachments will be sorted. In this case, their sort order is not a trivial matter. Will messages be sorted by date or by attachment size? If by attachment size, in what order—ascending or descending? How does this differ from the Sort by Size option?

If you use the filtering by sorting paradigm, you can avoid all this confusion by adding a fifth sorting option, Sort by Size of Attachment, as shown in Figure 10.7. In this case, messages without attachments would follow those with attachments. (Logically, messages without the attachment have an attachment size of 0.)

FIGURE 10.7 Proposed use of the filtering by sorting paradigm in Hotmail

By adding this sorting option, you avoid splitting options in the drop-down list into two groups and create a much more minimalist and graceful user interface. This option even follows the existing paradigm that enables two-way sorting by attachment size—ascending and descending (the choice that is missing from the option Show only messages with attachments that enables only filtering).