Most organizations that use SharePoint 2010 have many sites; these can and often do number in the hundreds and potentially in the thousands. So the problem this simple solution solves is – users may have access to so many sites that they can’t recall how to access them. Indeed, often users have access to so many sites that a “menu-style” navigation bar would be so over populated it might become unusable to find the site they are looking for. Often “menu-style” navigation does not take permissions into account during its generation process. A typical user in one department might not have access to another department’s sites, so why generate the menu item for him or her? This obviously clutters the selections the user sees and complicates the items he/she might have to navigate through. However, this is a problem that can be solved using search. A very simple query can be issued to SharePoint Search 2010 or FAST Search for SharePoint 2010 that returns a list of all sites the current user may access. Viola! We have an accurate navigation panel for all users. And this is precisely what “My SharePoint Sites” does. Below is an image of the second page of results this tool returned for a particular user at one of our customer sites.
We can dig a little deeper into SharePoint search if we look at the results of the query mentioned above. By default, all queries use a relevance sort; however this may not typically be what users expect when they look for a list of SharePoint sites. Typically users expect an alphabetical list sorted by title and we can achieve this by configuring search to allow sorting by title. This is not a function of “My SharePoint Sites” but more a function of search, and by administering search we can achieve the desired result. Further, sorting by title has another complication, case. By default FAST Search for SharePoint 2010 sort is based on an ASCII sort order. Therefore, sorting will follow [0-9A-Za-z] as pattern i.e. Numeric values will be followed by capital letter followed by small letter words in ascending sort. Again we can solve this problem by administering search. Like any problem in computer science, we can achieve the desired results several different ways, the final implementation depends greatly on the needs of the organization.
One method to solve this problem is found at this link: http://blogs.msdn.com/b/pasen/archive/2011/03/08/case-insensitive-sort-order-in-fast-search-for-sharepoint-2010.aspx . Although, as the blogger noted – this approach has a limitation – once a new metadata managed property is added or an existing one gets deleted, the index-profile file is re-generated. The newly generated file does not retain the modified values. A more flexible solution is to write a FAST pipeline extensibility stage that would copy an existing crawled property into a new crawled property and changing the case of the content to a standard upper or lower case. Then sorting on this field would yield the users expected results. Another easier solution would be to implement Discover Technologies’ Field Modifiers for FAST for SharePoint 2010. This tool allows you to accomplish the same result simply by modifying an XML configuration file.