I've built a small search solution which I think is pretty neat.
The problem: Customer has a team site with many, many children team sites. Each child team site is for a project team, and the company does about 300 projects per year. Currently, navigation to a specific project team site from the parent team site is via a drop down menu on the global navigation. This is an awful user experience because the menu has so many items that it is practically unusable.
Other requirements: Project sites have seven distinct attributes: project name, project id, project manager, department, project program, status, and URL. Search can be done on any attribute other than URL, and each search result should display all attributes.
Solution: Replace the menu item that has the drop down list of child sites with a menu item that links to a custom search page. This page lets the user easily search for a project site by any of the six attributes.
In this site collection, the only sites are the parent site and all the children sites - in other words, only the parent site and all the project sites. Create a Site Directory site, and customize the Sites list so that it can store all seven attributes of a project site. Set up a managed property for each of the seven columns. Do this in the SSP responsible for the indexer that crawls the site. Create a search scope that consists of a path rule (the URL to the Sites list) so that only the Sites list is in the scope.
Create a web part page in the Site Directory site, in a document library -one that has a variety of web part zones, including at least one zone arranged vertically. On this web part page goes one custom web part which provides the query user interface (more about this in a bit). Beneath that goes the search results paging web part, then the core results web part, then another search results paging web part. Configure the search core results web part - open its task pane. You want to make all the managed properties for the Sites list available for use. You do that by listing them in the Selected Columns textbox. This list is specified as XML, and you just add some nodes following the existing pattern.
Use the XSL Editor. Configure the XSL that formats the results so that individual search results display the appropriate metadata. In the XSL, use the right CSS classes so the search results use the company colors (if needed. If you have access to the style sheet used by the site collection, you can change the styling there. In this case, that file was owned by someone else, and in order to limit my changes to only the areas I wanted to affect, I did the style changes locally.).
The custom web part was an ASP.NET web part that included a user control which displayed two text boxes, 3 drop down boxes, and 1 people picker control plus a search button and a clear button. It was of course wrapped in a feature wrapped in a solution. On the user control, the 6 search criteria controls were laid out in 3 rows of two, with the project name and project id controls being the text boxes, the project status, program, and department being drop down list boxes, and project manager being the people picker control. The choices for the drop down list boxes were populated from the filed definitions for the corresponding fields in the Sites list.
When a user clicked the search button, the web part would build a keyword query in URL format, and refresh the web page with the keyword query in the URL. For example, if the user did a project title search for "foo" and the search page is named projectsearch.aspx, then the URL that would be navigated to would be, before URL Encoding:
projectsearch.aspx?k=projecttitle:"foo"
All my query web part had to do was build the URL. The standard Core Search Results web part, seeing the URL parameters would do the actual search and display the results.
You can specify the scope you created either in the core search result web part properties or in the URL.
Pretty neat, huh? I think I've done a good job of providing a functional solution while maximizing use of the out of the box capabilities and configuration and minimizing the amount of work that needs to be done in Visual Studio. It also shows how this customer is now getting even more value out of the built in enterprise search functionality.
Next my customer wants a version 2, which supports wildcard searches and allows each user to save their own search defaults.
That's all for now.
Happy Holidays!
Michael