A Matter Of Degree

FREE Ontolica Actionable Search Result Webpart for SharePoint

Today the folks at SurfRay (makers of Ontolica) released a free download of an actionable search results webpart for SharePoint (SP 2010, and FAST Search for SP).  To quote their description:

"This free result action web part adds four of the most commonly used document action menus to SharePoint search results. The solution adds a drop down menu similar to that found in SharePoint document libraries.

• View Properties
• Send Link Via Email
• Add to My Links
• Open Document Location

This web part deploys as a replacement to the Core Search Results web part in SharePoint 2010 and FAST Search for SharePoint."

Here's what you'll need in order to deploy and test it in your own environment:

- SharePoint 2010 with a functioning Search Service Application and Search Center
OR
- SharePoint 2010 with FS4SP.
AND
- Access to the SharePoint server.

I have the download and can’t wait to try it in my SP 2010 dev environment.  Definitely an easy step toward better Search experience and greater SharePoint Search Maturity!

How to make "This Site" the default SharePoint search scope

A client recently asked how to make "This Site" the default SharePoint search scope from the simple search box on all pages.  "This site" does not appear as an option when you try to manage this via the GUI (Site Actions | Site Settings | Site Collection Administration section / Search Scopes), so you can't set it as the default there.

I found the answer on this thread on SharePoint Blogs / SharePoint University:

http://www.sharepointblogs.com/forums/t/16293.aspx?PageIndex=2

and I wanted to reproduce it here with a few additions.  User Monty Myers (monty.myers) posted the following; my additions are in red:

Add or Modify the following line in the OSearchEnhancedFeature.xml file located in 12\Template\Features\ : (The full path is C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATURES\OSearchEnhancedFeature, then open the SearchArea.xml file in NotePad)

This is the line of code you will add:

<Property Name="DropDownMode">ShowDD_DefaultContextual</Property>

The bold line below shows where the line of code needs to be added: 

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <Control
        Id="SmallSearchInputBox"
        Sequence="15"
        ControlClass="Microsoft.SharePoint.Portal.WebControls.SearchBoxEx" ControlAssembly="Microsoft.SharePoint.Portal, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c">
 <Property Name="GoImageUrl">/_layouts/images/gosearch.gif</Property>
 <Property Name="GoImageUrlRTL">/_layouts/images/goRTL.gif</Property>
 <Property Name="GoImageActiveUrl">/_layouts/images/gosearch.gif</Property>
 <Property Name="GoImageActiveUrlRTL">/_layouts/images/goRTL.gif</Property>
        <Property Name="UseSiteDefaults">true</Property>
 <Property Name="FrameType">None</Property>
        <Property Name="ShowAdvancedSearch">true</Property>
 <Property Name="DropDownMode">ShowDD_DefaultContextual</Property>
    </Control>   
</Elements>

After making the change, save the file and do an IISreset. 

Important:  when you customize the SearchArea.xml file, it is unghosted, meaning that future patches and upgrades could overwrite your changes.  As a best practice, you should create a feature to install this unghosted file to current site collections and deploy the change in this manner.

When search doesn't work from SharePoint MySites - Preferred Search Center Weirdness

I've seen this issue with two MOSS 2007 implementations now - end-users report that performing a search from a MySite returns Access Denied.  The typical scenario is that a user will do a People Search for an individual, click through to the result which puts them on that individual's MySite, and then from that Mysite they'll try another search for a different user.  At this point they get an access denied error or other weirdness.

