SharePoint People Search – Lessons learned. Part 1: Covering the basics

For the last couple of days I’ve been working on a facebook solution based on SharePoint People Search. And while you might think that it’s nothing more than configuring and developing for SharePoint, there are quite a few search-specific things I’ve learned in those few days.

First things first

The first thing you are very likely to do while working with a solution based on SharePoint Search is to configure the SharePoint Search Service so that it crawls your content and returns some results. There is a great article on Microsoft TechNet which will guide you through the process of configuring the SharePoint Search Service.

During the development of my custom solution I have experienced some odd difficulties. While crawling the content, the SharePoint Search Service kept refusing to crawl the content and was returning the 401 Unauthorized error. Eventually I have found out that this error was caused by the loopback check. After applying the fix from the Microsoft Help and Support page, the Search Service started crawling the content as expected.

Display all users by default

In a facebook-like solution what you probably want to do is to display by default all users to provide some browsing (useful for example for new employees or if you don’t know someone’s name). SharePoint People Search does the opposite unfortunately. It doesn’t display anything unless you enter a search query.

Such behavior is not really user-friendly and not something you would like to have in your facebook solution. Luckily there is a workaround to this issue (provided by Ton Stegeman and Ingeborg Struijk):

• Edit the properties of the Poeple Search Core Results Web Part
• Open the Fixed Keyword Query section
• In the Fixed Keyword Query field enter: ContentClass:SPSPeople
  
• Open the Results Query Options section
• Change the value of Cross-Web query ID to Query 2
  

This will make the people results Web Part display some users by default:

There is one more thing you need to do if you want the paging web parts to work:

• Edit the properties of the Search Paging Web Part
• Open the Miscellaneous section
• Change the value of Cross-Web Part query ID to Query 2
  

After applying the changes the paging controls should be displayed properly:

Sorting people

Most facebook solutions present results sorted alphabetically by last name by default. Is it surprising to hear that SharePoint works differently?

Looking at the screenshot above you might’ve noticed that there are two ways of sorting the results. You can sort people either by Social Distance or by Relevance. While these two are useful while actually searching for people they are completely useless on the default view where you would expect the good old sorting by last name.

That’s not the end of bad news: not only is the sorting by last name not available on the standard People Search screen, but it is impossible to do. Sorting by either Social Distance or Relevance are the only two possible choices, hard coded in the People Search Core Results Web Part and there is nothing you can do about it. The People Search Core Results Web Part is sealed so if you want to provide different experience than the one I’ve just described you have to create your own Web Part. That’s the approach I chose.

Paging the results

SharePoint Search is very fast and is, in most common scenarios, capable of returning the search results in under a second. To keep it that fast some serious architectural choices have been made. One of them is estimated paging. Have you ever compared the search results information on different pages? Let’s have a look at some results of a query I ran the other day:

The first page:

…10th page:

…and finally the last page:

Noticed how the total number of hits changes? To keep the performance high, SharePoint estimates the number of hits. The closer to the end you get, the more precise the number gets.

Estimating the number of hits has some serious consequences for presenting paging controls. Because it’s a rough estimate that you get from SharePoint, you cannot present all pages at once. You simply don’t know how many pages there are. And that’s exactly how SharePoint Search Paging Web Part works! Take a look at the second screenshot (10th result page): what you see in the paging control is the current page, 5 previous pages and 5 next pages – but not all of them.

There is a very good article on the Microsoft Enterprise Search Blog which can help you understand how the total number of hits and paging in SharePoint Search exactly work.

Paging – level 2

SharePoint uses by default the best practice for paging information: it uses a query string parameter so that the Web Part responsible for displaying results can determine itself which page it is supposed to display. Using query string parameters is considered the best practices because it allows the visitors to persist the state of the page. When they send such link to someone else they are able to navigate directly to that page and see the same information.

One problem with using query string parameters is that they can be modified by end-users. In our situation the visitor can choose which search results page he wants to see by modifying the value of the query string parameter. As a result it is possible that the visitor enters an invalid page number. By default the Search Core Results Web Part displays the 'No results matching your search were found' message if an invalid page has been requested. Quite confusing isn’t it? While developing a custom Web Part you should check if the provided page number is valid and redirect to the first results page if it's not.

Summary

In this article we have looked at different aspects of SharePoint People Search configuration when used for a facebook-like solution. We have focused on different requirements and explored different shortcoming of the standard People Search Web Parts. In the next part of the article we will have a closer look at programmatically running search queries against the SharePoint Search Service and presenting the results to the end users.

Bookmark this post

Possibly related posts

• DIWUG meeting upcoming Thursday (May 7)
• Generating tag cloud using the Content Query Web Part
• Generating short description using the Content Query Web Part
• Debugging Content Query Web Part
• SharePoint People Search – Lessons learned. Part 2: Programmatically running search queries