We have come a long way during this journey to craft a functional and useful targeted search solution that began with the deconstruction of a previous 2007 version of the solution to the reconstruction of that same solution in 2010. Surprisingly, there was much more involved in the recreation of this solution as many of the out of the box configurations were already set with the Collaboration Portal in 2007. However, after working through the configuration changes and details, we have finally arrived at the experience for the user, where we can now complete our solution here in SharePoint 2010.
Implementing a Search Site
There are many moving parts involved with SharePoint, often a configuration or service set up in the back-end while an interface displays and allows users to interact with that service in the front-end, and Enterprise Search is no different. While the setup of the Search Service Application and Content Sources provided us the back-end we need to surface our targeted search results, we required the additional Site Collection configurations to ensure that search queries and search results would be input and returned through an application used by SharePoint. Furthermore, to focus the search query, we needed a Search Scope created and configured to act as the conduit for the queries, as well as establish a landing place for our search results from that targeted query. And although we had already constructed the logical architecture to support an Enterprise Search Center, the site is yet too generic to provide us a funneled, specific view. Thus we need one final element in the Search Center Site itself to both submit and display the search properly, which resides in the Web Parts, Lists and Libraries in the Search Center itself.
The Enterprise Search Center, regardless of customizability, requires that the Publishing Infrastructure be activated as the Enterprise Search Center itself is a Publishing Site by construction. The Enterprise Search Center uses two main web pages, a search page and a results page, to accept and return search queries for the Web Front-End to handle, which are both stored in a Pages Library in the Site. However, the benefit of the Enterprise Search Center is a tabular control that displays multiple pages through an identical interface and thus allows Web Pages to be connected to each Tab that is displayed in the Enterprise Search Center. These tabs are controlled by two lists, one for Search Pages, one for Search Results. This blends the query and results experiences into an identical form yet allowing for queries and result sets to be configured and even customized differently, yet still seem as if the very page accepting the query is the one that is rendered with the search results. Furthermore, changes can also go through review and approval processes, just like any other Publishing Site.
The Enterprise Search Center also includes additional Web Pages, including an Advanced Search page as well as a query and results page for People Search. Essentially, multiple Web Pages aligned with a List Tab can be presented on the landing page of the Enterprise Search Center for any sort of Enterprise Search customization as needed. This is further customized by various Search Web Parts that are included in the Enterprise Search Center’s Site Definition, that controls how search queries are accepted and results sets returned. And, with the Minimal.master page it uses, it keeps the search experience as simple and clean as possible, but also allowing for customization through Web Parts and other means to make the search more useful. Only an analysis of the URL would betray the difference in pages, although even the URL with additional parameters also helps in focusing the result sets in the page, such as when describing the Search Scope. To make a truly interesting application, implementing a Search Center also requires some degree of customization to enhance the user experience for Enterprise Search.
The process is deceptively simple: a standard search page presents a Web Part that displays a Search Box, which accepts the query and sends it through to the Query Processor for processing. The Site Collection is configured to return results in either an out of box default system page, or in a page customized by the Search Administrator for additional functionality or simply better formatting for the view of the results. When the Query Processor completes its task and returns the results to be rendered, it uses the Site Collection Search Results configuration to populate Search Results Web Parts, and the Web Front-End renders the results in the browser. However, this simple process also prevents our targeted search solution from working for two reasons. First, it prevents the user from submitting a search to only be queried against specific content, and second it prevents a targeted results set from rendering in an identical page and thus creating a possibly confusion experience.
To solve this issue and bring the entire configuration full circle, we need to perform a few additional configurations in the Enterprise Search Center:
1) Create additional Web Pages for both a targeted query and the associated search results
These web pages are created to allow a search query to be run against our targeted content and return results in a dedicated page that seems to be identical to the page where the query was submitted.
Note that the page names must be different since they are stored in the same Pages Library.
2) Create Tabs to represent the Search and Results pages used in the targeted query
To coincide with the previously created Web Pages, for the Enterprise Search Center to display either page correctly and without confusion, a Tab connecting the Web Pages for both the search and results phase of the search also needs to be created.
Since the Page names need to be different, yet the pages need to show with the same Tab, a Tab for each page will also connect the correct Page with the correct Tab view when rendered in the browser. Additionally, a Tooltip can be input to provide some hover text when the mouse pointer is positioned over it.
3) Configure the Search Box Web Part to use the correct Search Scope
The main function needed to leverage the Search Scope we created that focuses the query only on the Document Center site containing the targeted content is to configure the Search Box Web Part to use the specific Display Group. The default Search Scope, which will be the only Search Scope in the Document Center Display Group, will be used by default.
The search Web Page is used for this configuration, to focus Display Group on our custom Search Scope. By using the Dropdown Mode of “Show, do not include contextual scopes” allows our custom Search Scope to be leveraged instead, and prevents the contextual Search Scopes from being used. This configuration will allow a user to click the Store Only tab if they only wish to search within the Document Center Site and thus limit their search results to only content from that site. Note that this configuration is for the Enterprise Search Center specifically.
4) Configure the Search Box Web Part to use the custom Display Group
In the Miscellaneous section of the Search Box Web Part, we can configure the Document Center Display Group created when creating our custom Search Scope. This was necessary to configure which Display Group would be used in the Scopes Dropdown box. However, because we eliminated other contextual Search Scopes from being used, by setting our custom Display Group, this limits what the user can change or configure. This was configured to focus the search using the Tab separation to make the searches more readily intuitive.
Additionally, we want to be sure that the search results return and are rendered in our custom Web Page, and thus the Target search results page URL is also configured to use the local Web Page created earlier. This could also have been created in a different URL, but as this Enterprise Search Center has been configured for the Site Collection as a whole, using the local Pages Library was adequate for this scenario.
5) Test the targeted Search Scope and Web Page
By running a specified query against known content, we can now determine if the application is working. A simple keyword search for content should reveal search results in only the Document Center Site.
Note that the results sets are very limited, and only show content from the Document Center Site as desired. In contrast, a standard All Sites search query through the Enterprise Search Center yielded not only different results by also more and with different relevance.
Additionally, although the majority of the results from the general All Sites Search Scope search yielded results from our File Share Content Source, a quick refiner in the Refinement Panel by Sites shows that our News Site also yielded results.
A successful test bears out that despite a possible skewing of results and relevance due to various additional sources, the targeted solution remained focused and much more relevant.
Furthermore, this configuration for the Enterprise Search Center became necessary as the default Search Scope options, which would include our custom Search Scope, would still be needed to target content on the Enterprise Search Center Site. However, because we included the Search Scope in the All Sites Scopes as well, this targeted search can be performed from anywhere in the Site Collection, again because the Search Settings configured the use of the custom Search Scopes and their result sets.
Through some front-end content configuration involving Web Pages, Tabs Lists, and Web Parts, a successful targeted solution could be applied through the Portal Site Collection and thus properly emulates the 2007 solution despite all the changes between versions. And here, even the proper configuration of Web Parts and Site Collections Settings were necessary to work through to reach our solution goal.
Overall, the solution was re-creatable despite all the changes and shifts in configurations and options, but works just as well as the original, while taking advantage of even some newer features to make the Enterprise Search Experience that much more useful. At this point, although one last phase of this series was to examine the improvements that SharePoint 2010 could have on this 2007 solution, the length of this process brings us to a conclusion that our comparison and improvement analysis will need to be held in a different post.
This brings our targeted search solution series to a close. For now, our next post will return us to our never-ending quest to Solve for Y.