This post applies to SharePoint 2010 Server, Standard or Enterprise edition.

SharePoint can be used for all sorts of content. For collaborative and productivity scenarios, the focus is often on document libraries and lists for managing content. Sometimes content is better suited in web pages, such as wiki sites and newsletter. But the default page layouts are quite basic.

The image above (click on images here to view full size) shows the default page layouts for publishing content in web pages. There are three types of article page, two wiki pages and a web part page. We’re going to create our own article page layout.

Creating a new article page layout

The three article pages are very similar. The only difference is whether or not you include an image page control on the page and, if you do, whether it is on the left or right side of the page. All three include page controls for a title, article date, byline and page content.

The image above shows the article page layout Image on Right with some content in the Title, Article Date, Byline, Page Image and Page Content.  It looks fine when viewing the page, but it’s just one clump of content – the Page Content control.  The only slices we can display elsewhere are the Title and Byline.

The image above shows a Content Query web part (CQWP) displaying the ‘Latest Newsletter’.  (CQWPs can be displayed on any site in a site collection, in this case, showing part of the news letter on another site.) The active link is the Title and the text next to the image is the Byline, displayed as a description.  Instead of a Byline, I want to publish a summary without having to duplicate content in the actual article page.  To do that, I need to create my own article page layout.

Create the required columns

Every control on a page layout is linked to a column.  If we want to create our own page controls, we first need to create the columns. This is slightly different to creating columns in a document library or list.  Page controls must be associated with site columns, not library columns.  Site Columns includes four additional column types specifically to use in web publishing. These are not available when creating columns within lists and libraries.

1. On your site (or site collection root if you want to re-use the columns across other sites), go to Site Actions – Site Settings
2. In Site Settings, click on Site Columns
3. In Site Columns, click Create.  For our example, we are going to split our article page into three: News Summary, Message from the Boss, and the rest of the newsletter. We need two additional columns for the Summary and Message from the Boss. The image below shows the settings for our News Summary column.  Note the column type (Full HTML content…)

Add the columns to the Article Page content type

To make it easy to add our new columns to a page layout, we’re going to add them to the corresponding content type.

1. In the same site where you just created your columns, go to Site Actions – Site Settings
2. In Site Settings, click on Site Content Types
3. Scroll down to the group Page Layout Content Types and click on Article Page
4. In the Article Page Content Type template, click Add from existing site columns and add your two new columns to the content type.

Create the article page layout

1. Edit the site in SharePoint Designer
2. In the Navigation (on the left), click on Page Layouts
3. In the ribbon menu (at the top), click New Page Layout
4. In the New dialogue box, select the Page Layout Content Types group and the Article Page Content Type. Enter a URL name (all one word) and a title for your new page layout.

Add controls to your article page layout

First up, we currently have a completely blank page layout. To cheat and get us started, we are going to copy the design of one of the existing article page layouts.

1. In the Page Layouts folder, click on the page layout ArticleRight.aspx
2. In the page layout settings, click Edit file (under Customization)
3. When prompted, do NOT check it out.  Then, when prompted, click Yes to open in advanced mode. Copy the entire contents of the code screen and paste it into the code screen of your new page layout. When finished, close the ArticleRight.aspx page layout.

Side note: I personally prefer split mode in SPD to display both the code and the design of a page layout. If you can’t see any code, click on Split or Code just beneath the page layout.

Your new page layout should now look just like the page layout for articles with an image on the right. We are now ready to add our two additional page controls: News Summary and Message from the Boss.  We want to add these controls above the Page Content control’

1. In the Toolbox on the right side of the screen, scroll sown to the Content Fields group. You should see your two columns. In this example, Message from the Boss and News Summary.
2. Drag the two columns onto the page layout. I have added the News Summary and Message from the Boss within the DIV for the article content.
3. Look at the settings for the Page Content control (FieldName=”PublishingPageContent”) in code, it has two properties set:
   • HasInitialFocus=True
   • MinimumEditHeight=400px

   These two settings control the height of the box on the page layout and where the cursor is placed. For mine, I am going to use HasInitialFocus=True on my News Summary control. I am also going to make both of my columns have a minimum editing height of 200px.  When you are making these changes, make sure you add the properties before runat=”server” to make sure you get them in the right place (if you’re not experienced with doing this stuff).

4. Finally, I’m going to add a title for my newsletter in the DIV for the article header, to save writing them within the page each month. Note: normally I’d format these better or replace with a banner image (I was going to go all Matrix’y), but to keep it simple…

In the image above, you can see my two columns with field names displaying their GUIDs instead of the friendlier names of the built-in PublishingPageContent within DIV class=”article-content”. And I added a plain DIV to drop the magazine title ‘The Oracle’ at the top of the DIV class=”article-header” with a basic style applied.  The toolbox over on the right of the page shows my two columns listed under Content Fields.

