Share


How to shorten the learning curve for SharePoint search

February, 2008

See also SharePoint Thesaurus Web Part

Unlike earlier versions of SharePoint, the current release (now called Microsoft Office SharePoint Server or MOSS 2007), comes with a reasonably good search function. Its close integration with other Microsoft applications and low cost, make it an enterprise search contender in many organizations. But for many people, even those with other search engine experience, implementing MOSS 2007 search can be frustrating. This article offers some suggestions for shortening the learning curve based on our experience installing SharePoint search in our lab.

Suggestions fall into 2 categories:

1. Things to do before you start, such as waiting for the product to mature, managing user expectations, thinking search system instead of search engine, assembling the right team, and taking time to plan.

2. Things to do after you begin, such as doing targeted Google searches, creating a library of helpful resources, and creating "quick and dirty" screencasts.

Wait for the application to "jell"
Savvy IT managers wait at least a year after a new software product has been released to install it. This gives publishers time to prepare reference books and training materials, programmers time to fix bugs, and consultants time to gain experience with the product. Today, MOSS 2007 is a little over a year old. How-to training materials, many produced by Microsoft "MVPs," are becoming more widely available, and the first major MOSS update (SP1) has fixed some of the bugs.

A reason to wait even longer is Microsoft's recent acquisition of the FAST search engine. We are hearing that it may be two years before FAST technology is integrated into SharePoint (a good possibility). Meanwhile, a new version of Windows Server 2008 (the operating system SharePoint runs on) has just become available, and it's likely that the second Service Pack for MOSS will be released in the next two years.

Two years may be too long for many organizations, but the longer you delay, the better the documentation, the more stable the software, and the more best practices will be available.

Manage expectations
"Managing expectations" is a nifty IT concept designed to communicate the idea that:

  • new software won't solve everyone's problems;
  • new software won't live up to all the vendor hype (unless you spend a lot of time and money on customization);
  • intranet search won't work like the public Google no matter what you do;
  • "dirty" content and data must be cleaned up for any search engine to work right.

In other words, by setting realistic expectations on the front end, you can save time and money on the back end by reducing the number of tasks on the to-do list, spreading the responsibility among different departments, and reducing frustration among managers and end users.

In the most extreme case, you can restrict MOSS 2007 implementation to those features that are available out-of-the-box (i.e. do not require any custom programming). Examples include PEOPLE search (which leverages your employee directory), security trimming for SharePoint content, indexing common file types (e.g. Office documents and HTML pages), and human editing of search results through Best Bets and scopes. Features like social bookmarking, taxonomy management, and security trimming for non-SharePoint content can increase the learning curve dramatically.

Think search system, not search engine
In many organizations, user dissatisfaction gives rise to intense pressure to replace an existing search engine with something new, and MOSS 2007 search is a logical contender. However, it's a mistake to think in terms of a "bake-off" between SharePoint and other search products. MOSS 2007 is a search system that includes navigation, content creation, desktop applications, and workflow. It's implemented using a hybrid top-down and bottom-up approach where teams and departments are given considerable freedom to design their own information access environments. It's assumed that local knowledge stewards will want to craft special search pages and add Best Bets that will display at the top of search results. It's also assumed that most will create and manage much of their content and user permissions within the SharePoint environment.

Google, Autonomy, Endeca, Coveo and others are search engines. They are typically top-down implementations with the assumption that user permissions, content creation, and document storage are handled by other applications — one of which may be SharePoint. Most include modules (APIs or application program interfaces) that will index MOSS 2007 content.

If you've implemented one search engine, you'll find it easier to install another one. However, the learning curve for a search system like SharePoint is steeper because you have to learn a new vocabulary (e.g. "content query Web part") and a new architecture (e.g. "site collections" vs. "Shared Service Provider") as well as gain an understanding of how all the pieces and processes fit together.

The big question is this. Is it easier to leverage your existing knowledge of SharePoint to index non-SharePoint resources or is it better to buy a good enterprise-grade search engine to index SharePoint? Each organization must find its own answer.

