SharePoint 2010 Faceted Search

SharePoint 2010 Faceted Search

Give users what they’re looking for

The search experience in Microsoft SharePoint has improved continually throughout the product's more than 10-year lifetime. This is just as well. Otherwise, SharePoint would stand no chance of supporting the needs of end users in today's world of information ubiquity.

The information explosion, ever-increasing business pace, and user expectations place many challenges on search engines. Fortunately, SharePoint provides a feature that many people refer to as faceted search. Also known as a search refiner, faceted search enables users to navigate search results in an intuitive and context-sensitive way so that they can more quickly find the information that they're looking for.

The Importance of Search

Everyone engages in searching -- frequently. However, too much search activity indicates that the information you seek isn't easily findable. Extrapolating this issue leads to the conclusion that you aren't exploiting your company's intellectual capital to its fullest. When this happens, end-user productivity is affected. Not only do users end up frustrated, but they can never be 100 percent confident that the information they're working with is truly the best and most relevant for the task at hand.

Users often reach for that search box in high anticipation of quickly finding relevant information, only to have their expectations instantly buried in an avalanche of search results that appear to have little connection to their quest. This leads to disappointment and mistrust of the search system. The end user's view: "I asked you to find something relevant, and you can't even do that one simple thing!" (to paraphrase a line from the film Superman 3).

But fixing this problem isn't simple. Ensuring that the absolute best information is returned to a search query is difficult for many reasons:

  • Volume and scope of information sources. Your information assets tend to be very large and spread out through multiple repositories, so finding the best answer is usually akin to finding a needle in a haystack.
  • Highly structured to highly unstructured information sources. This challenge essentially relates to how well your information assets can be identified via metadata (i.e., data that describes the information, such as who the author is, to which project the information belongs, when the information was created, and so on). Some information strictly adheres to a known taxonomy, other information tends to have partial metadata that might or might not adhere to a taxonomy, and still other information has no metadata at all associated with it.
  • Non-exhaustive content. Your information assets are not just contained within documents. Tacit knowledge abounds, so search results should also consider the people that have the knowledge you seek. Information sources external to your organization might also be able to help users achieve their goals.
  • Relevance requires a context. If the context in which the search query is executed is not understood, then returning the best information is almost impossible. Often, no context is given for the search: Users simply enter some keywords into a search box and expect the best.
  • User context is generally unknown. This challenge is similar to the previous one but refers more to implicit context that's based on who the user is. Users expect results that are relevant to them, so different results need to be returned for different people. For example, if an engineer searches for drawings, then returning engineering drawings is relevant -- whereas the same search by a painter should return works by artists.
  • Ambiguous and incomplete query terms. Users expect the search engine to find the right thing and therefore often enter minimal terms in the query request. Users also might struggle to determine the best terms to enter and might have issues such as not knowing how certain assets are named in the system. For example, users' first names and surnames can often be difficult to enter correctly. All this makes it even more difficult for the search engine to return the best information.

Given these challenges, search should not be viewed as something that always delivers the right results the first time. Rather, it should be viewed as an interactive utility that guides the user through the information jungle to the appropriate destination, in as few clicks as possible. Successfully tackling such issues is key to ensuring that search aids information-worker productivity rather than being seen as a barrier and that search becomes a valuable business tool that can be relied on and used to achieve better business outcomes.

With this in mind, let's take a look at how refiners and the Refinements Web Part deliver functionality that can lead users to their destinations, without frustration.


Refiners (aka faceted search) are a key feature that let users further navigate the search result set by using what are essentially smart filters or groupings. Refiners are typically presented in the left navigation area of the search results page by using the Refinements Web Part. Refiners facilitate the idea of a conversational user experience.

Refiners are determined dynamically, based on the returned result set, the calling user, and the search results page. In Figure 1, you can see three Refiners -- Result Type, Site, and Author -- displayed at the left side of the page. More refiners, such as Modified Date and Wiki Categories, are presented further down the page.

Figure 1: Search refiners
Figure 1: SharePoint search results showing search refiners in the left column 

The dynamic nature of refiners can be understood best by looking at the Result Type refiner that Figure 1 shows. Here, you can see the ability to further filter the result set by either Microsoft Word or Excel. This tells you that only Word and Excel items were returned in the search results. If, for example, a Microsoft PowerPoint document was returned, then you'd also see an option to filter by PowerPoint.

You can navigate further into some of the refiners, such as the Site refiner that Figure 1 shows. Here, you can see that we have navigated into the namespace and found three site collections within. This information tells you that the result set came from only these three site collections. Therefore, you can home in on the content you seek with a few clicks.

