Download now from SharePointMasterPages.com »

We created this Master Page to help  designers / developers get a head start on integration projects, or for anyone wanting a clean, simple look and feel for their SharePoint Foundation 2010 installation.

Layout: Floating width 90%
Supported Browsers: Firefox, IE 7+
Integration: Collaboration Sites, Meeting Sites, Calendar, Search

SharePoint Master Pages is dedicated to branding SharePoint 2010, with masterpages built for both SharePoint Server and Foundation.

We are starting from small beginnings but have quite a few plans for the future... In the coming months we plan to roll out more Master Pages, Page Layouts, some SharePoint 2010 branding resources and freebies.

Our focus is on creating high quality branding resources for SharePoint at a price point that makes sense. Much of what can currently be found for sale are either poorly designed or lack the thourough integration of items such as the calendar, wiki, and my sites. We are hoping to fill this gap and solve a few of your SharePoint branding headaches.

So check the site out, buy a Master Page and check back later for some more quality stock!

• We finally got the dot com for our domain! So we are now on www.trinkit.com (including email).
• Trinkit is now based in the US, currently on the West Coast.
• After our site spent the last couple of years built on SharePoint, we have rebuilt it to use the awesome Umbraco. This is a much more suitable framework for building public websites.
• We have mostly moved away from SharePoint based work. We are still working on our SP Themes site, stay tuned for some 2010 related updates here.

Lastly you can check out our updated portfolio to see what we have been up to over the last 18 months.

We are hoping to fill a market gap at a better price point, and solve a few of your SharePoint branding headaches.

Over the past couple of years, the number of SharePoint built websites has grown significantly. But how do all of these sites stack up from a technical SEO perspective? Lets have a look using the new IIS 7.0 SEO Toolkit to analyze our site: www.trinkit.co.nz.

Here is the output after running the tool over our website:

OK cool, lots of errors! Now what do they mean and what can we do about it?

1. The page contains multiple canonical formats
This means that there are multiple addresses that can be used to access the pages of our website. For example, take the home page; we could browse to this page in the following ways:
http://www.trinkit.co.nz/pages/home.aspx
http://www.trinkit.co.nz/Pages/home.aspx (capitalization)
http://www.trinkit.co.nz/pages/home.aspx (no www)

The effect of this is that search engines will potentially spread the ranking over the different URLs rather than aggregating it for the one page. Now search engines are fairly clever and it should work out that there is only one page to rank. Not taking any chances here is a method you can use to fix this (IIS 7 only).

2. The page contains unnecessary redirects
This is because of the infamous 302 rewrite issue.When you type a URL like www.trinkit.co.nz, SharePoint will perform a 302 (temporary) redirect to www.trinkit.co.nz/pages/default.aspx. This is not ideal as search engines are not as keen on following 302 redirects, they prefer 301s (permanent). There is no ideal way of fixing this but here are a couple of options:
- Use IIS7 redirect rules
- Using an HTTPModule

3. The description is missing (Not SharePoint specific)
This is really obvious, we are missing the meta description tag. The meta description tag is normally used for your search engine result page (SERP) listing and is a key factor in determining relevancy. While we are on the topic, don't bother with the meta keywords tag. The big search engines have been ignoring this since about 2002.

4. The page contains broken hyperlinks (Not SharePoint specific)
Another obvious content issue. Broken hyperlinks are said by some to affect page rankings. In theory search engines will favour sites and pages that have relevant, up-to-date content and broken links are sign of poorly maintained page. This is tough to keep a handle on with blogs that have large amounts of outgoing links, but there are tools available that can help.

5. through to 7. are not SharePoint specific issues and there are heaps of great resources around that address these so I won't cover that here.

8. The URL is linked using different casing
As mentioned in item 1, search engines are case sensitive. In an ideal world all of your urls and all the links to them would be lowercase, with dashes used to separate words. The navigation controls in SharePoint always redirect to a first letter capitalized 'Pages' and what is worse is the tendency for URL's to occasionlly be loaded in upper case. A technique to address this issue is discussed in this blog post.

9. & 10. are not SharePoint specific

11. The page contains a large amount of script code
SharePoint does have a habit of including an awful lot of additional javascript. However I do think it's a little bit unfair for it to be reported in this case as I have removed most of it. Plenty of the javascript that gets loaded is only needed for authenticated authors and the associated rich editing controls. There are a few simple techniques to remove this and doing so can give you a great performance boost.

12. This page contains invalid markup
It's pretty commonly known that SharePoint isn't exactly standards friendly. Search engines will have an easier time processing the contents of your page if it is easily parsable. Now this doesn't mean that it has to be XHTML 1.1 Strict compliant. It just means that all the tags are closed and are not mismatched, which is a lot easier to achieve than XHTML standards. As WCAG 2.0 has the same requirements you can use a WCAG 2.0 validator to test this.

One other thing that does not seem to covered by the IIS SEO Toolkit:

