Faceted navigation is part of every major intranet search engine. In SharePoint, this feature is called “Refiners,” and the navigation panel’s name is “Refinement Panel.” It is responsible for allowing the users to access the search results filtered and organised according to a pre-defined classification system.
To create refiners on a SharePoint intranet (on-premises or online), there are several steps to follow. In this blog post, I’m summarising these practical steps and also provide best practices.
Search refiners are always discrete properties of the content presented as search results. First, they can be metadata in the source system, which can be used “as is.” For example, the author of a document, project ID, etc.
In other cases, we have to prepare the metadata, by using an auto-classification system, for example. In this case, the metadata we need in search is not available in the source system, we have to extract it from the content. The extraction of the metadata can be done by a specific dictionary, or according to pre-defined rules. For example, location info, the topic of a document, etc. Which is not available as metadata in the source system but implicit included in the content.
Once the metadata is available (either as is, or generated automatically), we have to consider if any normalisation is needed. Normalisation might be required in the following cases:
- We have multiple source systems, and the metadata is available (or has been prepared in the previous step), but the different systems use different names for the same property. For example, “author,” “creator,” “authored by,” “writer,” “created by,” etc. can be used for the same thing, but with different names. The end users don’t mind the property’s name in the source systems, what they want is to be able to refine the search results by the property. In this case, what we have to do is to create one property in the index and map it to each of these various instances, then use it on the user interface.
- We want to transform the data. For example, instead of displaying ZIP numbers on the refinement panels, we need the names of the cities instead. Another typical example is transforming e-mail addresses to person names, for example displaying “Agnes Molnar” on the refinement panel instead of the e-mail address of “Agnes.Molnar@SearchExplained.com.”
- The properties have to be combined. For example, if we have two separate properties for Last Name and First Name, a good practice to combine them into one refiner value in [FirstName LastName] (”Agnes Molnar”) or [LastName, FirstName] (”Molnar, Agnes”) format.
Of course, these transformations might be combined as well. In SharePoint though, the capabilities are limited. Although we have a feature called “entity extraction,” this has a very limited functionality. In the majority of use cases, we need additional, third party solutions.
Content Metadata is the set of properties, which the content has in the Source System (implicit or explicit). In most cases, different systems (and subsystems) have different set of properties, therefore normalising and unifying them is a critical step in every Enterprise Search implementation.
Search Metadata is defined in the Search Schema, and consists of Crawled Properties and Managed Properties (see below). Search Metadata is essential for every Search Application, as it describes the results, can be used for filtering and sorting the results, refiners, and also display on the Result Set or Hover Panel.
Crawled Properties are the representations of the Content Metadata in SharePoint and Office 365 Search Schema.
Managed Properties are the Search Properties which can be used on the User Interface, and in Search Applications. To define where to get their values from, they have to be mapped to the proper Crawled Properties.
User Experience Considerations
Once the metadata is prepared and added to the search index, we can start using it on the user interface. In SharePoint, Refinement Panel is a Web Part available out-of-the-box, which can be customised in an easy way.
The Refinement Panel We Part has various data types to display as refiners (facets): numbers, text values as well as dates. Some configuration can be done in Display Templates, which describes how the refiners have to be displayed. For example, whether to display the item counts or not (see https://searchexplained.com/refiners-in-sharepoint-2013-search/).
We can also create (or purchase) custom developed refiners for advanced scenarios. For example, when we need charts or maps to be used as refiners, but also to create refiner hierarchies (for example, based on a taxonomy).
When planning refiners for faceted navigation, the primary thing to keep an eye on has to be the user needs and requirements. Driven by them, we have to plan the properties accordingly, as well as the user experience. In several cases, we have to use the out-of-the-box capabilities, which are powerful although limited. In other cases, it’s possible to extend these capabilities with custom and/or 3rd party tools, therefore, we have more freedom during the planning phase.
Whatever your situation is, planning refiners has to be a thorough process, as it is a major part of the overall user experience.