Metro Style SharePoint Search Results

As a proof of concept I created recently I wanted to see what can be quickly done to alter the out of the box search results layout. For the project I was working on, the context of where a keyword appears in a result was important so I wanted to increase the amount of preview text that the search core results web part returned by default. However, I didn’t want the user to be overwhelmed by too much text on screen so I decided to experiment with delivering the search results in a metro style live tile. My inspiration came from the Microsoft MSDN tiles I see virtually everyday when I visit their site:

Here’s what I came up with:


Each result consists of two panels, the result panel simply contains an expanded preview of the document content with the out of the box hit highlighting. Over the top of the result panel is a semi transparent title panel that floats up when the results panel is hovered over. The title panel contains the standard search result details. In my environment I’ve set this up so that a single result only takes up as much height as an out of the box result does but clearly more pimagereview text is visible.

To implement this yourself, you’ll need to do four things:

1. Edit the search results page and expand the ‘Characters In URL’ parameter from 180 to 600. This will ensure that more preview text is returned as part of the search results response and that the results panel gets filled (in most cases). However, please note that this means the amount of data being transferred across the system for each search will increase and this might not be an appropriate thing to do in every environment.

2. Next, disable the ‘Use Location Visualization’ option. This will then allow you to override the XSL used by the search core results web part.

3. Override the default XSL used to render the results with the XSL used in my sample above. This can be downloaded from!397&parid=941D17ECA8C6632D!396&authkey=!ADsqmTHJv3MFfmk. The XSL I use overrides some of the default styles used by SharePoint but also relies on jQuery being available within the SharePoint site (see point #4).

4. Enable jQuery in the site collection. You can do this without having to write any managed code or change any of the master pages etc. by using ScriptLinks. I’ve posted a walkthrough of how to do this over here:

With the web part properties set and the XSL overridden, save the results page and you’ll see your search results displayed in metro style – live tiles (assuming you’ve already enabled jQuery).

If you want to adjust the look and feel of the tiles or their behaviour – float height, speed etc. simply update the XSL and reapply this to the search core results web part.


Graphical Search Refiners for SharePoint

Here’s my proof of concept for graphical search refiners for SharePoint 2010. It is based on the Google chart tools API, specifically the treemap library:

I simply override the XSL of the refiners web part so that the item counts for each refiners are used to display an area in the treemap proportional to the number of items found. There is no need to override the filter category definition xml to include counts (via the ShowCounts=”Count” attribute) as the XSL accesses the count values directly:


This is just a proof of concept so there are some (many) rough edges but if you want to grab the xsl I used it’s available here: RefinersXSL. Feel free to extend, enhance or use this as you wish.

Finally, you need to include a reference to the Google JavaScript API on your page somewhere:

<script type="text/javascript" src=""></script>

…perhaps via a content editor web part or via a delegate control.


Visual Best Bets with SharePoint Server using jQuery (not FAST)

Purely for demonstration purposes only I needed to quickly mock-up some visual best bets in SharePoint Server without using FAST. Thanks to the power of jQuery it took just 4 lines of script!


I’m assuming you have jQuery already deployed somewhere accessible to your site collection, if not, download it and upload jquery-X.X.X.min.js somewhere you can reference it, like the master page library for example.

First, create the HTML content you want to use as your new Visual Best Bet, here’s mine:


It’s not my best work but this is only a mock-up….Winking smile

Upload this html content to SharePoint somewhere.

Note: make sure you save and upload it as an ASPX file and not an HTML or HTM file otherwise you wont be able to access it directly due to the default Browser File Handling setting on the web application.

Next, create another HTML file that includes the following script:

<script type=’text/javascript’ src=’/_layouts/inc/jQuery/jquery-1.4.2.min.js’></script>
<script type=’text/javascript’>
    $(document).ready(function () {
        var u = $(‘.srch-BB-URL2’).html();
        $.get(u, function (data) { $(‘.srch-BestBets’).html(data); });

Note: The first line should be updated to point to your copy of the jQuery js file.

Upload this file to SharePoint somewhere.

Create standard Best Bet

Next we’re going to create a standard Best Bet. From our site collection (that hosts our Search Center) select Site Actions –> Site Settings –> Site Collection Administration – > Search Keywords. From the Manage Keywords screen create a new keyword:


Assign a new Best Bet to the keyword:


The URL you enter for the Best Bet should be the URL of  your HTML content you uploaded earlier as an ASPX file. Next, access your Search Center and test the Keyword and Best Bet is working:


Now edit your search results page and below the existing Search Best Bets web part, add a new content editor web part. Finally set the Content Link property of the content editor web part to be the URL of the script file you uploaded earlier and set the web part chrome type to ‘None’.

Save the page and execute your search again.

Now when the page loads, the jQuery script finds the URL from the standard Best Bet we defined, loads the HTML content from the URL via asynchronous Ajax and finally replaces the contents of the out of the box Best Bets web part with our HTML:


Please note, this is only a mock-up and not production quality code but it does illustrate the power of jQuery and Ajax quite nicely


Failed incremental crawl can remove items from an index

I stumbled across this today whilst reading ‘Plan for crawling and federation (SharePoint Server 2010)’ :

In the reasons to do a full crawl section:

You want to resolve consecutive incremental crawl failures. If an incremental crawl fails one hundred consecutive times at any level in a repository, the system removes the affected content from the index.

This could mean that if an incremental crawl fails to reach a piece of content 100 times in a row it will be removed from the search index. If you are performing incremental searches every 5 minutes, and they are consistently failing, after approx. 8.5 hours your index will start to be trimmed.

Best keep an eye on those crawl logs!

UPDATE 28-Sep-2011:

My previous comment about 8.5 hours was incorrect. There is another setting documented on that sets the minimum time that has to elapse before content can be removed from an index. The setting ErrorDeleteIntervalAllowed must also be exceeded before the content in trimmed from the index. You can maintain this setting and a few other related ones via the PowerShell:

$SearchApplication = Get-SPEnterpriseSearchServiceApplication -Identity "<SearchServiceApplicationName>"

## 1008 = number of hours (6 weeks)

$SearchApplication.SetProperty("ErrorDeleteIntervalAllowed", 1008)