Tech tutorials Making SharePoint Search Results Even Better For Your Users
By Insight Editor / 8 Mar 2016 , Updated on 21 Aug 2019 / Topics: Microsoft 365
By Insight Editor / 8 Mar 2016 , Updated on 21 Aug 2019 / Topics: Microsoft 365
If you've ever had a cursory glance at any SharePoint 2013 or SharePoint online demo, you likely noticed the nice-looking search results that come out of the box nowadays with their sleeker look and hover previews of the documents themselves. With the latest features, we have access to numerous new components that make our SharePoint search results look better for end users, much easier for power users to change, and especially easier for developers to enhance than the black magic we had to use on previous versions (XML, XSLT was not your friend).
These new capabilities have allowed for search-driven pages to be built where all of the links and information can be pulled directly from the search index instead of just list views.
Just to review, here's a quick rundown of the features we've been able to leverage since the launch:
Search display templates have been decoupled in this version so that we have Control Display Templates to structure the overall layout for how we want to present the search results, while Item Display Templates determine how each item in the result set will be displayed.
As with anything related to SharePoint, there's always more that can be enhanced to make our end users happier, and search results are no exception. In this article, we’ll examine how easy it is to grab document/list metadata that's already being indexed and then update our search page results with that data. My example uses a search results web part on a page that has its settings modified to pull the latest document updates in the site (no keyword search box), but these template updates automatically apply to those setups that have a search box web part too.
I'm going to have the last modified date show on all results, as it should be part of every default template. We'll also add in a managed metadata column that's attached to a specific document library but only build a table of the data if the result comes from that library.
Note: To accomplish these updates, you'll need to be a site collection admin if you want to apply this for all of your sites/sub sites, or at least a site owner to make changes for your site.
This is the hardest part of the exercise as it's up to us (or from user requests) to determine what extra data we want to show, mapping it in the search schema and then figuring out how to display it.
Let's jump in and take our first step to determine what extra data we want to show in our search results. Usually it's a metadata column in our document library that describes where, when or how to use this document in some situation or project. In my case, I was asked to show the template type and service type data in the result item when any of the documents from this library showed up. While these are managed metadata columns, any type of data that’s attached to an item can be used.
Now that we know what data is needed, it's time to put on our detective hat and go look for it in the SharePoint search schema, which is a collection of crawled properties of everything stored in our sites that are then sometimes automatically mapped to managed properties for use (site columns assigned to document libraries and managed metadata columns). To use indexed values in search results, we need to find or create the managed property that’s mapped to a crawled item. When you go into site settings, under the Search header, click on the Schema link.
The properties interface will default to showing all of the managed properties SharePoint creates out of the box. In the search box, we'll type the beginning of one of the columns from the document library above, remembering that less text is more results and that SharePoint doesn’t allow spaces in column names and will fix them for you (it replaces them with "_x0020_").
In the image below, you can see our query returned the managed property we need called owstaxIdTemplateType, which is set for a mapped crawled property named ows_taxId_TemplateType. This is where the detective work comes in if the target column wasn't given a name that’s specific enough. In this case, I know the column/crawled property is a managed metadata column (e.g., ..._taxId_...) and that the column was created with no spaces.
Now that we have our managed property, we need to look at the different attributes applied, such as type, query, search and refine, as well as others. What we're looking for is to ensure our property has the word "retrieve" in the retrieve column. Otherwise, we won't be able to show its values in our updated results. If it doesn't, we'll have to create our own managed property, but that's a topic for another article.
Now that we have our column in the index, our next step is to copy an existing Item Template and change it from there (no sense in re-inventing the wheel). I use SharePoint Designer 2013 and the Site Settings menus for this, but you can use standard File Explorer.
To start our template copy, we first need to see what template SharePoint is currently using. Back in Site Settings under the Search heading, click on the Result Types link.
This will load the menu showing all of the Display Templates by type, assigned to results SharePoint shows for us. We'll be creating versions for all of the document types in our library, but I'll just start with Excel for now. Also, on the far right under Result Actions, notice it says it uses Excel Item, which is what we'll need later to make a template copy. Hover over the item and select the Copy function in the drop-down.
Note: It's always best practice to make a copy of SharePoint objects and not update the original directly. You never know if an update from Microsoft will overwrite your changes.
Once the Edit Result Type page loads, in the name box, append some text to explain how it's different (e.g., site it's attached to, group, application, etc.) and note that the sources it's hooked to and what type of content it matches are automatically selected. Under Actions is a "What should these results look like?" drop-down hooked to Excel Item already. We'll update this with our new template later, but for now, we have our entry for displaying results differently. Click the Save button to create the entry, which will post back to the Manage Result Types page showing our new entry.
With our new result type created, we need to create a copy of the core Excel Item template to update and then attach. We'll open SharePoint Designer to our site URL and then click on the All Files object in the left pane to show everything. Since the templates are kind of hidden by SharePoint, click on the _catalogs folder, then the masterpage folder, the Display Templates folder and finally the Search folder. This is the physical location of all of the Control and Item Display Templates.
Since SharePoint likes to keep things interesting, the title of our target is Excel Item, but the file name pattern is reversed as Item_Excel.html. The other interesting piece you'll notice is .html AND .js versions of these files. This new decoupled model takes our HTML template and compiles it down to JavaScript for us as we save and then uses that JavaScript file when rendering the results.
So to make our version to work with, right-click on only the .html version of these files and select the Copy function, then right-click anywhere in the library and choose the Paste function. Once Designer finishes creating the copy in the library at the bottom, rename it by removing "copy(1)" and appending a distinctive name, as well as updating the title column to the right. (Otherwise, you'll see the Excel Item template twice when we go back into site settings and won't know which to pick).
Now we need to right-click on only our new .html file and select Check-Out, and then Edit File in Advanced Mode to open it for editing.
With the file open in edit mode, locate the XML node labeled mso:ManagedPropertyMapping near the top. This is where we add in our managed property we want the template to show. You'll see the syntax is pretty easy in that you put property name, colon and a descriptive name for it (,'xxx':'xxx') at the end of the node with both pieces surrounded by single quotes. I always just use the property name in the descriptor to make life easier. In our case here, I'm adding in the value ,'owstaxIdServiceType':'owstaxIdServiceType' just before the closing tag of the XML node.
After you update the managed property node, scroll down to just under the HTML that says
Here you'll see what looks like JavaScript comment tagging but with extra pieces: _# and #_. This is part of the new compiler marking in SharePoint that tells it what to rebuild down into the .js file.
In the upper highlighted section, I add in my JavaScript where I set a few variables to use those new managed properties we added above, then evaluate if they're empty to determine whether to create my display table (checking if this item is in my library where that metadata is set). Finally, near the bottom of the file under the default HTML, I add in two new HTML elements for the dynamic table and the last modified date I want to show all the time. Make sure you save and close the file when done.
Note: To show the JavaScript in the HTML, we have to surround our variables with the compiler notation mentioned above: _#variable-name-here#_.
Our next step is to go back to the browser in site settings and, under the Web Designer Galleries heading, click on the Master Pages and Page Layouts link. Here we'll check in and publish a major version of the new template.
This will drop us into the library where all the templates and layouts are stored. Double-click on the Display Templates folder, then the Search folder. This is where all of the Control and Item Display Templates live within the site collection. After paging to the second set of results, we'll see our new .html Item Template showing right around the existing one we copied from. Hover over just the .html file and, in the hover drop-down, select the Check-In function.
Once the Check-In modal loads, select the 1.0 Major version (publish) choice. This will make this version visible to everyone else once we've updated our result type. In the template library, we won't see the file as checked out anymore.
The last admin step is that we need to go back to site settings and, under the Search heading, click on the Result Types link. Hover over our new result type until the drop-down menu appears and then select the Edit function.
Once the page loads, we'll see all the settings from before when we copied the existing one. But now that we have our Item Display Template created, we're going to update search results to use it. Scroll down until you see the section Actions > What Should These Results Look Like? and select the drop-down. There we should see our new Excel Item - BP listed alphabetically right around the original (that's why we updated the title to find it). Select this new item, then click the Save button.
Note: Under the drop-down you'll see a disclaimer about the latest properties your template will update if you make changes. This applies to any new managed properties you add into your template. See the next paragraph on this.
The page will now post back to the manage result types, where you can review and verify that Excel results will now use our custom Item Display Template. One thing to note from the image below is that every time you update your template and publish a new major version, you have to come back here to do a properties sync (you won't see it initially following my instructions). This forces SharePoint to push your latest template into the cache for users to see. Otherwise, you'll be beating your head on the keyboard trying to figure out why your new metadata isn't showing up.
Now that we've updated all Excel results to use our new template, navigate to the page you're showing search results on and verify your work. We should see that every Excel result has at least the last modified date showing as we don't have any conditional logic around it being there. But if the result has that metadata attached to it, our new table will be built out with that metadata for our users. You can sit back and bask in your rock star-ness for making a small change with big impact.
Although this may not seem like a big thing for all of the steps above, it can help your users find information they didn't know they might be looking for. And, if you've set this value up as a refiner, they can find more excellent resources like this by filtering or searching by it. The big return here is cutting down the time users spend searching for content and instead helping them find exactly what they need right away.