Plan to use refiners on a search results page in SharePoint 2013
This is a blog post in the series, “Set up a Search Center in SharePoint 2013”.
In the previous blog post, I showed you how to create a result source, and how to configure the Search Results Web Part to use this new result source. In this post you’ll learn:
- How refiners helped me plan my trip to Japan
- What you should look for when identifying refiners
- About making a managed property refinable
- About refinable managed properties
How refiners helped me plan my trip to Japan
Although the term "refiners" is new to you, there is a high chance you’ve already used them. For example, have you ever bought a book online? Well, then most likely you’ve used refiners to find the right book.
I recently went online to my favorite book store to find a travel guide about Japan. I typed in "Japan," and as you can imagine, pages of search results popped up. Trawling through pages of results is not my idea of fun. Luckily for me though, the site designers had smartly provided a way to narrow down search results. On the left side of the page was a "Categories" list, containing entries such as "Cooking," "Geography," "History," "Travel" and so forth. I clicked "Travel," and in an instant, the search results showed only travel books containing the word "Japan."
However, turns out that there are quite a few travel books out there on Japan, so I needed to trim the results even further. I was looking for a paperback version (yes, I admit that there are still dinosaurs like me around who prefer the look and feel of a book made out of paper…). So, still focusing on the lists on the left side of the page, I spotted a category called "Format" containing terms like "Hardcover," "PDF," "Audio," Digital," and "Paperback. " So I clicked "Paperback" and got what I’d been after: results for travel books about Japan in paperback! Unfortunately, the number of search results was still too large for me, so I continued to use the different lists on the left side of the page until I’d drilled right down to five hopeful candidates; one of which made it over the finish line, and straight into my shopping cart.
Now, here’s the techy part to the tale: when I was clicking "Travel" and "Paperback" I was, in fact, using refiners. In SharePoint terms, a refiner is a managed property that has been made refinable. Refiner values are the values of a refinable managed property. So in the case of my online shopping trip, "Categories" and "Format" were refiners, and "Travel" and "Paperback" were refiner values.
In another blog post, I explain how site columns are “transformed” into managed properties during a crawl. For example, in my Search Center scenario, I have a site column named "Internal Writer.” For each list item, this site column contains the name of the writer of an article (remember, each list item represents an article). To help user quickly narrow search results to articles that have been written by a particular writer, in the same manner that I narrowed search results when shopping for a travel book on Japan, I had to make the managed property that represents the "Internal Writer" site column refinable. There is, of course, a little bit more to it than that, and I will show you all these steps in later blog posts.
What you should look for when you identify refiners
This is a pretty easy one: to identify refiners, you should look for information that users will want to use to narrow down search results.
In my Search Center scenario, I wanted to use the following refiners:
- Internal Writer
- Content Type
- Requested Publish Date
About making a managed property refinable
The first thing you have to do when you configure refiners is to make the managed properties that you want to use, refinable.
Depending on your permission level, you can do this from two places:
|To refiner-enable a managed property from||Requires permission level|
|Central Administration||Search service application administrator|
|Site Collection Administration||Site collection administrator|
There’s a reason why this can be done from two places. If you are working with content (let's say you’re a content manager), you’re not likely to have Search service application administration level rights, that is, you won’t have access to Central Administration. However, you’re very likely to have Site collection administrator permissions.
In the previous blog post blog I described how content managers can easily add content to the search index without having to pester Search service application administrators. So now that everyone’s happy, we don't want to jeopardize this happiness by making content managers dependent on a Search service application administrator to enable refiners.
In this blog post I’ll only describe the procedure as it can be performed by a Site collection administrator (content manager). For information on how Search service application administrators can make a managed property refinable, see Enable automatically created managed properties as refiners in SharePoint Central Administration.
About refinable managed properties
In the previous section I stated “The first thing you have to do when you configure refiners is to make the managed properties that you want to use, refinable." Well, turns out that Site collection administrators (content managers) can't do this because they don't have the required permission level. They do, however, have the permission level to map a crawled property to a refinable managed property.
Confused? I don't blame you, so let me try to explain.
Search service application administrators, who have access to Central Administration, can configure many things directly on a managed property. For example, the screenshot below shows how they can change the property named InternalWriterOWSUSER to be refinable by selecting either Yes – active, or Yes - latent from the Refinable menu.
If we look at the same property from the perspective of a Site collection administrator, who is configuring the property on the site collection level, not only is the property name grayed out, but the Refinable choice menu is locked (it might not be easy to see on the screenshot, but trust me; the field is locked).
Luckily, there are a large number of "empty" managed properties that are enabled as refiners by default. By "empty" I mean that a crawled property is not mapped to it. This means that Site collection administrators can map a crawled property to one of these refiner-enabled managed properties without having to depend on a Search service application administrator.
The table below gives an overview of the managed properties that are enabled as refiners by default.
|Managed property name||Data type for mapping||Display format for refiner values|
|RefinableDate00 - RefinableDate19||Values contain dates||Intervals|
|RefinableDecimal00 - RefinableDecimal09||Values contain numbers with maximum three decimals||Intervals|
|RefinableDouble00 - RefinableDouble09||Values contain numbers with more than three decimals||Intervals|
|RefinableInt00 - RefinableInt49||Values are whole numbers||Intervals|
|RefinableString00 - RefinableString99||Values are strings. This includes values that use the data type Text, Person or Group, Managed Metadata, Choice and Yes/No||List|
In my Search Center scenario, I had already identified the refiners that I wanted to use. For each of these refiners, I defined which refinable managed property I would use:
|Refiner to use||Refinable managed property|
|Requested Publish Date||RefinableDate01|
So now that we have a plan for which refiners to use, the next step is to do the actual refiner configuration.
Next blog post in this series
How to add refiners to your search results page