This post in the series was sitting in my “outbox” for a long time. Sorry to people like Nigel (@Nigel_Price) who probably gave up on me!
In a company with 100 employees, clicking on once of the letters are the top of the page will probably narrow things down well enough that you’ll see everyone with that letter at the start of their last name on one page. If you have many more employees, you may end up with too many people to see very easily. And since we’re limited to 50 results in the Search Results Web Part, you may need to page and/or scroll a lot, depending on what properties you’ve decided to show for each person (one line vs. two lines or more, for example).
There are a couple of out of the box capabilities we can use to sort or filter our results a bit more. Because we’re using search to drive the directory, we have all of the native search capabilities that SharePoint gives us. Let’s take a look at adding some sorting and improving the refiners.
Sorting
In the Web Part Properties for the Search Results Web Part, there is a checkbox labelled “Show sort dropdown”. It’s in the Settings section (which is full of other options as well).
By checking the box and adding some of our own JSON into the field below it, we can control what sort options are available. The JSON should be an array of sort options taking this form:
{
"name": "Last name (A-Z)",
"sorts": [{
"p": "RefinableString00",
"d": 0
}]
}
The values break down like this:
- name – The text value you’ll see in the dropdown
- sorts – The parameters for the sort that apply when the option is selected
- p – The managed property to sort on
- d – [0 | 1] If 0, the assort is ascending, if 1 it is descending.
Note that for the Last name sort above, I’m using the RefinableString00 managed property I set up in Part 4. If we tried to do this with the LastName managed property we’d get an error because that property is not Sortable.
Here’s a pretty basic set of sorting options that should at least get you started. I’m giving you four pretty basic sort options:
- First name (A-Z)
- First name (Z-A)
- Last name (A-Z)
- Last name (Z-A)
[{"name":"First name (A-Z)","sorts":[{"p":"FirstName","d":0}]},{"name":"First name (Z-A)","sorts":[{"p":"FirstName","d":1}]},{"name":"Last name (A-Z)","sorts":[{"p":"RefinableString00","d":0}]},{"name":"Last name (Z-A)","sorts":[{"p":"RefinableString00","d":1}]}]
You should be able to take this and enhance it for your own needs.
Refiners
Next we probably want to adjust the refiners a bit. Out of the box, the Refiners Web Part will display properties that look to a machine like useful ones, but they may not be the most useful in your organization. You may want to show refiners that are part of the search results already or you may want to show refiners that aren’t visible in the results.
Changing which refiners you see and in what order works like this:
- Edit the page
- Put the Refinement Web Part into Edit Mode
- Click on Choose refiners
- Change the settings
- Save it
The key action here is to add or subtract from the Selected refiners in the Choose refiners dialog. For each refiner, you can change the settings on the bottom of the page. Note that refiners use Display Templates as well. I’m not going to go into building Refinement Display Templates, but you can see them in _catalog/_masterpage/Display Templates/Filters.
In my case, I’ve got refiners for Department, JobTitle, PeopleKeywords, and BaseOfficeLocation. You will probably want some others which work for you.
You should see the impact of these changes immediately upon saving the page. Assuming that the properties you have selected have been indexed, that is.
What Next?
There are a number of different directions we could go from here. We could build a similar page to show a Site Directory [Nigel]. We could enhance the display of each person to show additional information about them or metrics about their recent activities. We could add as second alphabetical listing row below the first so that if you selected the letter B, you could the choose the next letter (only lit up if there are people lurking there). As with most functionality like this, coming up with the innovative ideas can be even harder than good execution on them. In this case, some of the limitations in Office 365 make it even more difficult that it should be.
I’d love to see:
- Ability to trigger a full crawl of the User Profiles when we change the schema. It wouldn’t have to happen right away, but it would at least remove the need for Powershell.
- Allow us to build a more intelligible set of “RefinableType” properties so that we can manage them better. If we create more than a handful of these special mappings – as most organizations will do over time – then management is going to be cumbersome at best. We can’t even search by the Alias names.
Then basic process here should work for many different use cases. As you’ve probably gleaned from this series, building good metadata and taxonomy isn’t just an academic exercise. The whole point is to make content easier to find, and a People Directory is no different: it’s a customized page that allows us to perform a certain used case in an optimal way. What “optimal” means is going to vary based upon the characteristics of your organization.
- How big is it?
- Why would people be looking for each other (beyond the simple phone list idea)?
- What information is important for people to see vs. that which must be secured?
- etc.
I hope you’ve found the series useful. If you’d like to know more or have other ideas, I’d love to hear about them in the comments below.
References
by
Marc D Anderson via Marc D Anderson's Blog
