I’m in the Advanced Search-Based Solutions in SharePoint 2010 session at SharePoint Connections in Orlando. And, although I’m really interested in search solutions, I’m most excited about the “Cher Point” t-shirt that Richard Boucher picked up for me this morning. It’s cold, so I’m wearing it over my black hoodie:
The search architecture for SharePoint 2010 can seem a bit complex. It’s also very elegant. You must first decide which search is right for you. I’m not interested in the single farm search tool or anything less simple than SharePoint 2010 Enterprise Search and FAST Search Server for SharePoint 2010.
There are amazing improvements this year in Enterprise Search, but even thought its a great cross-farm search, my company will index beyond the limits of this product. However, until we reach those limits and move our search topology to accommodate FAST, we might as well utilize this to its fullest potential.
Scot is talking a lot about keyword query search. I’ve just seen him bring back everyone in a farm who’s last name begins with “C” by entering “lastname:C” in the people search application. This allows a developer to include an “A,B,C..” phone book type control to the UI. Neato.
What’s great with SP 2010 is that, as an administrator/developer, you can intercept a query and modify it, changing the results returned. You do this by editing a web part called the core results web part. Then, use the GetXPathNavigator method to modify the results of the Query Pipeline. Results are always returned as a big XML document (hello, RSS aggregation possibilities). An example of the usefulness of this is when a user search for all tasks. The search engine would normally return results by “relevance”, but most people would probably want to see tasks returned by due date.
There’s another interesting idea to federate search. You can create a custom web part that searches in SharePoint and other search engines as well, like Bing, Google, Yahoo Search, etc. This is especially useful if someone is searching for market intelligence.
If you consider all the different content types users could search on, you begin to understand exactly how much you can impact the usefulness of the search results, which can be developed separately as stand-alone solutions in SharePoint Designer (of all things). Don’t forget to go to advanced mode or otherwise it can be a bit tricky.
The possibilities are endless for search-based solutions. Understanding keyword query search and how to edit the core results web parts is key to providing results your users actually need.