13. There is no XML sitemap defined
An XML sitemap tells the search engine where are all the pages you want crawled are, it is not made to be human readable. For a quick and easy way to get this setup check Waldek's sitemap generator.

Note that this was done on a slightly older version of the site, and a few of these issues have already been fixed.

The SEO tool is still in Beta and seems to be a little over zealous in the number of issues it reports, but it is already providing some really useful results.
Of course, nothing beats having really great original content that naturally generates healthy back links. Fixing these technical issues is really just a way of maximising that hard work and there is certainly nothing wrong with that!

We've been pretty busy over the last 6 months working on a variety of projects and I would like to share a few of these with you today. Some of the projects have been for clients, some for friends; a few have been big, most have been small. All of them were fun to make.

Environment Canterbury

Environment Canterbury is the regional council working with the people of Canterbury to manage the region's land, water and air. This site was released just a week ago and was built using SharePoint Server 2007 (of course!). Was a super fun project and we are really happy with the final result.

Kinloch Golf Club

The Kinloch Club was voted one of the Top 10 new golf courses in the world for 2007 by the prestigious U.S. Travel and Leisure golf magazine - making it the only course outside of North America to be included in that Top 10. This site was built using asp.net and CMS functionality was provided by Umbraco (http://umbraco.org/).

New Zealand Garden Sheds

New Zealands top supplier of high quality steel garden sheds. This is a PHP site built on WordPress.

Good Golfing

The website and blog of Renee Fowler, a great golf coach based in Wellington. This is also a PHP site built on WordPress.

Chilli Jam

A podcast blog for cutting edge dance music. Yet another PHP site built on WordPress.

With a public website we want a simpler more 'bing/google' like search experience. The method of search is a basic search keyword phrase input and the power of the search resides in the indexing of content. We do not want to rely on a user's ability to construct complicated search terms. Everybody can use it, and use it effectively.

What follows from here is a basic guide for setting up SharePoint search on an anonymously accessed SharePoint publishing site. This assumes a bit of experience configuring search, but if you don't take a look at this TechNet webcast on installing and configuring search in SharePoint Server 2007.

Creating Scopes

Creating scopes is the most important step in configuring public search. There are usually a number of resource files such as CSS, JavaScript, XSL and images as well as objects like user profiles that you wouldn't want showing up in your search results. However we do want to be able to search over all of our document libraries, inlcuding aspx pages. So our first step is to create a scope that will return all pages and documents which we can create like this:

A search using this scope will return anything that is in the content source "Local Office SharePoint Server sites" AND (the content is a publishing page OR the content is a document). Note the brackets used in this statement.

As you can see the rule behaviour is being used to create logical conditions. The logic of the rules can be applied as follows:

• Include = OR
• Require = AND
• Exclude = AND NOT

The 'contentclass' property specifies what type the indexed item is and will be automatically available for any content item in SharePoint. The two types that we are usually concerned with in a public site are:

• STS_ListItem_850 (Publishing Pages)
• STS_ListItem_DocumentLibrary (Documents)

Check out this post from Dan Attis for a complete list of contentclass values.

Tip

I would recommend against allowing list items in your search scopes. The basic reason for this is that to view a list item you need to browse to the display form (/Forms/DispForm.aspx). Problem is this should be locked down by the Form Lock down feature. Unfortunately it is common for lists to be used to store content for your public web site; for example when using WSS collaboration features such as blogs, wikis and discussion lists. At the end of the day the collaboration and publishing features in SharePoint don't play very nicely together. When making design decisions for a SharePoint based solution and the question comes up - "Should we put this content in a simple list or create aspx pages?", you should consider whether you want the content to be searchable or not.

Scope Examples

What if we wanted to create a scope that returned everything under a specific web? In this example I have added folder rule that will include all results in or beneath the 'about-us' site:

What if we had a shared server environment that hosted multiple websites? In this example I have added a domain rule so that any results for my site will be returned:

If you don't know how to create scopes than have look at this help page from microsoft office online.

Tip

When indexing document libraries make sure that the documents are of a file type known to SharePoint, otherwise SharePoint will crawl the document as a list item and use the form display page rather than the actual document itself. Check out the filter pack from Microsoft if you want to add additional file types.

Creating a Simple, Deployable Layout

Armed with our public search scopes we already have enough information to return the right results. The next step is to create a simple search page to display search results.

When you create a search centre using the out-of-the-box search site template, you get a whole bunch of features that just aren't that well suited to a public facing scenario (RSS Feeds, Alerts, Advanced Search). My recommendation is to take a light weight minimal approach - why use a whole search centre when a single results page will do it? Creating a single page layout that is part of an easily deployable SharePoint solution is often the cleanest way to go.

Web Parts

Web Part zones often cause issues when it comes to repeatable deployment and they add additional HTML bloat. If you are wanting the simplest HTML output possible then web part zones should be avoided.When it comes down to it we only really need a page layout with a few basic web parts - SearchBoxEx, CoreResultsWebPart and the SearchPagingWebPart.

Here is an example of using the CoreResultsWebPart in a search page layout without web part zone.

<Search:CoreResultsWebPart runat="server"

    ID="SearchResults"

    ShowActionLinks="True"

    Scope="All Pages and Documents"

    HighestResultPage="1000"

    DuplicatesRemoved="True"

    DisplayDiscoveredDefinition="True"

    ShowSearchResults="True"

    FrameType="None"

    NoiseIgnored="True"

    StemmingEnabled="True"

    View="Relevance"

    QueryNumber="Query1"

    SentencesInSummary="3"

    ResultsPerPage="10"

    DateFormat="DateOnly"

    DisplayAlertMeLink="False"

    DisplayRSSLink="False"

    RelevanceView="True"

    WebPart="true">

    <XslLink>/XSL/CoreSearchResults.xsl</XslLink> 

    <SelectColumns>

        <root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

            <Columns>

                <Column Name="WorkId"/>

                <Column Name="Rank"/>

                <Column Name="Title"/>

                <Column Name="HitHighlightedProperties"/>

                <Column Name="Size"/>

                <Column Name="Path"/>

                <Column Name="Description"/>

                <Column Name="PictureThumbnailURL"/>

                <Column Name="SiteName"/>

                <Column Name="CollapsingStatus"/>

                <Column Name="HitHighlightedSummary"/>         

                <Column Name="ContentClass"/>

                <Column Name="IsDocument"/>

                <Column Name="Write"/>

                <Column Name="Author"/>

                <Column Name="ContentType"/>

            </Columns>

        </root>

    </SelectColumns> 

</Search:CoreResultsWebPart>

The other web parts can be added to the page layout in the same way.

Tip

Make sure search.js is inlcuded in a custom search page layout as it is needed for logging search statistics:

<asp:Content ContentPlaceHolderID="PlaceHolderAdditionalPageHead" runat="server">

    <SharePoint:ScriptLink ID="ScriptLink1" name="search.js" runat="server"/>

</asp:Content>

Additional Branding Considerations

The majority of the branding is quite easy due to the core search results web part using an XSL transformation to style the results. Unfortunately the other web parts will require tedious battling with overriding of SharePoint's CSS properties. Not ideal but you can still get it looking pretty decent if you know what you are doing.

For full control of the HTML structure and styling you would need to create a bespoke solution that used the search SQL Syntax API that comes with MOSS. This is also the only solution if you require some advanced sorting or filtering functionality. This isn't overly difficult, but it's a tough one to explain to the business owner that is forking out for SharePoint.

So what about advanced search? I think we'll leave that one for another day.

I hope this post gives you a few ideas and some "best practices" on you can go about creating a decent search solution for you public SharePoint website.

Good luck!

It's been a busy few weeks with little time for this blog, so I have put together a catch up post of some recent news:

The Wellington Community SharePoint Conference
The inaugral conference went off without a hitch at the start of the month. I enjoyed presenting and meeting a number of SharePoint enthusiasts. The speakers slide decks have been posted up on the NZ SharePoint user group website.

SharePoint 2010
The first snippets of the next version of SharePoint have been released. I highly recommend watching the sneak peak videos - they are real eye openers! Also check out the developer documentation for some SDK info.

June cumulative update
Another update for SharePoint and WSS was released, check out the team blog for more info (yup, this is just filler).

Trinkit moved to auckland
Kate and I have moved shop to Auckland. 7 years of howling gales finally got to me and we have moved north in search of greener pastures. At this stage I'm pretty booked up for the next 6 months but Kate has a little bit of capacity if you know of anyone needing specialist SharePoint IA, design and integration skills.

After installing Service Pack 2 and running the backup command you will notice a few subtle, but important changes:


Previously it was a best practice to set the site being backed up to read only using the setsitelock command. This is something that I am guessing 95% of people never did. And who can blame them as it wasn't made terribly obvious. Fortunately the backup command now automatically sets this and lazy admins can have peace of mind.

The April CU also provided an important update to how backup and restore works, particularly with publishing sites. In SharePoint, the actual page layout aspx files are stored with some hardcoded metadata which includes the url of the site they belong to. Previously when performing a backup & restore to different farms with different URLs this could cause issues. Import/Export does not have this problem as the page layouts are recreated in the target site. The backup command has now been updated to fix this issue and this method of migrating content between farms is now supported. Note that the  June CU is now available and supersedes the April CU.

So why would you want to use backup/restore over import/export to migrate content anyway?

If you commonly use the SPSiteDataQuery class, ContentQuery webpart or the DataView webpart you rely on GUID references to lists for query commands. By default, import/export assigns new GUIDS to any lists that are migrated which will upset the queries that rely on them. Using backup/restore was an easy way to avoid this issue.

Of course it was fairly easy to write some import code using the object model and retain the GUID values. And if you still want to use import/export that is the way to go.

My session on SharePoint and NZ Web Standards is on the Thursday at 4.15pm in Chamber Room 1 and I'm really looking forward to it!