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.
