SharePoint 2010 : Configuring Search Settings and the User Interface - The Preferences Page: An Administrator's View

4/5/2013 4:44:56 PM

1 . The Preferences Page: An Administrator's View

The Preferences page is accessed by clicking the Preferences link (Figure 1) to the right of the search box.

Figure 1. SharePoint 2010 Enterprise Search Center dialog

Understanding Why the Preferences Page Improves Search

Letting the user specify settings regarding the search experience directly from the search centers is generally a great idea, as users often have little knowledge about what options exist for tuning their SharePoint experience. This is partly due to the extensive set of possible settings found in the Site settings page (if the user has permission to access this) and partly due to the settings in SharePoint generally being hard to find if not often used. Having this Preferences page will reduce the time required by the administrator or support staff to teach users how to modify the language setting in their browsers and what effect it has. Now this is more intuitive, and most users are expected to grasp the general concept of what this does with less training.

Adding the Preferences link next to the search dialog text box in search centers makes users intuitively aware that they can modify search-related settings and encourages the use of them. The concept is also known from the Google search page, which most users are assumed to be reasonably familiar with.

The Preferences page allows the user to enable/disable search suggestions and to specify the search context language(s) to be used.

Preferences Scope

The Preferences page is available both in Basic and Enterprise Search Centers. This is obvious as the settings on the Preferences page influence search results from both types of search centers. Preferences are personalized by being bound to a user profile. This way the user will use the same settings regardless of which computer is used to access the search center. In SharePoint 2007, the search context language was based on the browser's language. Preferences are applied globally throughout the SharePoint farm such that they will be the same for all search centers on all web applications.

Overriding the User's Language Settings

SharePoint 2010 introduces phonetic search and nicknames for People search. As both of these are language-dependent, the Language setting influences the search results returned. The search is performed against all selected languages using stemmers, word breakers, phonetics, and nicknames in all selected languages.

In SharePoint 2007, the administrator has the option of specifying the search context language in the search center to override the browser's Language setting. Even though it is now possible in SharePoint 2010 for users to directly set the language on the Preferences page, this can still be overridden by the administrator. But given that more emphasis has been put on this setting, the administrator needs to be aware of the impact it has on search results. By either overriding the language for search or using the fixed query setting and the Language property to augment the query with a fixed language, this will effectively override whatever setting the user has made. Doing so may cause confusion for users who expect their own Language settings to apply. It is suggested that this gets communicated to users if the Language setting is fixed by the administrator.

On the other hand, giving users access to settings such as the Language setting that directly influences the returned search results can also cause problems from an administrative point of view. Allowing users to define which languages are used for searching reduces the administrator's options for controlling the search behavior and results. This is something that an administrator needs to be aware of when users complain that they cannot find a specific search result.

Issues to Be Aware Of

Although the Preferences page adds these preferences directly where needed to make the user aware of their existence, it does introduce some problems. The number of settings exposed through the Preferences link is very limited. It allows the user only to turn search suggestions on and off and select the language context of the search.

One important thing that is missed is an easy way for users to learn what a specific setting actually does. In this case, this is actually a significant issue, as both the search suggestions and the Language setting can be difficult for users to grasp if no training or information is provided to them. Still, it is easier than changing the browser's Language setting, as this is something that tends to be forgotten or ignored.

As mentioned earlier, the Search Suggestions feature works only if search suggestions are turned on in the search center. This leads to confusion when the user enables this feature and nothing happens. Although this feature is global for all search centers, it would have been useful to show a warning message to the user on the Preferences page, saying that this feature is not activated on this particular search center as the setting is accessed from the search center where a change is wanted. It might have been a good idea to not include the Search Suggestions feature, as this works only if a site administrator has enabled search suggestions in the search center.

The most important setting from a search perspective is the Language setting. It would have been really useful to create a page only containing this setting. This way the Preferences page would include only the Language option, and the Preferences page could be named accordingly. The argument for why this would be a good idea is that the Language setting influences the returned search result set. Especially for searches that could potentially return search results containing multiple languages, this becomes an issue. An often-heard user complaint in SharePoint 2007 is: “Why are the search results different on my other computer?” The answer in many cases is due to a difference in search context language settings, which in SP2007 were set in the browser's own Language setting. As the Language setting does solve this issue, it would be preferable to expose it more directly.

2. Stemmers and Word Breakers

In SharePoint, stemming is used in combination with the word breaker component, which determines where word boundaries are. The word breaker is used at both index and query time, while the stemmer is used only at query time for most languages (exceptions are Arabic and Hebrew). A stemmer links word forms to their base form. For example, “running,” “ran,” and “runs” are all variants of the verb “to run.” Stemming is currently turned off by default for some languages, including English. Stemmers are available only for languages that have significant morphological variation among their word forms. This means that for languages where stemmers are not available (such as Vietnamese), turning on this feature in the search results page (Search Core Results Web Part) will not have any effect, since in such languages an exact match is all that is needed.

Word stemming is not the same thing as wildcard searching, which has to do with doing searches with * in the query. This means you are asking the search engine to find all words that start with the text string and end with anything, since * means match any continuous text string to the end of the word, which in most languages (excluding most East Asian languages) is indicated by a white space. So a search query using * such as “Share*” will return results including “SharePoint,” while a search query using the word breaker and stemmer would bring back “sharing,” which is an inflectional variant of “share.” Wildcard searching and word stemming are often used to refer to the same thing, but they are, in fact, separate and different mechanisms that can return different results—for example:

Searching for “run” would also return results containing “runs,” “ran,” and “running.”
Searching for “page” would also return results containing “pages,” “paged,” and “paging.”

Although it would seem obvious to just turn on this feature per default, it does impact how search behaves in ways that might not be desired. Word stemming can affect the relevance of your search query. If some terms have lots of stemming and others have none, one word may now dominate results even if it isn't the priority in the context of what was looked for. Stemming can also negatively affect performance—there will be a delay while expanding the search query to include stemming, and a larger set of results will be returned.

3. Phonetics and Nicknames

Phonetics and nicknames are new additions to the search facility in SharePoint 2010. They are targeted at People search and offer significant improvements to the user's ability to find other people inside or outside the organization. This is especially compelling for multinational companies, where incorrectly spelling names or knowing colleagues by nicknames only is common.

Phonetic Search

Phonetic searching considers alternative spellings and misspellings of a name in the People search results. More specifically, phonetic searching takes into account that many times users know how to say a name but do not know the correct spelling for it. Although this feature is currently isolated to People search, it is the search center that generally presents the largest roadblocks to spelling.

Assume that a user needs to find contact information for a colleague named Geoff Petersen. The user does not know how his name is spelled and instead types Jeff Peterson in the search dialog. Although neither Geoff nor Petersen is an exact match for Jeff Peterson (not even a wildcard match), Speech Server in SharePoint 2010 will return Geoff Petersen as a search result, thus allowing the user to find him based on the combination of first name and surname.

Note Phonetic searching considers only alternative terms based on SharePoint 2010's thesaurus. Cutting a query short and searching for the term Mayn will not necessarily return results for the person with the last name Maynard. For this query to function properly, the wildcard character should be entered at the end—Mayn*.

The behavior of phonetic search is influenced by the Language setting. Although the phonetic alphabet is language-independent, as it is based on the International Phonetics Alphabet (IPA), the pronunciation of names can differ between languages.

Nickname Search

Nicknames add another new facet to People search. As with phonetic search, it is language-specific, but instead of phonetic matching, it works by lookup. Assume a user is searching for a colleague named Michael, with the search context language set to English, but the user knows him only by the nickname Mike. Performing a People search for Mike would then return results for Mike and Michael because of the new Nicknames feature.

As mentioned, the Nicknames feature is language-specific, which means that not all nicknames are valid for all languages. The foregoing example with Mike works for the “en-US” LCID (locale/language ID), which is 1033, but not for the Danish “da-DK” LCID, which is 1030.

The nickname mappings can be found in the table called MSSLanguageResources, which is located in the Search_Service_Application_DB database (if the default name is used for the Search service application).

To see all nicknames for Michael, the following query can be executed in Microsoft SQL Server Management Studio (database name might differ):

SELECT [Phrase],[Mapping],[Locale]

FROM [Search_Service_Application_DB_<GUID>].[dbo].[MSSLanguageResources]

WHERE Mapping ='Michael'

GO

Table 1 shows the query results. The first column is the nickname. The second column is the name it maps to (Michael in this example). The third column is the Locale ID (LCID) or language variant for which the nickname applies.

Table 1. Query Results

Nickname	Mapping Name	LCID
micha mi	chael	1031
michi mi	chael	1031
mischa mi	chael	1031
michal mi	chael	1033
michale mi	chael	1033
micheal mi	chael	1033
michel mi	chael	1033
mick mi	chael	1033
mickey mi	chael	1033
micky mi	chael	1033
migi mi	chael	1033
miguel mi	chael	1033
mike mi	chael	1033
mikel mi	chael	1033
mikey mi	chael	1033
miki mi	chael	1033
miquel mi	chael	1033
mitch mi	chael	1033
chiel mi	chael	1043
giel mi	chael	1043
machiel mi	chael	1043
maikel mi	chael	1043
michai mi	chael	1043
michal mi	chael	1043
michel mi	chael	1043
michiel mi	chael	1043
mitchell mi	chael	1043

One thing to be aware of is that nicknames might apply both ways, such that Michael is also a nickname for Mike. The same query just mentioned can be changed to view these by changing the mapping in the SQL query:

SELECT [Phrase],[Mapping],[Locale]

FROM [Search_Service_Application_DB_<GUID>].[dbo].[MSSLanguageResources]

WHERE Mapping ='Mike'

GO

It is possible to add and remove nicknames using the new SharePoint 2010 PowerShell cmdlet. To add the nickname Mike for Michael and vice versa to the Danish LCID, the following can be run:


New-spenterprisesearchlanguageresourcephrase –Name Michael -Language "da-DK"

 –Type "Nickname" –Mapping Mike -SearchApplication 988218e4-b4f5-4042-b545-c5a6230aab24



New-spenterprisesearchlanguageresourcephrase –Name Mike -Language "da-DK"

 –Type "Nickname" –Mapping Michael -SearchApplication 988218e4-b4f5-4042-b545-c5a6230aab24

It might take a while for the new nicknames to take effect, as the required job named “Prepare query suggestions” must run before they get applied. The job runs every 24 hours.

Like word breaking, nicknames and phonetic searches work differently for each language. As long as the corresponding language pack is installed, the language used for a query can be supported by these features. If a user is attempting to search on a language other than his or her current browser language, the user will need to specify the language on the Preferences page. Up to five languages can be queried by the search engine at one time.

Other -----------------