Tags that users have used to mark content can also be used as refiners. This approach lets you navigate the result set to find pages that are being tagged by the whole community. Such pages are usually wonderful candidates for relevant content because it is the community that is ultimately surfacing them in the search results. How very social!

When you click a refiner value, the search results page is called, with suitable query terms that ensure that only the refined content is returned. The "r" query string is used to pass the desired refiner to the query. As an example, the following URL is associated with the Excel result that's shown in Figure 1:"odc" fileextension="ods" fileextension="xls" fileextension="xlsb" fileextension="xlsm" fileextension="xlsx"

The Refinements Web Part

Refiners are displayed via the Refinements Web Part. The configuration of this Web Part determines which refiners are listed for the current result set. The XML that's associated with the Web Part is used to define filter categories, which are mapped to SharePoint managed properties that are in the search index or to managed metadata that is defined in the SharePoint Managed Metadata service. Through this XML, you can control how to determine the displayed refiners, how many refiners are displayed within each category, and so on. You can also define how to associate items that match the search query and a particular filter category. For example, the filter category for Result Type indicates that the file extension for managed property should be used and that extensions that are equal to xlsx, xlsm, and so forth, should be included in the Excel category. (We'll discuss how to view the default XML that defines such filter categories in a moment.)

The XML can also perform relative calculations on the value of a managed property to determine its filter category. For example, the XML for the Modified Date filter category instructs SharePoint to calculate the number of days that have passed since the Write managed property was last updated in order to determine whether the item should appear in the Last Week, Last Month, or Last Year filter category. Figure 2 shows some sample XML for the Modified Date category.

Configuring and Customizing the Refinements Web Part

To view the default XML for the configuration of the refiners on the Refinements Web Part, edit the Web Part and view the contents of the Filter Category Definition text box in the Refinement section, as Figure 3 shows.

Figure 3: Refiner configuration
Figure 3: Viewing XML for refiner configuration 

As an example of how to add your own refiners, suppose that you've added a custom property called Instrument to various items in your body of indexed information. Furthermore, you've configured this property to be a managed property (using SharePoint Central Administration or Windows PowerShell), so it can be used as part of a search query (amongst other things). If you wanted to use the different values of this property as a single filter and display these values in alphabetical order on the search results page, you'd replace the default XML with the code that Figure 4 shows. (Note that if you wanted to add the values as an extra filter rather than as a single filter, then you would simply insert the node into the existing XML.)

The Category node defines each filter. You can apply many attributes to the Category node of the XML, to control how the refiners within the filter are displayed. These attributes refer to properties that you can set on a FilterCategory WebControl object (see TechNet for more details). In the code sample in Figure 2, these attributes are the most important:

  • Type. This attribute controls what is used to determine the contents of the filters; in this case, ManagedPropertyFilterGenerator. Developers can add other filter types. Some, such as TaxonomyFilterGenerator for managed metadata, are available out of the box.
  • MetadataThreshold. This attribute controls the minimum number of items that need to be returned in the search results before the refiner will activate.
  • NumberOfFiltersToDisplay. This attribute controls the number of filters to display in this filter category. If more filters are available, then a More link is shown -- so long as the ShowMoreLink property is set to True.
  • SortBy and SortDirection. These attributes control the sort order of the displayed filters. SortBy can be one of these: Frequency, NumericValue, Name, or Custom.
  • MappedProperty. This attribute controls the managed property that is to be used to build the list of filters for this filter category.

An example of such a Refinements Web Part can be seen in Figure 5. Note the single category of refiners with individual values, shown from the Instrument property.

Figure 5: Refinement Web PartLaahs-SPC349-Fig5-lg
Figure 5: The Refinements Web Part 

The Refinements Web Part also supports Extensible Stylesheet Language (XSL) to transform the display. Therefore, you can modify the XSL to modify the default display so that it suits your needs. You can access the XSL via the Data View Properties of the Web Part, as Figure 3 shows. For example, you could replace the textual description of the filter categories with something more exotic, such as an animated image, to liven up your search results page. Figure 6 shows a sample of such an exotic page. (Obviously, it isn't animated!)

Figure 6: Livening up filter-category descriptions
Figure 6: Livening up filter-category descriptions  

Helping You Help Users

SharePoint Server 2010 delivers many search features that can help you navigate the large bodies of information that typically are found in many enterprises. Many new features help you tailor the search experience to meet your business needs. The Refinements Web Part is one example and can help you simply and effectively lead users to the information that they're looking for.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.