The Problem with Contextual Search Scopes
Contextual Search Scopes are a widely used feature in SharePoint deployments and while some question their value many users rely on them. It also turns out that in certain situations contextual scopes pose a real design challenge. But before we get into that let’s explain what contextual search scopes are for the uninitiated.
What are Contextual Search Scopes?
A contextual search scope is a scope that SharePoint creates for us automatically and provides the capability to scope searches to the current site or the current list. Most SharePoint users will recognize the following screenshots depicting search boxes with various contextual scope configurations.
No Scopes Dropdown – default to current context
Show Scopes Dropdown – default to current context (list and site)
“This List” scope
Site collection administrators enable or disable contextual scopes at the site collection level as well as choose to display them as options in a scopes dropdown or default to the current context.
Here is the page where a site collection administrator would configure the settings.
How Contextual Search Scopes Work Out of the Box
Did you notice the last field on the Search Settings page?
This field determines which results page is used when a Contextual Search is selected. The default is /_layouts/OSSSearchResults.aspx.
So if you have a site that utilizes regular, static search scopes *and* contextual Search Scopes, those queries made using contextual scopes will utilize the OSSSearchResults.aspx results page while non-contextual scopes could be directed somewhere else and here is where the rub starts to happen.
SharePoint 2010, especially when using FAST Search Server 2010 for SharePoint (FS4SP), truly now delivers world-class enterprise search. Notice I didn’t say “SharePoint Search” but “Enterprise Search”. Part of the promise of enterprise search is that users will have a singular location where they can go to search for everything in their organizations. This typically warrants a dedicated Search Center. I won’t go into details here, but a Search Center is a site template that contains pages, web parts and features that allow administrators to build search sites. Here is a link to more about site templates.
To Explain the issue, let me walk you through a very typical scenario.
An organization develops a search strategy that includes a dedicated SharePoint application just for search. Let’s call it
The search team brands the search site, customizes the search results XSLT and exposes lots of properties as refiners and sort-by options.
Now, their SharePoint Intranet is a separate application with lots of different site collections like the following:
The SharePoint administrator redirects search queries from each of these site collections to
. Users type their queries in from the Intranet and are they are redirected to
. The users are happy because SharePoint and FS4SP deliver great results and a rich experience. At this point if the user performs a search and chooses “This Site” or “This List” as their search scope their search results are displayed on the OSSSearch page. This creates sort of an uneven experience. Users perform a Search using the “All Sites” scope and they get this great search center with custom look and feel, refiners, etc. And when they do a search using “This Site” it looks totally bland.
One option would be to brand the OSSSearch page to look like the results page in our search center. We could do that (or better yet, make a copy and edit that so we’re not being destructive). However, that would mean that every time we changed the branding, added a refiner, added a sort-by property or anything else on the results page we would also have to make the same change on the OSSSearch page. Now imagine we are a large organization with 50 to 100 or more search consumers, each with their own set of requirements. It’s easy to see how this could become completely unmanageable.
Fortunately SharePoint allows us to forward contextually scoped queries to our
site as well. Problem solved, right? Wrong. When a user performs a contextual search the query is redirected and the scope is honored in our results but there are a handful of problems ranging from just kluge to unacceptable:
- There is nothing on the page to indicate to the user that there is a contextual scope being applied. The only way they could tell is if they looked in the query string.
- If they perform a subsequent search from the results page using a different scope there is no way for them to get back to the contextual scope (it disappears) other than using the browser’s back button.
- There is no way for the user to get back to the page that they executed the search from other than using the browser’s back button.
- They lose the navigation of their original site since they are now in a different site collection or application
So this is “the problem with contextual search” (as the antagonistic title of this article describes it). In environments with a centralized search center, a highly customized search center or search is being provided as a service this is something that you may need to address and I personally have never seen good answer for it.
I recently faced this challenge at a client and, while there are obviously different approaches with various pros/cons, this is what we decided on.
- All non-contextual queries redirected to one centralized search center.
- Each search consumer (business group) has a dedicated results page in that search center.
- Consumers have two options for their contextual searches
- If it is important to the consumer that they have a consistent search experience (same look/feel/UX for all queries) then contextual searches will be sent to the search center
- If it is more important that they maintain their navigation on the search results page then they will keep their OTB OSSSearch page for their contextual searches
Now, if they go with option “1″ we have some problems to solve (as stated above). Here is how we solved them. I’ll warn you up front that I am able to post the code for this solution. Instead I will explain the concepts and most developers will realize this is not an incredibly complex task.
Problem: There is nothing on the page that indicates to the user that there is a contextual scope being applied. The only way they could see it is if they looked in the query string.
Solution: We extended the Search Box Web part (meaning we wrote a custom search box web part based on the OTB SharePoint search box web part) to grab the contextual search from the query string and add it to the dropdown box where users can select search scopes.
Problem: If they perform a subsequent search using a different scope, there is no way for them to get back to the contextual scope (it disappears) without using the browser’s back button.
Problem: There is no way for the user to get back to the page that they executed the search from (except for the browser’s back button).
Solution: Surprisingly, this was the biggest challenge we faced.
Then I had the idea to instead just keep track of the number of page loads (for instance if a user was paging through a results set) in a cookie and set the onclick of the site icon to history.go(n), where “n” is the number of page loads to go back. This seemed to work fine, and I thought it was quite clever (if I do say so myself), however if the user clicked on the back button of the browser it would cause problems and it ultimately was not a resolvable problem.
We made this back button functionality part of the web part however there is no technical reason to couple this with the search box.
Problem: They lose the navigation of their original site since they are now in a different site collection or application
Solution: This we just solved by giving them the option to use the page in the layouts folder.
Again, there are different ways to skin this cat, but this solution is working nicely and has been a low-effort/high-reward solution for us.
I should also point out that this is a very relevant solution for those organizations considering a Search First migration (I’ll leave it at that as Search First could be a subject for a whole seperate blog series).
I hope this explanation/solution will help you navigate this potential headache.