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 identify refiners, and told you about refinable managed properties. In this post you’ll learn:
How to map a crawled property to a refinable managed propertyIn my Search Center scenario, I knew that I wanted to use the following refinable managed properties:
The procedure to map a crawled property to a refinable managed property is the same for all refiners. In the procedure below, I’ll show you how you can do this. As an example, I’ll show you how I mapped the crawled property that represents Internal Writer to the RefinableString01 refinable managed property.
Two crawled properties were found: ows_q_USER_Internal_Writer and ows_Internal_Writer.
If you now look like a big question mark, trust me, I understand your confusion. This part is quite tricky. There are actually two crawled properties (very strange since we only have one Internal Writer site column), so which one should you choose to map to the refinable managed property?
OK, let's take a closer look at what’s going on. The difference between the two crawled properties is the prefix. One has a ows_q_USER_ prefix, and the other ows_. Now here’s the important part: When mapping a crawled property to a refinable managed property, you should select the crawled property with the ows_ prefix!In another blog post I talk about the naming convention for crawled and managed properties. For more information, see From site column to managed property – What’s up with that?
On the Edit Managed Property page, notice that the crawled property has been added to the Mappings to crawled property field.
It's important to understand that the alias that you enter here is not the refiner name that will be shown on your search results page. This alias is meant to make your life a bit easier when you’re configuring refiners in the Refinement Web Part (I’ll show you how to do this in the procedure below). Remember, you can't change the name of the refinable managed property, so when you do the configuration, you’ll have to deal with quite a few refinable managed properties that have similar names; RefinableString01, RefinableString02 etc. So the alias is a good reminder of which value you mapped to the property.
I repeated the steps from the procedure above for the remaining four refiners. The screenshots below show my final result.
How to initiate a reindexing of a list or libraryWhen you’ve mapped all the rfinable managed properties that you want to use, you have to do a reindexing of your list or library. I showed you how to do this in a previous blog.
How to configure the Refinement Web Part to use custom refinersBy default, the Refinement Web Part is included on the search results page. In the previous blog post I showed you how to configure the Search Results Web Part to use a new result source. The two refiners Author and Modified date were also displayed.
To display custom refiners, here’s what you should do:
This moves the RefinableString01 property over to the Selected refiners section. When a refiner is moved over to the Selected refiners section, additional configuration options are shown (I'll go through them in steps 10 and 11).
I clicked Preview refiners again, and verified that the ContentType refiner (RefinableString04) was displayed first, and that it had checkboxes that would enable users to select multiple refiner values.
I repeated this step for the refiners RefinableString01, RefinableString02 and RefinableString03.
But I wasn’t quite satisfied with the way my RefinableDate01 refiner was displayed. Remember, this refiner represents Requested publish date. By default, the refiner values are shown in a list, which makes it difficult for users to see the date range.
To display the refiner values in a more user friendly way, in the Refinement configuration dialog box, from the Display template menu, I selected Slider with bar graph. In the Dates section, I selected Last day, week, month, six months and year.
When I now previewed my refiners, the values for the Requested Publish Date refiner (RefinableDate01) were nicely displayed as a graph.
But there was one more thing that I had to improve: the refiner display names. RefinableString01, RefinableString02 etc. does not make much sense to users.
Repeat this step for all your refinable managed properties.
However, there was one small detail that would make the refiners even better. Right now users couldn’t see any numeric details for the refiner values. For example, I could see that I (Bella Engen) was a writer of articles that had to do with search configuration, but I couldn’t see how many articles.
To see this information, I need to add counts to the refiner values.
How to add counts to refiner valuesTo add counts to refiner values, you’ll have to edit a display template. When you work with display templates, you'll make life a lot easier for yourself if you map your network drive. By doing this, you’ll be able to work with display templates from Windows Explorer. I describe how you can map your network drive in this blog article.
To verify that refiner counts are displayed, enter a query in your search center.
In my scenario, I could now see that I (Bella Engen) was the writer of 5 articles that had something to do with search configuration. Nice!
Next blog article in this seriesHow to add a custom search vertical to your search results page