Search Center and Search Pages
When most users think about searching, they think about the search box where they type in their queries, but that is just one small piece of the search functionality. The Search Center is a template provided with MOSS 2007 that provides an OOB search page that can be easily customized to meet your organization’s needs. The Search Center, like other site templates, is made up of several default pages and Web Parts. After it has been created, you can easily tweak the template to meet your specific requirements.
Search Center Templates
MOSS provides two different search center templates OOB: Search Center and Search Center with Tabs. These templates are made available to the site whenever the Enterprise and Publishing features have been enabled, or the templates are created whenever a site is created from the Collaborative Portal site template.
The Search Center contains the Search Web Parts needed to quickly re-create the typical MOSS search experience. The Search Center with Tabs adds the ability to create multiple tabs within the Search Center that allow users to easily navigate between different pages. For example, separate tabs can be created for different search scopes (an example of this can be found at the end of the chapter) or even creating a tab for users to select when they want to do an advanced search.
| It’s possible to use the Search Center pages and Web Parts on sites that are created from other templates. To do this, you simply need to activate the Enterprise, Publishing, and Search Web Part features on the site collection. After the appropriate features have been activated, you’ll see the Search Center templates and Web Parts available in your site creation options and Web Part Gallery. |
Search Pages
Several pages get created by default whenever you create a Search Center site: default.aspx, people.aspx, peopleresults.aspx, advanced.aspx, and results.aspx. These are the pages that users will navigate through during their searches. Each of the different pages is preconfigured with various Web Parts. Each of these default pages plays a unique role in the search experience. The default.aspx and the results.aspx pages are used to submit and return the search results. When users submit a query on the default.aspx page, they are redirected to the results.aspx page to see their search results. If users choose to restrict their searches to the People scope, which only searches user profiles, they will use the people.aspx and the peopleresults.aspx pages. For any advanced searching, they will use the advanced.aspx page, which allows them to search on a granular level by mapped properties.
| Although the Search Center provides several OOB search pages, it’s possible to customize the Search Center to use custom pages as well. For instance, you could build your own custom results page that is customized with different Web Parts, layouts, or options and then redirect the default.aspx Search Box Web Part to use your custom page to render the search results. The pages provided are simply preconfigured to provide a complete search experience without requiring further customization. |
Search Web Parts
All of the interaction with searching is done through the various Search Web Parts. These Web Parts are very modular and can be added and removed based on your specific search requirements. If you’re just getting started with customizing search, a good place to begin is the results.aspx page. When this page is in edit mode, you’ll see that there are many different Web Parts used to build the search experience. Figure 8.3 is an example of the results.aspx in edit mode.
Each of these different Web Parts can be customized through the Web Part tool pane. For example, suppose you’ve been asked to implement the ability to show more results on the first page of the search results. By default, the limit is set to 10; however, your users want to see the first 15 results. You can do this by modifying the Search Core Results Web Part and setting the results per page property to 15. The following is a listing of different Search Web Parts. Keep in mind that they can be combined together to create a customized search experience.
Search Box. Used to enter search queries. Through the tool pane, you can customize the different components such as search scopes, link to advanced search, and width of the search box. You can also specify the page used to return the search results and append additional items to the user’s query.
High Confidence Results. Displays any high confidence search results. By default, it’s configured with people-centric properties, but it can be customized to match any of the mapped properties configured in the SSP.
Core Results. Displays the search results, which, by default, are ranked by relevance and returned in groups of 10. In addition, the results query can be controlled to create a fixed query, add additional details to the query string, add custom XSLT, or define a specific scope for the results.
Search Statistics. Displays the different statistics for the search results, such as number of results, total results, and elapsed time to complete the search.
Search Paging. Controls the paging of the search results.
Search Action Links. Provides additional actions that users can take after the search results have been returned. Using this Web Part, users can toggle between the way that results are returned (relevance or modified), create alerts, or subscribe to a Really Simple Syndication (RSS) feed. This Web Part can be customized so that only specific actions are displayed to the users.
Best Bets. Displays any best bet, keywords, or high confidence results associated with the search query.
Search summary (did you mean?). Displays a summary of any keywords used in the search query as well as any suggested corrections for spelling.
Advanced Search Box. Allows you to submit an advanced search query by providing the ability to narrow the search based on properties or scope.
Federated Results. Displays federated results from the federated data sources.
Top Federated Results. Displays the top results across multiple federated data sources.
These Web Parts are what define the search experience to the end user. The Search Center template is simply a convenience that makes it easier to get up and running more quickly, but the Search Web Parts could be added to any page that had Web Part zones.
Searching Behavior
When a user types in a query into the search box, the default behavior is for SharePoint to consider that all of the search terms need to be included in the results. For those familiar with SQL syntax, it’s similar to putting an AND between the search terms.
Additionally, by default, the search box supports stemming. Stemming is the process that happens when you type in a word. It is broken down into its basic form, and then other conjugations of the word are considered. For example, if you typed in the word “sit” through stemming, search would also look for other conjugations of the word such as sat or sitting.
Although the MOSS search functionality is very powerful, there are some limitations to how the OOB search functionality works. Users looking for more granularities in their results are limited by what they can type into the search box. For example, the search box doesn’t support syntax that allows a user to enter multiple search terms and provide results where any of the terms are included. In other words, by default, the search box doesn’t support the ability to use an OR clause.
One of the more common questions asked about the MOSS search is whether it supports Boolean operators or wildcard searching. The simple answer is no; MOSS search doesn’t support these searches through the user interface. The underlying MOSS search engine does provide support for both Booleans and wildcards, but they can only be leveraged through code. There are third-party options, such as Ontolica (http://www.ontolica.com) and MondoSearch (http://www.mondosearch.com), which extend the search capabilities to take advantage of the advanced capabilities without the need to write code.
| The Advanced Search Web Part helps to address some of the issues related to providing an interface that allows for more granular searching. |
When a user submits a query in the search box, the Web Part redirects the page to the results page and appends details of the query to the URL. For example, if you were to search on the term “Orlando,” the resulting URL would look like this: http://servername/searchcenter/Pages/Results.aspx?k=Orlando&s=All%20Sites.
The Web Parts on the results page read the information passed in the URL, also called the query string, and serve up the results accordingly. In the preceding example, there are two values specified in the query string, referred to as URL syntax; however, in addition to these two, other values can be passed in.
k. The specified keyword. Uses URL encoding for special characters such as 20 for spaces (http://servername/results.aspx?k=MOSS%20Explained).
s. Specifies the search scope.
v. Tells which view to use when displaying the search results. There are two options: by relevance (http://servername/results.aspx?k=MOSS%20Explained&v=relevance) or date (http://servername/results.aspx?k=MOSS%20Explained&v=date).
start. Specifies which results page to show (http://servername/results.aspx?k=MOSS%20Explained&start=2).
You can further refine search results through the use of restrictions. Just like the name implies, restrictions are specific criteria that limit the search results to only what is specified. The restrictions can be typed directly into the search box to allow for greater control of what is being searched. However, they are similar in many respects to the URL syntax in that once entered into the search box, they are passed through the query string.
Property name. Allows queries to be performed against a specific metadata property (city: “New York”).
Scope. Specifies the scope to be searched (scope:MyCustomScope).
File type. Specifies the file type to be searched (filetype:docx).
Site. Filter by site (site:http://intranet).
| If multiple restrictions are used on the same property, SharePoint automatically assumes an OR between the terms so that the results are a union of the terms. For example, if your query is scope:HR scope:Sales, the results that are returned come from both of the specified search scopes. However, if multiple filters are applied to different properties, the results are the intersection of those values. For example, the search scope:HR DocumentType:benefits returns all results related to the keyword benefits from the HR site. |
The main point to all of this is that through the use of URL syntax and restrictions, you can harness more power from the OOB searching functionality without writing any custom code. This technique can be used to simply allow a skilled user to find content more easily, or with a little creativity, custom search solutions can be created. For instance, what if you had a list of locations and wanted users to be able to search them by city name? You could have them go to the advanced search page, but that solution is far more complex than simply typing in a city name into a box and clicking Go. This type of example helps to demonstrate the type of creative solutions to problems that are typically faced in MOSS.