Assemble a team
In most large organizations, search engine implementation and management is handled by a team consisting of IT staff, document managers, taxonomy managers, and representatives of key business units. Microsoft recommends that local site administrators be included as well. These are people (sometimes called knowledge stewards) who design the end-user search experience and define search scopes, keywords, and Best Bets. In a large organization, there could be hundreds of them. Organizations that have a process to identify, train, and support knowledge stewards are likely to have a shorter MOSS 2007 learning curve than those that don't.

Take time to plan
Implementing MOSS 2007 is a little like visiting a foreign country. It helps to plan what you'll pack, where you'll stay, and what you'll see before you leave for the airport. Even a little planning is helpful before you sit down at the MOSS 2007 console. Start by reading the following 3 sections of Chapter 7 in Microsoft's free electronic book, Planning and Architecture for Office SharePoint Server:

  • Identify your search team
  • Plan to crawl content
  • Plan the end user search experience

The worksheets referenced in the book will help you select options once you begin search configuration and customization and will serve as a handy reference when you sit down at the SharePoint console.

After you begin
Once implementation has begun, we have found it helpful to capture new-found expertise as we go rather than rely on Microsoft's documentation or save the documentation task for the end. This strategy is appropriate for SharePoint because:

  • the decentralized architecture means that many other people will need access to your know-how;
  • SharePoint search implementation steps and processes are not intuitive;
  • if implementation is interrupted, you'll need your own captured know-how to avoid time spent in re-learning.

We have used three techniques with success:

1. Highly specific Google searches to find blog entries and Microsoft's own technical documents;

2. Capture and categorize useful resources in an electronic library;

3. Create quick and dirty screen tasks for each step in the process.

Google searches
If we can't find the information we need in SharePoint books, Microsoft's support Web site, or online help, we try a search on the public Google site. An example might be "MOSS 2007 complex URL" or "crawl complex URL." The more specific the search, the better the results.

Using this strategy, we sometimes landed on articles in the Microsoft Office Developer Center. Many of the articles are rated using one to five stars. How nice it would have been to click a link and get a list of all 5-star articles!

Capturing search results
Once we found a useful page or document, we added a record for it to our electronic library (see below). At the same time, we'd save a copy of the page to a document repository (not SharePoint) in a shared folder on our local network. We usually save HTML pages as PDF files so we can enter notes and highlight text. Files are given a name that corresponds to the electronic library catalog record number so they can be retrieved later with a single click.


click image to enlarge


The second step is to assign one or more index terms to the document. This is a quick and easy process, even if the term does not yet exist in our vocabulary.


click image to enlarge


The third step is to add a definition to SharePoint-specific terms and assign cross references where necessary.


click image to enlarge


Taking a little extra time after finding a resource is much more effective than creating a bookmark (or even using a social bookmark system like del.icio.us). The electronic library not only makes search and retrieval easier, but it automatically creates a topic index like the one below. A version of the index is also available to participants in our SharePoint course and seminar.


click image to enlarge

Screencasts
Step-by-step instructions with screen shots and screencasts are the most valuable resources we found in our searches for how-to information. The two formats are complementary. Written instructions can be printed out and used as a reference. Screencasts that show a sequence of screens along with mouse movements and an audio commentary show a process from start to finish. Most screencasts are short (less than 10 minutes) and focus on a specific process. By creating them as we progressed during the implementation process, we made a sequential record of what we had done (using creation date as the sequencer).

For capturing our own know-how as implementation progressed, we prefer screencasts because they are so much faster and easier to produce than written documents. There are two caveats:

1. Use the right software. Camtasia Studio is very easy to use for quick and dirty recordings — the kind we use for internal documentation. Producing publishable quality (without false starts and audio gaffs) and using Camtasia's editing features requires more skill and practice. That can always be done by an experienced Camtasia editor after the fact.

2. Use flash as the output format. Screencasts in flash format will play fine in most browsers without the need to open another program. You can also easily use Camtasia to produce other formats (e.g. podcasts), but screen shots don't display well on tiny ipod windows.

Conclusion
We've heard again and again that good planning is essential to SharePoint implementation, and our experience confirms it. We've also heard recruiters complain about a lack of experienced SharePoint developers. With that in mind, it helps to do everything possible to help internal staff get up to speed as quickly as possible and share their expertise as widely as possible through an electronic library and screencasts.

Created on February 10, 2008 l Updated on January 4, 2010