When you’re ready, save the page layout, check it in and publish/approve ready for use in the site.

Add the page layout to the site

Once published, we can add our new page layout to the list of page layouts used in the site.

1. Back at the site, go to Site Actions – Site Settings
2. Within Site Settings, click on Page layouts and site templates (under the Look and Feel group)
3. Under Page Layouts, select ‘Pages in this site can only use the following layouts) and add your page layout. Click OK.

Note: If you want the new page layout to be the default when new pages are created, go back into Page Layouts and set it to be the default.

Use the new page layout

If I go to edit my current newsletter, I can now change the page layout and select my new format.

In the image above, I have moved my summary and message from the boss into the new boxes on the page. Compare to the original image earlier in this post. (In hindsight, should have made the two boxes 100px they don’t need to be that large.) As a tip, set the default size of the box to roughly how much content you would want people to put in it.

When you publish the page, it looks just the same. But now that we have content segmented, we can start to display those segments elsewhere.

Modifying the content query web part (CQWP)

The final step in this post is going to be to display the news summary from our newsletter on the Intranet home page. We need to change the columns that are displayed in the CQWP under Title and Description.

In the image above, ‘Original Latest News’ is the CQWP with its default settings, displaying the Title and Byline of the newsletter.  Beneath it, ‘Latest News’ shows our new CQWP displaying the Byline (instead of Title) and Newsletter Summary (instead of ByLine).

I’m planning to go into the CQWP in a bit more detail in another post, including adding a ‘Read more…’ link.

SharePoint 2010 introduced managed metadata for the first time – the Managed Metadata Service (MMS). You can create a hierarchy of terms (metadata) and then use those terms to classify content stored in SharePoint. If you decide to rename a term, all items classified will be updated to reflect the new term. That’s the managed bit.

For an overview, please read an earlier blog post: SharePoint Managed Metadata Overview (Nov 2010)

Whilst the MMS is a great addition to SharePoint, it doesn’t cover all taxonomy requirements. This post will briefly explain the different types of taxonomy and what SharePoint can and can’t do to implement them.

The short version:

The SharePoint MMS can create taxonomies with a single hierarchy or multiple hierarchies using term sets. It can also be used for folksonomies by using a keywords list of tags. It can nearly do polyhierarchies, by reusing terms across term sets, but with limited uses.  If you have a deep taxonomy hierarchy to implement, you may need to add FAST to your SharePoint deployment.

The details:

Types of taxonomy

A taxonomy is a hierarchical form of classification. You define a hierarchy of metadata terms that can then be used to classify and describe stuff.

There are three main types of taxononomy:

• Single hierarchy
• Multiple hierarchies
• Polyhierarchies

And then there’s the informal rebel, the folksonomy.

Single Hierarchy

The simplest of taxonomies – a single hierarchy containing all the terms you plan to use. In this example, I’ve started with Flowers. That means the only things I’m going to classify are flowers. If I want more in a single hierarchy, then flowers would be a sub-class with a parent – e.g. plants, which may have a parent – organic material, that may have other sub-classes like mammals, which would have a sub-class for primates etc.  A single hierarchy is simple in theory but quickly becomes complex as you try to organise all possible terms.

Which is why, unless you are a library or garden centre, you end up with…

Multiple (Faceted) Hierarchies

In the digital world, we don’t need items to be located in only one place. We can use multiple hierarchies to describe them.  I might be looking for tulips. I might be looking for anything with red petals. I might want flowers that open earlier or later in the year for my garden.  Thanks to multiple hierarchies, I can find what I want without having to know where to look first.

Polyhierarchies

The most complex of taxonomies – a polyhierarchy is where a child or sub-class has two or more parents instead of just one.  Jasmine can be in the form of a shrub (small bush) or a vine (tall climbing plant).  Instead of being listed twice, the word is listed just once and linked to the two different parents.

Folksonomy

A folksonomy is the informal version of a taxonomy. It is simply the use of tags to describe objects. An object may have many tags. A tag may be reused for many objects.  There is no hierarchy – all tags are equal and there is no relationship between them.  You don’t define the tags first. You create them as you go. Once a person has created a tag, it’s added to the list.

A folksonomy can seem chaotic and confusing. Its success on the Internet, on sites such as Flickr, has been because it is a lot easier and quicker to simply tag items than have to select from a pre-defined hierarchy that may not match your vocabulary (imagine if plants were described using their Latin names).

SharePoint and Managed Metadata

SharePoint’s MMS can be used for both taxonomies and folksonomies.  Within Central Administration (and can also be accessed via Site Collection Administration) is the Term Store Management tool.

Keywords

SharePoint’s folksonomy is a group called Keywords:

