{"id":2157,"date":"2013-10-31T13:20:40","date_gmt":"2013-10-31T13:20:40","guid":{"rendered":"https:\/\/irsg.bcs.org\/informer\/?p=2157"},"modified":"2013-10-31T13:20:40","modified_gmt":"2013-10-31T13:20:40","slug":"tabs-facets-and-views-getting-the-interaction-right","status":"publish","type":"post","link":"https:\/\/archive-irsg.bcs.org\/informer\/?p=2157","title":{"rendered":"Tabs, facets and views: getting the interaction right"},"content":{"rendered":"

\"Tabbed<\/a><\/p>\n

As the dominant interaction paradigm used throughout the world of eCommerce, faceted search provides a framework that supports the exploration and selection among thousands – if not millions – of diverse items. But sometimes faceted search needs to be combined with other types of UI control to provide alternative ways to view and organise content. In these cases, the interplay between the various components can be deceptively complex, and small details can make a significant difference to the overall user experience. In this post, we consider some of the issues and examine a number of design solutions.<\/p>\n

<\/p>\n

Amazon<\/a> and eBay<\/a> provide two well-known examples of the use of faceted search in eCommerce. In each case, a cornerstone of their approach is to use a category selector<\/em> as the first element in the faceted navigation menu. This conveys the diversity<\/a> of items in the result set, and plays a vital role in clarifying the intent<\/a> of vague or ambiguous queries (in this case, the term \u2018silver\u2019):<\/p>\n

\"amazon\"<\/a>
Category selection at Amazon<\/figcaption><\/figure>\n
\"Category<\/a>
Category selection at eBay<\/figcaption><\/figure>\n

The user is invited to make a specific category selection, and, once this is completed, the facet is removed from view and replaced by category-specific submenus:<\/p>\n

\"Category<\/a>
Category now selected at eBay<\/figcaption><\/figure>\n

\n

No surprises so far \u2013 after all, the default behaviour for single select facets<\/a> is to be \u2018refined away\u2019 when no longer relevant. But hold that thought – it\u2019s one we\u2019ll return to later.<\/p>\n

Managing diverse content<\/h2>\n

Sometimes the focus of the search experience is not so much on finding<\/em> specific results but on exploring<\/em> a wider selection of heterogeneous content types. We see this in eCommerce when product results are returned alongside associated content items such as customer reviews, buying guides, how-to videos and so on. A query for \u2018LCD TV\u2019 on retailer John Lewis<\/a>, for example, returns results both for products and related articles as two separate lists:<\/p>\n

\"Diverese<\/a>
Diverse content results at John Lewis<\/figcaption><\/figure>\n

Similarly, apple.com<\/a> returns results for products, support and audio content, organised as three vertical lists:<\/p>\n

\"Diverse<\/a><\/p>\n

Such distinctions become even more pertinent for information or content-oriented sites, where the goal is not so much to guide users down a specific \u2018funnel\u2019 (e.g. to the shopping basket or checkout pages) but to encourage them to engage in further exploration and discovery. In these cases, understanding the different content types is fundamental to successful use of the site, so it makes sense to present them as an explicit element of the search experience. Reuters<\/a>, for example, uses tabs to differentiate between news, blogs, video & pictures:<\/p>\n

\"Diverse<\/a><\/p>\n

Similarly, Microsoft.com<\/a> uses radio buttons to differentiate between downloads, support, communities and \u2018all Microsoft\u2019. (It\u2019s likely that the latter is an aggregate of the other three, but in the absence of record counts, we cannot know for sure.)<\/p>\n

\"Multiple<\/a><\/p>\n

Views and subcategories<\/h2>\n

An interesting thing starts to happen when we explore the four Microsoft categories.\u00a0 If you look closely, you\u2019ll notice that downloads has its own faceted sub menu, in this case for \u2018Product category\u2019:<\/p>\n

\"Faceted<\/a><\/p>\n

This is of course not entirely unexpected: it is well known that faceted search implementations can and should use precedence rules<\/em> to trigger the display of secondary menus based on the current navigational context. In this instance, a precedence rule ensures that the submenu for product type is displayed only when category=downloads<\/em> has been selected.<\/p>\n

But this raises an interesting dilemma. As we discussed before<\/a>, facets are, in principle, orthogonal dimensions that can be applied independently to a result set. Therefore, selecting and applying a value in one facet should update the overall result set, and with it the values currently available in other facets. Consequently, faceted navigation menus typically expand and contract to accommodate such changes. In the eBay and Amazon examples shown above, the category selector disappears when its work is done, to be replaced by secondary, category-specific submenus.<\/p>\n

However, when we use tabs (or any other independent view control) to implement category selection, the dynamic changes entirely: in this context, does it really make sense for the categories to disappear once a selection is made? I explored this possibility in a recent design project, and demonstrated to stakeholders a prototype based on this approach. At first, no-one noticed anything unusual, focusing instead on the result content and to a lesser degree on the content of the submenus. But when I drew their attention to the specifics of the interaction, it was met with universal resistance. (Of course, they could have all been misinformed in this instance, but my instinct is their reaction would probably be shared by a number of end users too).<\/p>\n

So we needed instead to find a solution in which the tabs could persist, yet behave consistently as further selections are made. But this raises a further question: if they are to persist, how should changes made in one view affect the others? Should selections apply universally across all tabs, or should the views remain independent, managing their own separate state?<\/p>\n

It turns out that both approaches can be made to work. An example of the former can be found at TripAdvisor<\/a>, where selecting a rating for hotels changes the number of matching B&Bs and speciality lodgings, and vice versa:<\/p>\n

\"Tabbed<\/a><\/p>\n

In fact, the user can continue making selections to the point where the results in the other views can become zero. In this respect, the tabs are behaving like a kind smart dead end<\/a> exclusively for categories: visible, but zeroed out and disabled:<\/p>\n

\"Selections<\/a><\/p>\n

An example of the converse approach can be found at JJ Keller<\/a>, where a search for \u2018signs\u2019 produces a set of 1,216 products and services and 2,562 news and information results, with the former displayed by default:<\/p>\n

\"Tabbed<\/a><\/p>\n

Each view maintains its own navigational state, so that refinements made in one have no effect on the other. For example, selecting specific values for product\/service type, business issue or colour have no effect on the news & information results:<\/p>\n

\"Category<\/a><\/p>\n

Aggregate views<\/h2>\n

Though they run counter to conventional facet behaviour, both the previous approaches allow tabs to persist alongside regular faceted menus, and the navigational state to propagate to other views in a relatively consistent manner. But there\u2019s another issue to consider: under what circumstances is it advisable to show an aggregate (or \u2018all results\u2019) view? In the examples above, Microsoft uses one, but the others don\u2019t. Is this a principled design decision? If so, based on what criteria?<\/p>\n

One criterion might be the transparency of the categories. For example, if they are relatively self-explanatory and mutually exclusive, then an aggregate view would probably add little value. Conversely, if the categories are ambiguous or potentially overlapping to the extent that the user may be unsure which one to select (e.g. \u2018downloads\u2019 vs. \u2018support\u2019 vs. \u2018communities\u2019), then an aggregate view can provide a convenient workaround.<\/p>\n

Either way, an aggregate view needs to be consistent with the others. This means that thought should be given to exactly which faceted submenus it includes, which depends in turn on the dimensions that the categories share. In practice, these can be very few, particularly for enterprise search applications where the metadata is often noisy or incomplete. In this respect, both Amazon and eBay present unrealistic but instructive examples, in that they present a kind of aggregate view by default (at least until a category is selected). eBay is fortunate in that a handful of generic properties such as Condition, Price, Location, etc. are shared by most items, and these can be used to populate the initial view (along with the category selector itself). Amazon takes a slightly different approach and displays a selection of facets from the various sub categories, e.g. author (for books), metal (for jewellery), etc. The inevitable consequence of this is that selecting a value from any of these facets indirectly refines away all the other categories. This outcome may be undesirable for some users, but if it gets others more quickly down the conversion funnel, then it is may be in some sense achieving its goal.<\/p>\n

Summary and best practices<\/h2>\n

One of the great strengths of faceted search is its simplicity: by presenting navigational choices as options in a menu, users can seamlessly navigate and explore complex information spaces. But when these elements are combined with other UI components and views, the interaction can become surprisingly complex. In this post we\u2019ve reviewed some of the key design decisions and outlined a number of alternative solutions.<\/p>\n

Basic principles<\/h4>\n