The solution to this issue is to go to the Shared Service Provider in Central Administration, click on My Site Settings, and ensure that the Preferred Search Center URL is correct (i.e. that it points to the desired Search Center, typically the one used in your main SharePoint portal - like http://[sitename]/searchcenter/Pages/)

The worrisome aspect of this is that both times I've seen this issue, it has happened after a new site collection was created, and that new site collection's Search Center URL got plugged into the SSP's Preferred Search Center setting.  One of my colleagues theorized that this setting points to the most-recently-created Search Center (and a new Search Center is created each time you use the Collaboration Portal template for a new site collection).  I could not find a setting in Central Administration, or at the time of creation of a new site collection, to prevent this from happening.

You know you're living in an interesting society when...

...you type "modifying" into the Google search field and the third most popular result that appears on the drop-down of query suggestions is "Modifying nerf guns."

Search Relevance Tip - Best Practice - Spaces in Filenames / Title Field

I'm in my third and final day of MOSS 2007 Enterprise Search Advanced Training.  There's a best practice from yesterday's session that I want to discuss.  Microsoft recommends that content owners / end users use spaces in filenames to make them searchable (i.e., "MOSS 2007 White Paper" and not "MOSS2007WhitePaper").  The indexer treats a filename without spaces as a single word.  Tests during the session proved that filenames using underscores ("MOSS_2007_White_Paper") and dots ("MOSS.2007.White.Paper") also are not indexed as individual words but as a single word.  Therefore a search on a keyword that is a part of such a filename ("MOSS") will not show up in search results.

That's significant, but spaces in filenames can cause issues.  (Another example.  And another.)  These may not be SharePoint issues, but it's possible that you'll have compelling reasons not to use spaces in your file names.  At the very least, it could be difficult to enforce a file-naming convention across an organization, especially when there's no out-of-the-box validation at the time of upload.

My recommendation is to require the Title field in Sharepoint document libraries, and/or to train content managers on the importance of using this field.  Title is very important in ranking and relevance, so much so that MOSS 2007 search uses a text extraction algorithm that generates TWO title values for every MS Office document - the actual title field from the document property sheet, and a "shadow" title based on formatting and placement of the words at the top of the document.  If content managers populate the Title field with meaningful words, the formatting of the original filename is not so critical to search results.

Google search tool - Soople.com

I recently attended a Knowledge Management Forum on Search, and will be blogging on a few of the resources and trends I learned about, but wanted to pass this one along right away -

Soople.com

- "A site that softens all the fantastic advanced functions Google offers. This site is meant for all those who are not yet familiar with all the possibilities of Google and all the required syntaxes."  It's not affiliated with Google but brings together many different flavors of Google search on one page.  Useful!

Netflix's Problem Is Your Company's Problem

Online movie-rental company Netflix announced yesterday that it is offering a million-dollar prize to anyone who can improve their recommendation system.  In an interview on NPR yesterday, James Bennett, vice president for recommendation systems at Netflix, suggested that the issue is not so much with the existing tool, but with the metadata associated with movies in their database.  He said that one way to improve the system could be to offer a questionnaire that a user could fill out to improve their recommendations, with such questions as "Do you like movies with happy endings?"  However, in such a system, if the user answers yes to that question, the application must then find movies that have happy endings, and there is currently no data to support this.  What Netflix knows about movies is who made them and who's in them, some basic genre and ratings information, and any associated awards.  This is a good start, but it's not enough to provide the subtlety of recommendations that users want, and it will be a gigantic job to re-tag the database of movies if someone develops a better solution.

This is why, as you design your corporate portal, document management system, or any other  database particular to your company or industry, it's not enough to go with the the application's default metadata, or with What You've Always Done.  You need to think carefully about the metadata you are collecting on, say, a repository of documents.  How might your employees want to use them, not just now, but five, ten, twenty years from now?  Having worked extensively with Microsoft's SharePoint Portal Server 2003 (now Microsoft Office Sharepoint Server, or MOSS 2007), I know how easy it is to start storing documents and information without building in any useful metadata at all.  The tool won't do it for you - you need to put the process and the standards in place first. 

To cite just one common example - suppose your firm wants to help the younger and newer employees by showing who at the company has expertise in particular areas.  How do you define expertise?  One way might be to see how many documents an individual has authored on a subject.  Sharepoint Portal Server automatically tags every uploaded document with "Created By," which is the login name of the uploader.  But what if the uploader is the expert's secretary?  The new employee searching on the subject will find a lot of documents "by" that secretary.  It might be possible to infer who the real author is, but what if the secretary works for more than one person?  By the time you decide you need to include an "author" field on all document libraries, there might be hundreds or thousands of documents already in the system.  Who's going to go back and enter the author information for all of them?  But if you make the "author" field required only for uploaded documents going forward, you won't be able to capture all the good work that's already been done.

It can't be stressed enough - plan and strategize how to handle metadata BEFORE you implement a new system, especially one like SPS or MOSS. 

Now here's my suggestion for Netflix.  The problem is, if I say I loved a certain action film, Netflix recommends a bunch of other action films in a similar time period and style.  But maybe I loved it because of clever dialogue or an exotic setting, and not because of its genre or actors.  How about this:  after I rate it four stars, give me a standard list of choices for "Why?"   The plot, the stars, the special effects, the script, etc.  The choices could even be multi-select or rankable.  Do I actually have to code it to get the million bucks?