When any item is tagged, either using the Enterprise Keywords column available in lists and libraries or by tagging site pages, the tag is added to the Keywords group (1. above).  As you start to type a tag, SharePoint will automatically suggest matching tags as you type (2.), to avoid having multiple spellings of the same word.  You can manage your keywords (3.) If you want to clear out unnecessary tags, you simply delete them.  If you also have a taxonomy, you can move popular keywords into the term set and make it part of a formal hierarchy. This is a great way to develop an effective taxonomy rather than a taxonomy filled with unused terms.

Term Sets

SharePoint uses term sets to create taxonomy hierarchies, with the following levels:

You create a group to contain one or more term sets.  A group with a single term set would be a single hierarchy. A group with multiple term sets would be a multiple or faceted hierarchy.

Within a term set, you create terms. Each term can itself have terms. In the image above, we have a group called Taxonomy Examples (created for this post). The term set is called Colours. The first level of terms contains Blue. Beneath blue is a second level of terms: Royal Blue, Cambridge Blue and Navy Blue.

Terms can be re-used across term sets, which sort of (but not quite) enables polyhierarchies.

In the image above (click on it to view in larger detail), I have a group called Plants. It contains term sets for Shrubs and Vines. The Shrubs term set contains a term called Jasmine. The term has been re-used and linked to the term set Vines.  If you look at the right side of the page,  displaying the term properties for Jasmine, in the box ‘Member of’ we can see the term is linked to two term sets. If I rename Jasmine, both term sets will be updated.

To create this polyhierarchy, the group Plants is the class, and the term sets are the first sub-classes. It has to be done this way because you cannot re-use a term within the same term set.  But this creates a challenge because only the built-in Enterprise Keywords column allows users to pick terms across groups and term sets. Managed Metadata columns have to point to a specific term set.

Whilst you cannot re-use a term in the same term set, there is nothing to stop you having duplicate terms, i.e. two or more terms with the same name. The downside is that you are creating extra terms, each with its own properties, which is extra work to manage and can be confusing for people.  But duplicates enable you to use a single term set that works better with the Managed Metadata column.

It’s probably easier to demonstrate:

The image above on the left is displaying the term store within the MMS. At 1. is the polyhierarchy example: A group for Plants with term sets for Shrubs and Vines, each linked to a single term, Jasmine (it has a slightly different icon to show it is linked to more than one term set).  At 2. I have created the alternative scenario, a single hierarchy with duplicate terms. This time, Plants is the term set with first-level terms for Shrubs and Vines. Each has a second-level term called Jas.

The MMS is used in two ways within SharePoint lists and libraries:

• Enable the built-in Enterprise Keywords column, which points to the entire term store (all groups and term sets).  It is always a mult-value field (people can enter one or more tags) and if the words entered are not already in a term set or the keywords group, they will be added to the keywords group. (Side note: the label ‘Enterprise Keywords’ can be confusing since it points to all groups in the MMS, not just the Keywords group).
• Create columns of the type ‘Managed Metadata’ which must be pointed to a single term set. However you can then specify if the column is to contain only a single value versus multiple values, and whether or not people can create and add their own tags or must choose from the list provided.

The top-right image is displaying the properties form for an item in a document library, with the built-in Enterprise Keywords column (3.) enabled. As I type in Jas, three suggestions are offered – Jas in the term set Plants, under the term Shrubs; the duplicate Jas in the same term set Plants, under the term Vines; and, Jasmine from the group Plants, displayed once but showing both term sets that it is linked to. In this image, the correct method would be to use the Polyhierarchy (from 1.) so that I can classify the document as about Jasmine, regardless that it is both a shrub and a vine.

The bottom-right image is displaying the properties for a Managed Metadata column (4.). When you create a column of the type Managed Metadata, you have to point it to a single term set.  This is where the polyhierarchy (1. in the image above) fails in SharePoint because I can’t point the column to the group Plants, I have to pick one of the term sets within the group, either Shrubs or Vines. I don’t want separate columns for each sub-class within plants. My alternative approach (2.) with duplicate values does work because Plants is the term set. But then how do I decide which Jas to pick to classify my document?

And there’s another gotcha.  One of the most useful reasons for implementing managed metadata is to refine search results.

The image above is displaying a standard SharePoint search results page. On the left side of the page are the search refiners.  I have two term sets listed – Department and Products.  Under Products, I can refine results by SharePoint, Content and Apps.  Here’s the rub. My term set hierarchy is as follows:

• Term set: Products
  • First-level term: SharePoint
    • Second-level term: Content
    • Second-level term: Apps

