SharePoint 2013 and "search scopes"

While SharePoint 2013 introduced some undeniably handy features in the content discovery department, some of the old functionality has changed so much that you'll have to forget many of the design tricks that worked in 2007 and 2010.  One of such pain points is deprecating search scopes in SharePoint 2013.

The requirement

Let's start with a trivial situation. You have a requirement that states:

"A user should be able to perform different types of search from any page/sub site on the portal by selecting a type of search and specifying keyword(s)".

This would be considered an out-of-box functionality in 2007/2010: you just enable search scopes dropdown (considering the search box control is already in the master page), and define scopes. Piece of cake! Well, not so much in 2013.

 

The problem

The thing is - there's no search scopes in SharePoint 2013. OK, to be exact - there's no user-definable search scopes, as we still have a couple of built-in locked-down scopes left for some backward compatibility, but that does not help us at all. What do we have? Per Microsoft:

The search scope functionality was replaced by a more powerful functionality for result sources.

Result Sources! When you take a closer look at them, you'll find out they are indeed much more powerful than search scopes. Some very complex query scenarios are now fairly easy to configure. Cool. Now let's see why the result sources do not exactly work for our initial requirement.

1. Unlike with the search scopes, you cannot specify a result source as a query string parameter for your search results page. A result source must be pre-assigned as a parameter to whatever search results web part you are using. That generally means you have to create a results page per result source you're planning on using. That's right, if you have some customizations on your results page, you'll have to duplicate those customizations on every single results page. Not to mention admin overhead to keep those pages in synch content-wise. OK, that's somewhat inconvenient, but doable.
2. Unlike the search scopes, the result sources do not appear in the search dropdown. At least not directly.

So, what does appear in the search dropdown? Is there such a thing at all? Yes, there is, though it's visually integrated with the search box itself (a rather good UX decision, I'd say):

If those are not scopes, and not result sources - what are they? Technically speaking, those are links to the search results pages (though they can be anything, even the external links). How do you control them? Through this nice and handy Search Navigation management UI:

"So, this is it" - you would say - "we configure result sources, create result pages for them and add links to the Search Navigation". Yes, that would've worked if we did not have a requirement of having those dropdown items on EVERY sub site. The thing is - Search Navigation is site-scoped, not site collection or else. Don’t' get too excited about that "Use the same results page settings as my parent" checkbox - it will only get the parent's result page settings, but not the search navigation items. So, if you select this checkbox, and specify no search navigation items, you will get the default Everything/People/Conversations/This Site regardless of what you've got in the parent. Of course, you can duplicate search navigation settings in all sub sites, but if you have a dozen of them, and a dozen of sub sites, plus frequently created new sub sites - your site administrators will hate you passionately.
 

Microsoft solution

What does Microsoft say about it? Didn't they think of it? Of course they did. And they have a solution. At least what they consider being one:

1. Deploy a Search Center site;
2. Configure search navigation in Search Center;
3. Specify search center in site collection/search service web app, and have sub sites inherit the search settings.

Neat, isn't it? Well, let's see what we're going to get here:

• Those of you who ever had to customize Search Center already do not like this solution. Yes, that "special" master page that you will have to create and maintain separately. Yes, that lack of global navigation support. You know the drill.
• The user experience is terrible. Let's say you're on some portal page, searching for an office.
• What you want:
• In the global search box type in name, and select "Offices";
• Click "Search";
• Get the results in a format specific to "Offices" search.
• What you get:
• In the global search box type in name;
• Click "Search";
• Get the results from a default result source (that might not even contain your type of search results), in some generic format (that might not even be suitable for displaying your type of results);
• Select the "Offices" search type;
• Get the results in a format specific to "Offices" search.

I can't think of any UX professional that would approve such implementation. This is where you would probably start thinking of implementing your own custom Search Box control, that looks into some central place for those "scopes". Well, don't do that just yet.
 

Our solution

Why not just write a simple timer job that synchronizes search navigation of every sub-site with, say a root of site collection? For every sub site you just synchronize the following two properties:

Search settings:

SPWeb.AllProperties["SRCH_SB_SET_WEB"]

- it's just a string that most likely looks something like

{\"Inherit\":false,\"ResultsPageAddress\":null,\"ShowNavigation\":true} 

Search navigation:

SPWeb.Navigation.SearchNav 

- this is an SPNavigationNodeCollection object that cannot be assigned, so you'll have to cycle through it adding each node:

foreach (SPNavigationNode node in nodes)
{
    if (web.Navigation.GetNodeByUrl(node.Url) == null)
    {
        web.Navigation.AddToSearchNav(node);
    }
}

Don't forget to delete the removed search navigation nodes as well, and call the SPWeb.Update() a the end!

To summarize, in order to fully comply with our requirement, we need to:

1. Create result sources;
2. Create a page with configured search results web part per result source;
3. Create a timer job that synchronizes sub site search settings with those of site collection root ones;
4. Create search navigation entries in the site collection root, and see them appear globally throughout the site collection.

Hope, this helps you find some peace with UX designers and SharePoint administrators...