I was asked the other day if SharePoint Designer 2010 will work with 2007 based sites. It looks like SharePoint Designer 2010 is not supporting backward compatibility. Therefore it won’t support Windows SharePoint Services 2007 / v3 or earlier versions. Unfortunately, SharePoint designer 2010 only works for SharePoint 2010. However, you should be able to have both versions installed and running on your computer simultaneously. Is this a correct assumption?
Frequently I get requests on how to hide the breadcrumb navigation links on a page in SharePoint. For a single page, you can
add a content editor web part to the page and then add the following “code” in
the Source Editor.
If you want to hide the breadcrumbs on all pages,
you can add the code to the master page or an alternate css.
Understanding the SP2007 Search
This is the body of content that the search will be run
against. These can be subsets of the whole content index to help narrow down
and refine the breadth of the search.
SharePoint Search provides search scopes in a drop down list whereas
team sites provide the search scopes as tabs (by default these are the whole site and people).
|This scope||Enables users to||At this level||Customisable?|
|All Sites||Search across all content in the index||Search Centre
Lists and libraries
|People||Search for people||Search Centre
Lists and libraries
|This Site: Site name||Search across the current site and all of its sub sites||Top-level site
Lists and libraries
|This List: List name||Search across the current list or library||Lists and libraries||No|
Site and list searches are (in theory) accurate from an end
user perspective but linked content can be held in different areas of the site
or become scattered across the site over time. This can be counteracted using
properties and scopes.
Customisable scopes are available and these can be used to group
certain content in the index into a set of content upon which queries can be
run. This can be done across the whole collection of sites (shared scope) or on
a site by site basis (site-collection-level scopes). The default scopes are
copied and then built upon to create a customisable scope.
As indicated in the table scopes can be applied to different
levels of the site with more functionality available at the higher levels. Only
shared scopes can contain scope rules based on a specific content source.
Scopes are customisable from their default state with rules
that can include, require or exclude the following elements:
|This scope rule type||Is available to shared search scopes||Is available to site-collection-level search scopes||Tests content by|
|Web address (http://server/site)||Yes||Yes||Location|
(Author = John Doe)
|Content Source||Yes||No||A particular content source|
|All Content||Yes||Yes||All content in the content index|
More than one rule can be added to help refine the search.
An example could be a user looking for recently updated document in a huge (and
disorganised) document library; the scope could set search location to the root
folder containing all folders and for a last modified date of less than a week.
Display groups provide a way to assign scopes to a
particular search box.
Upon crawling, the SharePoint search logs meta properties
for the content – these can have different names in different programs. With
2007 came the ability to effectively map the trawled properties to agreed unique
Managed properties have the following benefits:
Users can use managed properties to construct
queries in the search box that filter search results.
You can use properties on the Advanced Search
page to enable end users to easily filter search results.
Site owners can customize the Advanced Search
page to use different managed properties.
Site administrators can create custom scopes
with rules that filter search results based on queries. End users benefit from
advanced property-based queries without the need to learn how to construct an
Currently the following searchable properties are available through SharePoint 2007 search:
- Created Date
- Last Modified date
Mapping more properties increases the size of the search
database, and reduces performance accordingly, so it’s a good idea to map
properties only when you are confident that the mapping is relevant. Where
multiple instances of the same meta data appear during a crawl user defined
priorities can be set so that the ‘more important’ data string is used.
Managed properties can be included in the rules and search
scopes, it is important to ensure that:
The managed property exists
The managed property is available for use in
There are properties of that content that are
mapped to managed properties that can be included in scope rules
When searching using managed properties only the is exactly or is exactly not operators can be used. Managed properties have to be
made available for use in search scopes by the administrators.
The quality of the results delivered is inherently linked to
the level of meta data in the content itself – gapped meta data will omit that
content from searches. It is important the managed properties are unique. Poor
mappings of crawled meta data and managed properties can also result in poor
results. Where a crawled property is key to the information architecture it can
be turned into a managed property (such as AD logon).
What Users See in the Search Results
Office SharePoint Server 2007 enables site collection
administrators to create an entity called a keyword that is directly related to
keyword phrases of the same name that are in the index. A site collection
administrator can create a keyword using one or more words.
Keywords can contain a definition, best bets and synonyms to
help users find what they are looking for.
Best Bets can be used to represent the keywords and suggest
a link to the user. These can include further information such as a title and a
description. These can point to top level site pages or a specific page within.
They can also include my sites for best bets such as “chief exec” or “Erika”. Best
bets can appear in search results without the content being crawled.
Synonyms are useful when several search terms are used for
the same concept and content, so that search results are consolidated and not
scattered across several search terms.
It is possible to bump certain pages up the search results
by increasing their relevance – http://go.microsoft.com/fwlink/?LinkId=93736&clcid=0x409
There are 3 levels of relevance – Most authoritative, second
most…, third most… – sites can also be demoted to below the level of
content without a specified relevance.
Good practices to use when planning authoritative page
SharePoint sites and business applications
central to high-priority business processes will typically be most
authoritative. Could these be mapped from usage stats? (HR policies, flexi sheets, apps
Sites that encourage collaboration or action are
likely to be more authoritative than sites that are merely informative.
Sites that are informative but not central to
high-priority business processes or used for collaboration are likely to be in
the second or third level of authoritative sites.
External sites will typically be less
authoritative, because your organization cannot control the content on those
You don’t need to assign an authoritative page
setting to every site. It is a good idea to select relevance for a small number
of sites that you know are most authoritative or less relevant, and adjust the
authoritative page settings during normal operations based on feedback from
users and information in the query logs.
The default precedence for file types in the search setup
for enterprise search is:
- HTML Web pages
- PowerPoint presentations
- Word documents
- XML files
- Excel spreadsheets
- Plain text files
- List items
The current setup has changed this as .ppt files are not
Title and URL seem to be weighted highly.