The standard search refiners in SharePoint do not display a hierarchy under the term set, it is simply Term Set as the heading, and all terms listed beneath, regardless of their position in the term set hierarchy.  A deep hierarchy within a term set does not work well with the standard search refiners, they are better suited to flat hierarchies – term set as the class with just one sub-class of terms.  In this example, I should either keep the term set Products but have just one level of terms – the product names (SharePoint, Office etc.) or make the product the term set if I want to classify by feature, e.g. term set: SharePoint, terms: Content, Apps etc.  The alternative is to upgrade my SharePoint deployment to include FAST, which is Microsoft’s advanced search and taxonomy tool. FAST includes the ability to configure your search refiners to match your taxonomy hierarchy.

In conclusion, the Managed Metadata Service enables you to create all three types of taxonomy: single hierarchy, multiple hierarchies and polyhierarchies, as well as the folksonomy of keyword tags.  However, you can only use all these methods with the built-in Enterprise Keywords column, which cannot be locked down if you want to restrict what words can be used to classify content.  The Managed Metadata column can be locked down but only works with a single hierarchy, meaning you either have a deep single hierarchy or have to create separate columns for each term set.  Search refiners work best with multiple (and flat) hierarchies, they do not work well with a single deep hierarchy.

To design the MMS effectively for search, you have three choices:

1. Flatten your taxonomy:

• Use multiple term sets, each with a list of terms – i.e the term set is the class, the terms are a single sub-class. Do not have a hierarchy deeper than that.
• If using the Managed Metadata column, you will need a column per term set.  Essential if you need to restrict people to picking from your defined lists of terms.  Aim for fewer term sets. This will likely mean not going to deep with your taxonomy (in my Plants example, I’d need to either drop the final level – Jasmine, or drop the sub-clases of shrubs vs vines vs flowers, and just have a term set of Plants with terms for the type: Tulips, Roses, Jasmine etc.
• Use the Enterprise Keywords column when you don’t mind people adding their own tags (will be added to the Keywords group). Matching terms will be suggested to help avoid unnecessary duplicates.

2. Upgrade your deployment to FAST

If your taxonomy is too important to flatten but you still want to use search refiners (you should, reasons for classifying content usually include making information easier to find), you need to consider whether or not to configure FAST in your SharePoint deployment.  FAST includes advanced search refiners that include displaying a deeper taxonomy hierarchy.  It also includes the ability to auto-classify. But may involve additional licenses so you need to factor the cost into your project.

3. Use a specialist add-on

The third option is to use an alternative (non-Microsoft) taxonomy solution that can be added to your SharePoint deployment.  You are likely to also require an auto-classification tool.

If you are immediately thinking that option 1 is not good enough for your taxonomy needs, before heading to the second or third option consider if your taxonomy is good enough for your organisation’s needs.  Folksonomies have succeeded where taxonomies have failed because of their ease of use.  It’s no use having a deep and detailed taxonomy hierarchy if people make mistakes, choose the defaults or just click the first in the list to get through classifying their information. And auto-classifiers are a long way from perfect.

No metadata is better than bad metadata.

Related blog posts

• SharePoint Managed Metadata Overview

One TechNet article I’m always dipping into for reminders when designing SharePoint solutions is the capacity management article defining boundaries, thresholds and supported limits for sites, lists and libraries. For the full article, read SharePoint 2010 Capacity Management: Software boundaries and limits (at time of writing, updated 14 July 2011 following changes introduced with Service Pack 1).

First up, Microsoft definitions:

• Boundary = static limit that cannot be exceeded by design
• Threshold = configurable limit that can be exceeded to accommodate specific requirements
• Supported = Configurable limits that have been set by default to a tested value.

Second, there have been a lot of changes introduced following Service Pack 1 released in June. The last major update to the software boundaries and limits was September 2010.  These tables have been updated to reflect the changes.

What follows is my summary and additional notes with references at the end. Some items are in a different order to the key reference as I’ve organised by layer – web app – content DB – site collection – site – list/library – page followed by some of the key services. Note: When a Max.Value has an asterisk next to it, that usually means you’ll never (or shouldn’t, IMHO) get close to it…

Farms and Web Applications

Content Databases and Site Collections

Lists and Libraries, Documents and Pages

Column Limits (Large Lists)

When designing large lists or libraries, consider the following. SharePoint 2010 supports SQL row-wrapping and can wrap up to 6 times (means one item actually occupies 6 rows instead of 1).  The maximum size per row is 8,000 bytes, with 256 reserved for built-in columns, which means the total number of user columns must not exceed 7744 bytes, regardless of how many row-wraps are used.

All the following values are Threshold limits.

External data column typically have a primary column (text field); hidden ID column (multi-line text) and secondary columns (text, number, Boolean or multi-line) based on the data types defined in the BDC.

Tips include creating and using an index to organise a large list – allows filtered views and faster results.

Security

The short version: keep tidy via Active Directory. Put users into Active Directory (AD) groups, put AD groups into SharePoint groups. Don’t forget, you can’t add Sharepoint groups to SharePoint groups.

Search

User Profiles

Blogs

What	Max Value	Limit Type	Notes
Blog posts	5,000 per site	Supported	Won’t be using SharePoint for busy blog sites then… Plenty of other reasons not to. For large and public blog sites, using a dedicated tool like WordPress (what this post is being written on)
Comments	1,000 per site	Supported	Techcrunch definitely couldn’t run their site on SharePoint…

Business Connectivity Services

Workflow

Managed Metadata

PerformancePoint

SharePoint Workspace (formerly known as Groove)

Project Server

.

Related Blog Posts

• SharePoint Sizing pt 1 – Servers
• SharePoint Sizing pt 2 – Databases

References

• SharePoint 2010 Software boundaries and limits – TechNet
• Designing large lists and maximising performance – TechNet
• Data storage changes for SharePoint 2010 (post Service Pack 1) – SharePoint Team Blog
• Techniques for managing large lists – SharePoint help, Microsoft.com
• Managing large lists in SharePoint for users and site admins – Joel Oleson

This post is filed in the Architecture & Planning section of the SharePoint 2010 Handbook on this site.

SharePoint 2010 includes service applications for managing information that traditionally has been stuck in spreadsheets. The challenge can be choosing which tool best fits your needs. Here’s a rough guide, based on only editing and viewing data in a web browser. From the user’s perspective, no Office client required…

…however, first a licensing note. SharePoint Lists are available in all versions of SharePoint 2010. Excel Web App is available for all versions of SharePoint 2010 but requires Office 2010 licenses to use (you don’t need the software, just the license). InfoPath Forms Services, Access Services and Excel Services all require SharePoint 2010 Enterprise Edition.

Second: This post is just covering services to store and manage structured or semi-structured data typically found in Office . It’s not covering the analytics side, i.e. PerformancePoint and Excel Services, and it’s not covering integrated application features, i.e. Business Connectivity Services or External Lists.

And off we go…

The short version:

• Use SharePoint lists for simple applications with not toooo many columns
• Use InfoPath web forms if you’re creating a lot of columns of the type ‘Multiple Lines’…
• Use Excel Web Apps, if you’re licensed, if you are trying to make a list behave just like a spreadsheet. You know you’re going to need Freeze Panes at some point…
• Use Access Services if you’re creating a lot of columns, need more functions to calculate, more queries to filter and more items to view than a list can possibly handle… and you’re on a budget that excludes more expensive alternatives

Now for a bit more info:

*
Note this refers to the Excel web application that displays the full Excel spreadsheet, not Excel web parts that display a named range of data from a spreadsheet.

Table explanation: X = requirement can be met by the feature.  / = sort of, but another feature can do more or better.  – = not applicable (Excel Web App doesn’t use views to display content). Blank = no, requirement cannot be met by the feature.

Lists

Easiest to use and most common choice for replacing spreadsheets for managing information. Don’t forget lists include calendars, tasks, links, contacts etc.  You can create calculated columns using common functions from Excel, including ‘If’ statements. And you can have multiple different views to manage the data. Different people can edit the list at the same time provided they are editing different items. And finally, if there’s a process involved, you can integrate a workflow to manage the data.

The limits:

• You can only have so many columns before lists become unusable. You have a single form for editing individual items and all columns will be displayed on it. You can use Datasheet views instead to display a limited set of columns. But note: Datasheet views won’t work for any columns containing Managed Metadata, they will be read only.
• According to Microsoft capacity planning guidelines, you can store up to 30,000,000 items in a list. However all views must return less than 5,000 items. And in reality, the number is often far lower before performance degrades.

InfoPath

InfoPath is used to create forms containing semi-structured data, i.e a mix of numbers, calculations, and large clumps of text. The sort of files that could have been created in either Excel or Word because neither really fits the purpose.  With InfoPath you can create web forms for people to fill in and automatically submit to a SharePoint library. You can have multiple views within the form and control which view is displayed when a user opens the form. And you can choose to promote certain properties into SharePoint columns for quick access without opening the full form.

Pros:

• Managing semi-structured data, including lots of text.
• Integrated workflows to manage updates to the form

Cons:

• You can only edit one item in a web form. If you need to edit lots of items at once, you are unlikely to be including lots of text and InfoPath wouldn’t be the right tool.
• The same Microsoft capacity planning guidelines for lists also apply to InfoPath forms libraries

Excel Web App

With SharePoint Server 2010, you can integrate Office Web Applications. They are similar, but not quite twinned, with the Office Web Apps available with Windows Live Online.  You store the spreadsheet in a SharePoint library and open it in the browser instead of the full Excel desktop client.  You don’t get full Excel functionality but it should be more than sufficient for editing content.  Excel trumps lists in that you can use that popular feature – Freeze Panes – to scroll across lots of columns without forgetting which item you are viewing.

Pros:

• Freeze panes
• Bigger range of functions for calculations
• Excel data visualisations can provide dashboard-style analytics

Limits

• In the web-browser, only one person can edit the entire spreadsheet at a time.
• Creating views is a manual effort, it is still just a spreadsheet.

Haven’t found a definitive answer as to how large an Excel spreadsheet can grow and still be opened in the browser.

Access

Access, that client database tool loved by users and loathed by IT usually in roughly equal proportions, has joined the world of SharePoint. You can now create web databases in Access and publish them as a SharePoint site. Forms and reports can be edited and analysed using just a web browser.

Pros:

• You can go column-crazy and choose how many appear in the different forms available within Access, including single item view, multiple items and datasheet views <- side note: lists use Access Services built-in, even in SharePoint 2010 Foundation, to display datasheet views.
• Whilst you don’t get workflow integrated, the query capability offers much more compared to configuring list views enabling different forms to be used for different stages of data update. (You just can’t email reminders automatically when data needs updating).
• Increased capacity compared to lists. Lists can store 30 million items and still be supported but no more than 5,000 items will be displayed in any view. There is no defined limit to the number of records that can be stored in an Access web database, the default is 500,000. But Access queries can contain up to 200,000 items, with a default value of 50,000. But don’t get too excited – see performance note below.
• Better option than Access client databases in networked mode. Access Services in SharePoint uses far better caching mechanisms to lock/unlock items and you don’t need to compact every 5 minutes.

Limits

• Less flexible permissions compared to lists. With lists, you can set permissions per site, list and item. With Access Services, you set permissions per site only.  You can lock columns to read-only in forms but everyone is affected. There’s no concept of a ‘super’ user from the content perspective. Changes to the database schema can only be made by people with Full Control or Design permissions to the site.  And anyone who can view the site can open it in Access 2010 if they have Access installed on their computer. And they can export the table contents to Excel…
• Consider it a replacement only for lists, spreadsheets and simple databases. Lots of limited functionality, such as not being able to do table joins, you have to use field lookups instead (DBAs may howl). Queries can only get so complex and you may resort to doing calculated columns within the table (DBAs – don’t bother howling, it’s no different to a calculated column in a SharePoint list – which is what the table becomes when it is published to SharePoint).

Whilst scale is way beyond SharePoint lists, it’s nowhere near fully-fledged databases (SQL or NoSQL) with web front-ends. The challenge is that it can do enough for users that they inevitably want that other 20% of requirements you said no to.

From a performance perspective, users will experience a significant delay (more than 10 seconds) waiting for a form or report to open if the underlying table or query contains more than 1,000 items. Possibly less – it’s comparable to the delay opening a normal SharePoint list of equivalent size.  The difference is that the delay is due to caching in the background. Once the form opens, editing and filtering is nearly as quick as if working in the full Access client, even if the form contains 10,000+ items. This is where it trumps lists.  If you’re displaying more than 1,000 items, aim for fewer forms and use the Datasheet form which enables filtering without refreshing the query – in effect, you’re viewing a list but without the limit of 5,000 items. May publish more guidelines in a separate blog post.

And there you have it, a rough guide to the different ways you can store and manage data in SharePoint.

References

• SharePoint Editions comparison – Microsoft
• Capacity Planning Guidelines – blog post to be published

Not a million of references for this one, most is based on experience tinkering with SharePoint over the past 12 years. It’s come a long way from that document management add-on to Exchange I first saw in 1999

SharePoint 2010 has changed a few things regarding search. One of which is the use of a different master page to control the navigation, providing a minimal global navigation (aka top link bar) and removing the left sidebar (aka current navigation or the quick launch bar). The left sidebar needs to be removed to make way for the new search refiners but the global navigation loses an important feature – the breadcrumb to navigate back where you started (i.e. somewhere else in the site collection).

Comparing default master pages

The top image above shows the header for a normal internal SharePoint site with it’s little breadcrumb icon expanded (the folder icon next to Site Actions). I’m on the Facilities site which is a sub-site under Resources which is a sub-site under Intranet. Intranet is the root site in the site collection.

The second image above shows the header for a SharePoint search site (Basic or Enterprise template). There is no icon.  It is a sub-site under Intranet but you can only tell if you look in the address bar of the browser. There is no link to click to get you back to the Intranet root. This can be annoying for users if they are not interested in any of the search results provided.

I do the following little hack to add the Intranet root URL before the site title.

1. Create a new master page

• In SharePoint designer,open the root site in the site collection. Click on Master Pages in the navigation
• Open the minimal.master page and copy its contents (do not check it out, do not save any changes)
• Create a new blank master page, give it a name (e.g. search.master) and replace its content with the content from the minimal.master page

2. Set up a style for the link to be added

• At the end of the HEAD section of the master page, add the following style settings

<style type="text/css">
   .MyLinkStyle a, a.hover{  
       color: #FFFFFF;  
       text-decoration: none; }
</style>

• Note: you can call .MyLinkStyle what ever you want, e.g. .YourLink. Just make sure it starts with a full stop (.)
• These style settings are based on the default site theme. If you are using a different theme, change the formatting to suit. If you are doing everything properly through style sheets, make the changes in the appropriate files.

The HEAD section of the file should now include your style settings as shown below (additions highlighted):

Adding <style> code to master page

3. Add the link before the site title

• Whilst still editing your new master page…
• Locate the line that contains the Heading 1 tag. It should look something like this:

<h1 class="s4-mini-header">

• Enter the following code directly beneath this tag:

    <span class="MyLinkStyle">
    <a href="http://intranet">Intranet</a> -
    </span>

• Note: Replace “http://intranet” with your own URL.
• The edited section should look something like the image below (additions highlighted, my URL is http://demo/sites/intranet/):

Adding the link to the master page

I’ve included the split screen mode so that you can see how the link appears visually. Don’t be confused by ‘Intranet – Intranet’. We are creating this master page at the root site in the site collection – called Intranet on this demo. The master page is only going to be applied to the Search sub-site.

4. Finish your new master page

• Save, check-in and publish your new master page.
• Don’t forget to approve it – you’ll be prompted if you’re working with a default settings.

5. Apply the new master page to your search site

• Navigate to your Search site. Go to Site Actions – Site Settings
• Under Look and Feel, click on Master Page
• For the Site Master Page, change the selected master page from minimal.master to search.master (or whatever you called your new master page)

Selecting the new master page

Click OK. And your search site should now look something like the following:

Link added to the Site Title

And there you have it, a basic little hack to add navigation to your site title in search sites.

Related blog posts

• SharePoint 2010 Search Set-up
• Adding Staff Directory Search
• SharePoint vs FAST for search
• Configuring Adobe PDF indexing

This post is filed in the SharePoint 2010 handbook under Enterprise Search

Note: This post is relevant to both SharePoint 2007 and SharePoint 2010.

One of the features that SharePoint has had for a while now is the Meeting Workspace site template. It’s a template to help co-ordinate content and activities relating to meetings. Used well, it can be a great time-saver and/or help improve the management of and outcomes from meetings. But it does have its gotchas and isn’t suitable for all types of meetings. This post is an overview of when and how to use SharePoint for managing meetings, including Outlook integration.

There are two methods for using SharePoint to manage meetings:

Team Site with a Calendar and Document Library

The most basic way of using SharePoint to organise meetings: within a team site. It could be a simple document library (e.g. called Meeting Docs) within a general team site, or it could be a dedicated sub-site such as the image above, including a calendar and a library per type of meeting. Add a column to the document library called ‘Meeting Date’ and when you upload documents, you can enter the meeting date for future reference. You an also use it to create views based on meeting date if you want to make it easy for people to locate what documents relate to a given meeting.

The calendar is really an optional nice-to-have. Most people would create the meeting invite within their mailbox and send it out to all attendees. It’s then automatically added to individual calendars for everyone who accepts the meeting invite.  Creating the appointment in a calendar on the SharePoint site just offers another visual prompt, outside a person’s mailbox. But it is a separate manual process (unless you give the site a mailbox and do some jiggery-pokery to make the calendar list an attendee…)

Meeting Workspace

The Meeting Workspace is a special site template designed specifically for meetings. There are 5 variations of the template:

• Basic Meeting Workspace
• Blank Meeting Workspace
• Decision Meeting Workspace
• Social Meeting Workspace
• Multipage Meeting Workspace

The Basic Meeting Workspace contains a single page (per meeting) and 4 web parts (and corresponding lists or libraries): Objectives, Attendees, Agenda and Document Library. The Blank Meeting Workspace contains a single page and nothing – the clue is in the title.  The Decision Meeting Workspace is like the Basic one but with extras: Objectives, Decisions and Tasks.  The Social Meeting Workspace contains multiple pages. The home page contains Attendees, Directions, and Things to Bring plus a picture. There is a page for discussions (it contains a Discussion Board) and a page for Photos (Picture library) ‘cos meetings aren’t social without photos  The Multipage Meeting Workspace lets you create multiple pages for the meeting and starts with 3 to begin. The home page contains Objectives, Attendees and Agenda. The other two are blank and ready to use (and rename from Page 1 and Page 2).

Regardless of the template you pick, a meeting workspace can be recurring – contains multiple meetings within the single workspace; or individual – one workspace per meeting.

Recurring Meeting Workspace

You can create a meeting workspace with a recurring schedule. A single site is created but with special code behind it to generate an instance of the site per meeting date, each one listed in the sidebar on the left of the page. The recurrences can either be created automatically using a recurrence schedule or manually added to the series. But you can not mix and match. It is either a set schedule or a manual series.

Automatic recurrences

When you create the meeting, you specify a recurrence schedule just as you would with a normal meeting. You can create the meeting from within a calendar list in SharePoint or an Outlook calendar. But you must specify to create a meeting workspace. The image above shows the option within SharePoint and a recurrence schedule for the meeting. Outlook integration is discussed later in this post.  You can make changes to an individual item within a recurring series but it must be done within the appointment item.  Additions must be added within the series (i.e. the recurrence schedule or item series).  Do not delete a recurrence unless you are absolutely certain it will no longer be required. It is fiendishly difficult to get it inserted back into the series.

Manual recurrences

Manual recurrences are created by simply adding a meeting to an existing meeting workspace instead of creating a new one. You can only add meetings to a meeting workspace that does NOT have an automatic recurrence schedule. Use this approach if your recurrence schedule is unpredictable.

Individual Meeting Workspace

An individual meeting workspace is a single site for a single meeting. Each time you create a new event in the Calendar list (or within an Outlook calendar), you choose to create a new meeting workspace site. With an individual meeting workspace, you do not get a sidebar down the left site of the page unless you select the Multiple Pages template.

Multipage Meeting Workspace

The Multiple Pages template enables you to have multiple different pages within a single meeting (the Social Meeting Workspace is also a multipage site). In the past I have often used this to provide a dedicated page for meeting organisers, where they can place their contacts, to-do lists and all the stuff that needs to happen for the meeting to take place but is of no interest to the attendees. The content can be audience-targeted so that only the organisers can see it.

In SharePoint 2007, pages were displayed as sub-tabs along the top of the page. They are now listed as navigation in the sidebar (same place as where recurring meetings are listed). This is much more consistent compared to other site templates. But it has its flaws. The ‘Pages’ link takes you to a backstage area that doesn’t actually display any pages.

The image above shows what happens when you click on Pages. You don’t see pages, you get to view All Site Content. That area can be confusing for users at the best of times. If you’re going to call it Pages it would be helpful if it at least displayed a list of the pages… or better still, change it to Home and point it to the default home page. But you can’t modify the link. Add it to the list of usability goofs Microsoft has made with SharePoint 2010.

Outlook Integration

As well as creating meeting workspaces within SharePoint, you can also create them within Outlook. This has a number of benefits:

• The site URL is embedded in the Outlook appointment, making it easy for attendees to navigate to the site (and eliminates the ‘I couldn’t find the document…’ excuse)
• Everyone who is added as an attendee is automatically added to the site permissions as a contributor, so that they can upload and edit documents.

And another change has occurred between the 2007 and 2010 versions, this time within Outlook.

In Outlook 2007, when creating a new appointment in your calendar, if you clicked Invite Attendees you see a link within the ribbon (the new menu structure in Office 2007) to create a Meeting Workspace. As shown in the image below:

In Outlook 2010, the Meeting Workspace link is no longer enabled by default. And when it is enabled, it is a tiny icon up in the Quick Launch tray at the top of the page. To display it, you must first click the little arrow at the far right of the Quick Launch tray (both are circled in red in the image below) to open a dialogue box where you can choose what icons appear, including the Meeting Workspace icon.

But other than that, the functionality is the same. When you click the Meeting Workspace icon, a task pane appears on the left where you can configure options to create a Meeting Workspace, including location and template. The location list is populated with the 5 last visited sites. It may be empty the first time you use the feature and you will need to paste in the URL to a site. But after that, it will remember settings.  People who are added to the To list will be added to the Members group of the site, with Contribute permissions (can add/edit/delete documents by default). The subject link will be used as the site title.  When you click Create, the site is provisioned and link is embedded in the body of the appointment, as shown in the image above.

A couple of tips: Enter the attendee list and subject line in the appointment before you create the meeting workspace. And keep the subject line short or you will end up with a very ugly URL. Gotchas to be aware of – recurring meetings in Outlook that are linked to a SharePoint Meeting Workspace site. I’ve seen a few cases of orphaned meeting workspaces when a recurrence is cancelled in Outlook and then rearranged.

And there you have it. SharePoint can be a very useful tool for organising meetings. But it can also be over-engineered. Only use meeting workspaces when the need justifies them. In many cases, a simple document library is all that is required, with the benefit of metadata to tag and find documents. A simple rule of thumb – think twice about using meeting workspaces for meetings that occur more frequently than quarterly…